Redux 8184157: (ch) AsynchronousFileChannel hangs with internal error when reading locked file
Alan Bateman
Alan.Bateman at oracle.com
Sun Jun 30 08:37:10 UTC 2019
On 27/06/2019 20:01, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8184157
> 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.
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?
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.
-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190630/1ac93916/attachment.html>
More information about the nio-dev
mailing list