On 18/05/2015 13:40, Stephen Dawkins wrote:
> On Mon, May 18, 2015 at 12:30 PM, Mark Thomas <ma...@apache.org> wrote:
>> Thanks. That rules out some possibilities for application error.
>>
>> When you get two threads writing to the response, if would be useful to
>> know which of the following those threads are:
>> - the Tomcat thread that handled the original request
>> - the application thread that wrote the response
>> - the Tomcat thread that the application dispatched to once the async
>> processing completed
>
> Here's what I've found:
>
> PID
> 15302 initial request received, initial application processing and
> request sent to a remote server asynchornously
> 15305 received response from remote server, more application processing
> 15305 HTTP response sent
> 15302 additional HTTP response sent, eventually fails with Broken Pipe
Bingo.
I think I have found the problem (well, a problem anyway). It looks like
there is a bug in javamelody.
Once a request/response has been put into async mode, control passes to
the async processing. i.e. from that point onwards the container should
not be writing to the response until the application returns control to
the container via a dispatch.
If you look at the this line of code [1], javamelody is flushing the
response. There needs to be an if (!request.isAsyncStarted()) {...}
around that code.
Also, looking at the various Response wrapper classes, none of them use
syncs / or volatile. Since control is passing between threads there is
the possibility of stale values being observed in the new thread. In my
experience actually seeing a stale value is pretty rare but it could happen.
HTH,
Mark
[1]
https://code.google.com/p/javamelody/source/browse/trunk/javamelody-core/src/main/java/net/bull/javamelody/MonitoringFilter.java#199
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
