On Wed, Dec 4, 2019 at 11:51 AM Mark Thomas <ma...@apache.org> wrote:
> On 04/12/2019 10:25, Rémy Maucherat wrote: > > On Wed, Dec 4, 2019 at 11:11 AM Mark Thomas <m...@homeinbox.net > > <mailto: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). > > Could we record the start time of the write (or similar) and adjust the > timeout passed the Poller accordingly? > Yes, it's usually this kind of strategy, but it's complex :( I may keep the wait(timeout) instead but make the processing of the failed more robust. Rémy