Chuck,
On 5/31/13 5:46 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Subject: Re: APR/native errors with non-blocking I/O
>
>> I'm pretty sure that sterror is thread safe: it should just return a
>> stati
On 03.06.2013 14:54, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@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)
&
> From: Mark Thomas [mailto:ma...@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 == T
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.
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
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: APR/native errors with non-blocking I/O
> I'm pretty sure that sterror is thread safe: it should just return a
> static char*.
Would that it were that simple. Seriously, it's not thread
On 31/05/2013 21:42, Caldarale, Charles R wrote:
>> From: Rainer Jung [mailto:rainer.j...@kippdata.de]
>> Subject: Re: APR/native errors with non-blocking I/O
>
>> Compile and have fun.
>
> Or we could talk about Mark's familiarity with C :-)
That will be
Chuck,
On 5/31/13 4:42 PM, Caldarale, Charles R wrote:
>> From: Rainer Jung [mailto:rainer.j...@kippdata.de]
>> Subject: Re: APR/native errors with non-blocking I/O
>
>> Compile and have fun.
>
> Or we could talk about Mark's familiarity with C :-)
>
>&g
Rainer,
On 5/31/13 4:35 PM, Rainer Jung wrote:
> On 31.05.2013 21:34, Mark Thomas wrote:
>> "Caldarale, Charles R" wrote:
>>
From: Mark Thomas [mailto:ma...@apache.org]
Subject: APR/native errors with non-blocking I/O
>>>
>>> Assuming these are negative errno values:
>>>
On OSX th
> From: Rainer Jung [mailto:rainer.j...@kippdata.de]
> Subject: Re: APR/native errors with non-blocking I/O
> Compile and have fun.
Or we could talk about Mark's familiarity with C :-)
> IMHO we don't have that in the code to output text instead of cryptic
> number
On 31.05.2013 21:34, Mark Thomas wrote:
> "Caldarale, Charles R" wrote:
>
>>> From: Mark Thomas [mailto:ma...@apache.org]
>>> Subject: APR/native errors with non-blocking I/O
>>
>> Assuming these are negative errno values:
>>
>>> On OSX the error code is -32
>>
>> Broken pipe.
>>
>>> On Linux th
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: RE: APR/native errors with non-blocking I/O
> Where might I find a list of these error codes.
It's a bit old, but still pretty accurate:
http://www.ioplex.com/~miallen/errcmpp.html
- Chuck
THIS COMMUNICATION MAY CONTAI
"Caldarale, Charles R" wrote:
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Subject: APR/native errors with non-blocking I/O
>
>Assuming these are negative errno values:
>
>> On OSX the error code is -32
>
>Broken pipe.
>
>> On Linux the error code is -104
>
>Connection reset by peer.
>
>Did
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: APR/native errors with non-blocking I/O
Assuming these are negative errno values:
> On OSX the error code is -32
Broken pipe.
> On Linux the error code is -104
Connection reset by peer.
Did the other end go away?
Can you get a packet
14 matches
Mail list logo