You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2013/06/03 11:10:10 UTC
Re: APR/native errors with non-blocking I/O
On 31/05/2013 20:34, Mark Thomas wrote:
> The other end does hang up but it wasn't clear if that was the root
> cause or the result. The client reports invalid chunked encoding.
> I'll look into the client code.
I made some progress with this over the weekend. I'm still not sure
where the problem is but I have a clearer idea of what is happening.
I've modified the test to send a sequence of "0123456789ABCDEF0123..."
rather than "XXX..." so it is easier to spot when / if the data is
corrupted.
I've also switched the client to a simple socket based client so I can
examine the bytes directly.
What this shows is that towards the end of the 5MB, the client receives
a chunk that is long than it should be and the chunk shows corruption in
that the expected sequence is broken.
The total bytes the server thinks it sent (including headers, chunking
overhead etc.) does not agree with the total bytes received by the client.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native errors with non-blocking I/O
Posted by Rainer Jung <ra...@kippdata.de>.
On 03.06.2013 14:54, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:markt@apache.org]
>> Subject: Re: APR/native errors with non-blocking I/O
>
>> 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;
>> }
>
> Looks reasonable - just get rid of the else keywords, since each condition ends with a return.
+1
I guess this is for sendb and also sendbb?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: APR/native errors with non-blocking I/O
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Mark Thomas [mailto:markt@apache.org]
> Subject: Re: APR/native errors with non-blocking I/O
> 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;
> }
Looks reasonable - just get rid of the else keywords, since each condition ends with a return.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native errors with non-blocking I/O
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org