NIO Socket.read() may not respect the socket timeout

[Alan Bateman]

On 27/05/2025 23:50, Alexei Olkhovskii wrote:
>
> Hello,
>
> We’ve ran into a corner-case issue with socket read(). In short, it 
> doesn’t honor socket timeout when trying to acquire the read lock:
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L336
>
> readLock.lock();
>
> In our case one thread obtained a database connection and got stuck in 
> read() (we think because of a StackOverflow).
>

Would it be possible to do some digging to say for sure if this happens 
after StackOverflowError (SOE)? There have been a few reports of issues 
that appear to be lock "corruption" when continuing after SOE and it may 
be that the reserved stack area for critical sections needs to be 
re-visited.

As regards the test. Can you confirm you created this to demonstrate 
your point and isn't representative of what the code is doing? For a 
TCP/stream connection then having several threads reading from the same 
connection would require coordination at a high level. If it does arise 
that one thread is blocked reading and another thread attempts to read 
from the same connection then it is blocked until the first thread 
finishes reading. It would be a strange scenario to arise and different 
to the accept case where it's okay to have concurrently threads attempt 
to accept connections, they don't interfere.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250528/881bc541/attachment-0001.htm>