<div dir="ltr"><div>Thanks for your response, Alan:</div><div><br></div>> Can you determine if a blocking read outstanding on the same connection that another thread is blocked on the large write? <div><br></div><div>Yes, there are two server threads per connection: a reader virtual thread that loops around reading incoming client requests from the socket using a blocking Socket.read(); a writer virtual thread which polls responses from a write queue and writes them to the socket using a blocking Socket.write(). For additional context, we use a platform thread for accepting connections. Each connection is handed off to a dedicated reader which configures the TCP socket and performs any initial blocking handshaking (e.g. TLS). The reader thread then creates the write queue and writer thread before waiting for incoming requests. A separate write timeout thread (also virtual) monitors active connections to see if any writes have taken too long and aborts the connection if needed. FWIW, I believe this architecture is very similar to Helidon's.</div><div><br></div><div>> Can you set SO_SNDBUF to a large value to see if that reduces or eliminates the sightings?</div><div><br><div>Yes it does! As suggested, I set SO_SNDBUF to 2MB on the server and I have been unable to reproduce the problem since with this setting. The problem reoccurs as soon as I reduce it back down to e.g. 8KB.</div><div><br></div><div>The description of JDK-8334574 does indeed look very similar to the architecture of our server and would explain the behavior we're seeing. I'll spend some time looking at the reproducer to see if I can understand how it differs from my futile attempts. :-)</div><div> </div><div>Cheers,</div><div>Matt</div><div><br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 11 Feb 2026 at 17:27, Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/02/2026 16:00, Matthew Swift wrote:<br>
> Hi,<br>
><br>
> I suspect that I've discovered a bug in the IO polling mechanism used <br>
> by virtual threads on Windows. I've been able to systematically <br>
> reproduce the problem on Windows 2016, 2019 and 2022 Intel x64 using <br>
> both JDK 25.0.2 and 25.0.3 EA build 01, and also JDK 27 EA 8 build. <br>
> The problem occurs when the server attempts to send a large response <br>
> message to the client. The server's write operation becomes blocked <br>
> and is never notified when the socket becomes writable again:<br>
<br>
Can you determine if a blocking read outstanding on the same connection <br>
that another thread is blocked on the large write? Can you set SO_SNDBUF <br>
to a large value to see if that reduces or eliminates the sightings?<br>
<br>
We have been chasing an issue in the Windows Ancillary Function Driver <br>
for winsock that arises when a Windows SOCKET is use with two different <br>
completion ports or AFD device handles at the same time. Daniel Jeliński <br>
has some good analysis here:<br>
   <a href="https://github.com/piscisaureus/wepoll/issues/35" rel="noreferrer" target="_blank">https://github.com/piscisaureus/wepoll/issues/35</a><br>
<br>
We have a prototype poller implementation that works around this issue <br>
but it has some performance impact (on Windows) so have been slow to <br>
process it [1].<br>
<br>
-Alan<br>
<br>
[1] <a href="https://bugs.openjdk.org/browse/JDK-8334574" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8334574</a><br>
<br>
<br>
</blockquote></div>