On Wed, Jul 10, 2013 at 1:24 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
>
>> Can someone explain again why ra_serf / serf can't just resend
>> requests, with C-L, whenever it has received a 411? So (after we know
>> it's HTTP/1.1) send every request optimistically assuming chunked
>> encoding, and fallback whenever we get a 411 (and perhaps remember the
>> fallback, so we downgrade that entire connection / session).
>>
>> Why is that not possible? Is it because (a) it's too hard to implement
>> (lots of code paths all over the place), (b) we can't resend requests
>> because we don't have them available in the right place anymore after
>> sending, (c) it would potentially break some ordering things (really?
>> why?), (d) it would require serf 1.4 anyway, or (e) something else?
>
> Partly a), mostly c). It is relatively easy to do when ra_serf is
> processing requests syncronously. It gets much more difficult when
> ra_serf starts using pipelined requests as there may be outstanding
> requests when the 411 is received. I posted a patch that keeps track of
> outstanding requests and retries, it works in lots of cases but won't
> work in all cases.
Is pipelining optional within (ra-)serf's logic? I.e. can the "start
pipelining" switch simply be flipped a little bit later, once we're
sure that chunking works? That way we won't do an extra (synchronous,
but useless) request just for detecting chunkness, but we just
continue working synchronously with our normal (useful) requests a
tiny bit longer, before switching to pipelined mode. Still a small
performance hit in general, but it might be negligible.
Totally making abstraction of implementation complexity, of course ...
Of course, if you could make your patch work in all cases, Philip,
that would be even better :-).
--
Johan
Received on 2013-07-10 13:51:10 CEST