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

[Brian Burkhalter]

> On Jun 30, 2019, at 1:37 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 27/06/2019 20:01, Brian Burkhalter wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8184157 <https://bugs.openjdk.java.net/browse/JDK-8184157>
>> http://cr.openjdk.java.net/~bpb/8184157/webrev.01/ <http://cr.openjdk.java.net/~bpb/8184157/webrev.01/>
>> 
>> 
> I think the analysis is good and the approach to consistently leave the release of the OVERLAPPED structure to when the completion event is posted is good.

Good. Thanks for looking this over.

> One thing that isn't immediately clear from the changes is whether it introduces a memory leak when there is an error initiating the I/O operation or where there is an async close at around the time that the I/O operation is initiated. I would need to study these cases further to see if there are issues.
> 
> 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.

> 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.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190701/01e25033/attachment.html>