On 03/06/2013 10:10, Mark Thomas wrote:
> My next step is to look more closely at the server code (the issue is
> sensitive to timing so it can be tricky to add debug code and still see
> the issue) to figure out if I am misusing the API or if there might be
> an APR/native bug at the root of this.
I've finally figured out what is going on. The non-blocking write test
is more likely to hit this bug because it uses a slow client so the
buffers all fill up. In theory, any of the non-blocking code could hit this.
The problem is actually quite simple. When the buffers are almost full
the next write triggers an APR_STATUS_IS_EAGAIN. However, some of the
requested data will have been written. How much data is not available
through the current API. The Tomcat code assumes no data was written and
hence ends up duplicating part of the previous write.
Thoughts on how to extend the tc native API?
I'm thinking something along the lines of the following:
if (ss == APR_SUCCESS)
return (jint)sent;
else if ((APR_STATUS_IS_EAGAIN(ss) || ss == TCN_EAGAIN) && sent > 0) {
return (jint)sent;
} else {
TCN_ERROR_WRAP(ss);
return -(jint)ss;
}
to fix the immediate problem.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
