RFR [8058099] (ch) Cleanup in FileChannel/FileDispatcher native implementation [win]

[Doerr, Martin]

Hi all,

I can still reproduce the error. My command line is:
C:\Java\jdk1.8.0_20\bin\java -classpath \\hs0131\hs0131.a\sapjvm_dev\jck\jck8\JCK-runtime-8\classes -Djava.security.policy=\\hs0131\hs0131.a\sapjvm_dev\jck\jck8\JCK-runtime-8\lib\jck.policy javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests -TestURL file:////hs0131/hs0131.a/sapjvm_dev/jck/jck8/JCK-runtime-8/tests/api/java_nio/channels/AsynchronousFileChannel/AsynchronousFileChannel.html#tryLock -TestWorkDirURL file:/X:/certification/JCK-runtime-8/workdir/api/java_nio/channels/AsynchronousFileChannel/

All jck stuff is on network drives which seems to be key for reproducing. X: is a network drive which just mounts a local directory on drive C: on the PC's local hard disk drive.
I couldn't reproduce the problem when using the C:/... path directly which points to the same files. That seems to work stable.

Several subtests failed with the following exception:
FAILED: Unexpected java.io.IOException: Overlapped I/O operation is in progress
java.io.IOException: Overlapped I/O operation is in progress
        at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
        at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:102)
        at sun.nio.ch.WindowsAsynchronousFileChannelImpl.tryLock(WindowsAsynchronousFileChannelImpl.java:359)
        at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests$3.runTest(TryLockTests.java:154)
        at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestSafely(Nio2TestCase.java:385)
        at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single$1.run(Nio2TestCase.java:349)
        at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:279)
        at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235)
        at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithPerms(Nio2TestCase.java:354)
        at javasoft.sqe.tests.api.java.nio.Nio2TestCase$Single.runTestWithAllPermsDenied(Nio2TestCase.java:270)
        at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.tryLock01_03(TryLockTests.java:166)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:405)
        at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:194)
        at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:126)
        at javasoft.sqe.tests.api.java.nio.channels.AsynchronousFileChannel.TryLockTests.main(TryLockTests.java:53)

I didn't dig through all the code to find out where we got the file handle from, but I assume it was opened for asynchronous I/O since the test is called AsynchronousFileChannel and the method holder class is WindowsAsynchronousFileChannelImpl.
I guess asynchronous is used for concurrent read and write operations and the asynchronous file locking is just a side effect which was not intended?

Hope this helps. Best regards,
Martin


-----Original Message-----
From: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Sent: Dienstag, 23. September 2014 14:00
To: Ivan Gerasimov; nio-dev at openjdk.java.net; Doerr, Martin
Subject: Re: RFR [8058099] (ch) Cleanup in FileChannel/FileDispatcher native implementation [win]

On 22/09/2014 14:17, Ivan Gerasimov wrote:
>
> On 22.09.2014 16:09, Alan Bateman wrote:
>> :
>> Martin Doerr brought up an issue recently where LockFileEx was 
>> returning ERROR_IO_PENDING [1]. I'm still wondering about that one 
>> because I also believed that if we aren't using FILE_FLAG_OVERLAPPED 
>> that it would also complete synchronously. Maybe we need to look at 
>> that one again to understand how this is possible.
>>
> That looks scary!
> However, I didn't find the reproducer in the thread, so it's hard to 
> say how it was possible to make it fail.
I'm not sure either, it's either that the MS documentation is wrong, 
Windows doesn't work the way the documentation says, or something 
fishing in the bug report. I've cc'ed Martin to see if he can say any 
more about the issue.

> I can revert these two usages of OVERLAPPED to be safe.
> On the other hand, we have a few more places where OVERLAPPED 
> structure is used, but the action is assumed to complete synchronously 
> - i.e. no checks for ERROR_IO_PENDING error are performed.
> The places are write0 and writev0 (in append mode) and release0.
>
> Shouldn't we check for ERROR_IO_PENDING more consistently?
I don't think so, I think what you have is right (at least according to 
the documentation).

-Alan