On Wed, Dec 4, 2019 at 11:11 AM Mark Thomas <m...@homeinbox.net> wrote:
> On 04/12/2019 09:58, Mark Thomas wrote: > > On 04/12/2019 09:27, Mark Thomas wrote: > >> On 04/12/2019 07:55, Rémy Maucherat wrote: > > > > <snip/> > > > >>> Blocking is also used for HTTP/2 where it seems to work. If the write > >>> buffer is full, 0 bytes are written and the socket is indeed passed to > >>> the poller but until the operation is complete it is supposed to be > >>> blocked here: > >>> > https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/net/SocketWrapperBase.java#L1430 > >> > >> That helps a lot. I can try and see why things aren't blocking there. > > > > Some progress. The thread does wait there but it is getting released too > > early. I'm guessing something is calling notify(). I'm planning to add > > more debug to figure out what / why. > > Found it. > > The wait on line 1430 (see link above) waits for the write/read timeout. > The problem was that this wait was timing out, allowing the code to > continue before the Poller timed out a few milliseconds later and called > the CompletionHander which ultimately sets the SendResult the WebSocket > code is looking for. > > I'm currently testing using: > > state.wait() > > rather than > > state.wait(unit.toMillis(timeout)); > Well, it would remove the enforcement of the overall timeout since the write could be made up of multiple operations. But I think I get the idea that it's imperfect (once the IO is running, you cannot stop it this way). Rémy
