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

[Alan Bateman]

On 28/05/2025 20:46, Alexei Olkhovskii wrote:
>
> > This may be an issue with the reserved stack area. There was work done 
> in JDK 9 via JEP 270 [1] but I think it needs to be looked at again.
>
> Perhaps https://bugs.openjdk.org/browse/JDK-8318888 is also relevant.
>

Yes, there are a few reports of issues when continuing after SOE.


> But regardless of the reason the other thread is holding the lock, 
> don’t you think the socket timeout should be respected for read(), 
> connect(), etc?
>

The connect method is only allowed once. It would be strange to create 
an unconnected Socket and then attempt to have 2 threads invoke connect. 
The second attempt must fail with SocketException (it will be 
"Connection in progress" or "Socket closed"). You are right that the 
second attempt will block, maybe beyond the connect timeout it 
specifies, before it throws the SocketException. I don't think this is 
worth spending time on as there is impossible for the second connect to 
succeed.

It's hard to know if there if there is a case where concurrent reads 
from the same TCP/socket stream make sense. At one point it was possible 
to have a Socket to a UDP socket but that mis-feature is deprecated a 
long time ago. If several threads are reading from the same stream then 
it requires coordination at a higher level, something that understands 
the protocol, meaning the lock contention will be further up the stack. 
If there is a protocol where it's possible to do something sensible when 
reading subsets of bytes, and with different timeouts, or code handling 
SocketTimeoutException then maybe your point could be looked. For now, I 
think the issue here is the "lock corruption" and we need to understand 
this a bit more. I'd prefer not use that to justify doing something to 
help a workaround when it does happen.

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