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

[Brian Burkhalter]

> On Jul 1, 2019, at 12:05 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> 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.

If an exception is thrown initiating an I/O operation then this indeed would introduce a memory leak. This leak was there already for the pending case. I don’t know about the async close case.

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

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

Thanks,

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