<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 27/05/2025 23:50, Alexei Olkhovskii
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CH4PR08MB1051010F0EB8E98012D9C3BA88D64A@CH4PR08MB10510.namprd08.prod.outlook.com">
      
      <meta name="Generator" content="Microsoft Word 15 (filtered medium)">
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Aptos;
        panose-1:2 11 0 4 2 2 2 2 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:10.0pt;
        font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#467886;
        text-decoration:underline;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}div.WordSection1
        {page:WordSection1;}</style>
      <div class="WordSection1">
        <p class="MsoNormal"><span style="font-family:"Courier New"">Hello,</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-family:"Courier New""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-family:"Courier New"">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:<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-family:"Courier New""><a href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L336" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java#L336</a><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-family:"Courier New""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-family:"Courier New""> 
            readLock.lock();</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-family:"Courier New""> </span><span style="font-size:12.0pt"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-family:"Courier New"">In our case one
            thread obtained a database connection and got stuck in
            read() (we think because of a StackOverflow).</span></p>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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. <br>
    <br>
    -Alan<br>
  </body>
</html>