On Mon, Apr 8, 2019 at 10:49 PM Mark Thomas <ma...@apache.org> wrote:
> On 08/04/2019 20:38, Mark Thomas wrote:
>
> <snip/>
>
> > I'm not sure. Do you have the complete logs for those tests? I'd like to
> > look at everything sent from the client to the server for stream 3.
>
> Thanks for the logs (sent off-list). They didn't line up with my code
> which made me realise I was working with the 8.5.x branch rather than
> master. As soon as I switched to the right branch I was able to exploit
> the timing gap I thought I'd found.
>
> > I'd got as far as thinking that the server wasn't (always) marking
> > stream 3 as half-closed and my next steps are to try and figure out why.
>
> The short version is that the thread (A) parsing the incoming frames
> first signals end of headers. This starts the container thread (B) with
> a new StreamProcessor to process the request.
>
> Thread A then continues and signals end of stream.
>
> If Thread B processes the request, writes the response and gets as far
> as the new check I added before thread A signals end of stream, you see
> the reset.
>
> This only happens with NIO2.
>
> There should be a sync that prevents this. There is in the non-async case.
>
> Next steps are to figure out which sync is missing and where it needs to
> go.
>
Thanks for the fix. I can indeed see that HttpParser.onHeadersComplete has:
output.headersEnd(streamId); // <- dispatch is done here
if (headersEndStream) {
output.receivedEndOfStream(streamId);
headersEndStream = false;
}
I guess it's possible to rely on syncing but normally thread dispatching
should not occur until after the state is properly set, it's simply safer.
Rémy
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
