Redux 8184157: (ch) AsynchronousFileChannel hangs with internal error when reading locked file

[Brian Burkhalter]

> On Jul 2, 2019, at 9:02 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>>> The Windows implementations of AsynchronousSocketChannel and AsynchronousServerSocketChannel also remove and free the OVERLAPPED structure then the socket operation completes immediately. Will they also need attention?
>> 
>> Yes, at least AsynchronousSocketChannel: I should have caught that before. I’ll update the patch for these cases and look into the memory leak possibility mentioned above.
> 
> AsynchronousSocketChannel needs a similar change but I think not AsynchronousServerSocketChannel. I do not have a reproducer for this case yet however.

After re-reading the code while investigating how to write a reproducer for a similar AsynchronousSocketChannel failure, it does not appear that such a failure is possible. In the case of read or write on such a channel, read0() and write0() can return only one of two non-error condition codes: one for when the operation is pending, and another to indicate that the channel has been shut down. Only in the former cases is pending set to true. So the only possibilities for pending to be false are that the channel is either already shutdown or an error occurred while initiating the operation. In both of these cases the OVERLAPPED pointer is correctly removed from the PendingIoCache instance. Note that pending cannot be true if an exception occurred, so removing the OVERLAPPED pointer only on condition that pending is false is sufficient.

>>> The test will need cleanup, maybe rename it to LockReadWriteStressTest or something that is closer to what it actually does. It can use try-with-resources to avoid leaking resources when it fails. I assume "f" and "l" will be renamed as they are unusual variables names in this context. Also the buffer usages is unusual and I can assume can be cleaned up too.
>> 
>> The test is in effect the reproducer supplied in the issue so I did not give it any further attention yet.
> 
> 
> The test and the other things above are updated here:
> 
> http://cr.openjdk.java.net/~bpb/8184157/webrev.02/ <http://cr.openjdk.java.net/~bpb/8184157/webrev.02/>
An updated patch with the WindowsAsynchronousSocketChannelImpl change reverted is here:

http://cr.openjdk.java.net/~bpb/8184157/webrev.03/

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190703/80a131eb/attachment-0001.html>