On Tue, Jun 12, 2012 at 1:18 PM, Justin Erenkrantz
<justin_at_erenkrantz.com> wrote:
> On Tue, Jun 12, 2012 at 1:01 PM, Lieven Govaerts <lgo_at_mobsol.be> wrote:
>> That seems strange, serf_context_run is not documented to return
>> APR_EGAIN. While the response handler can return APR_EAGAIN, serf
>> itself will translate this to APR_SUCCESS. As a result, ra_serf
>> doesn't expect it and - rightfully IMO - treats it as an error.
>>
>> Are you trying to solve this issue:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4175 ?
>
> Not quite.
>
> While the 404 code is what we're looking at right now (Ivan & Johan
> are to my right trying to debug it)...this patch is about EAGAIN
> always being returned from the network layer.
>
> FWIW, ra_serf will still cause a crash even with this patch in the 404...
>
>> If so, the solution - as discussed in
>> http://svn.haxx.se/dev/archive-2012-05/0133.shtml - lies in getting
>> the response handler not labeling the request as done until the
>> complete response has been read, including retrying on APR_EAGAIN.
>
> I looked at that thread...but, it doesn't make much sense. =(
>
> How is it supposed to retry? ra_serf needs to let the context_run
> loop execute again to pull off the remaining bits from the socket.
> Without the patch, we treat EAGAIN as a fatal error and it gets
> returned all the way to the client. -- justin
Hm, I see now, it's not the return code of the response handler here,
but the apr error wrapped in the svn error object.
So why would we insist on treating EAGAIN as error in the response
handler? There doesn't seem to be any added value of passing this
expected return code as error all the way back to the look.
Lieven
Received on 2012-06-12 13:57:14 CEST