On 28/11/2018 15:00, ma...@apache.org wrote: > Author: markt > Date: Wed Nov 28 15:00:06 2018 > New Revision: 1847646 > > URL: http://svn.apache.org/viewvc?rev=1847646&view=rev > Log: > Fix possible cause of intermittent TestCoyoteOutputStream failures.
I thought this would be worthy of a longer explanation than seemed appropriate for a commit message. I have tried to recreate the issue locally without success. I was able to recreate it occasionally running the tests on silvanus.a.o (the CI machine that runs all our buildbot jobs). I captured a network trace that confirmed that this was a server side bug. What I saw was a corrupted response. The headers and first chunk were correct but rather than the 5 bytes of the end chunk I saw the other 8187 (8192-5) bytes of the buffer. It was clear the buffer was configured for write when it was being read. I then tried to figure out how this could happen with a view to reproducing the issue. There were a lot of dead ends during which I noticed that the write pattern varied when I added additional debug statements. I discovered that, depending on timing, the NIO2 endpoint would sometimes use a gathering write when performing a non-blocking flush. There is a non-blocking flush just before the switch back to blocking I/O (after the dispatch to end the async component) and it looked to be possible that the gathering write could still be in progress when the following blocking write was performed. That in turn meant that one of the buffers used by the gathering write could be modified during the following blocking write. However, my current understanding of the code is that the gathering write will have written all the data from the buffer that is used by the following blocking write before that blocking write occurs. So I may have missed the root cause completely. It depends a lot on the internal workings of the AsynchronousSocketChannel. On balance, I decided to commit this fix as there does appear to be a bug here. Hopefully, it is the root cause of the intermittent TestCoyoteOutputStream failures. If it is, great. If not, I'll keep looking. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
