Greg Hudson wrote:
> I'm actually unsure why you need more than one connection total. You
> can be sending GETs to the server as you're parsing the REPORT response,
> then start handling GET responses as soon as the REPORT response is
> done. The server should be sending data full-time, with only one
> round-trip delay at the beginning to send off the first GET request.
I'm not really sure how the whole pipelining thing works, but we (I)
made fixes to Subversion's diff/merge code which caches the whole REPORT
response to disk before processing it and doing the GET thang. I did
this because if a GET sent off in the middle of REPORT processing took
too long to get fully handled, Apache dropped the connection on the
REPORT (thinking "inactive client").
We're not in the exact same scenario with ra_serf, but I'm wondering if
we're not in something similar. What happens in the following scenario?
c->s: REPORT request
s->c: REPORT response
# client starts parsing the REPORT response, and firing off GETs
c->s: GET #1
c->s: GET #2
...
[more than httpd Timeout seconds goes by]
c->s: GET #496
...
# client finishes parsing REPORT, but that first GET long ago has
# been sitting around unhandled for too long. Did Apache drop
# that connection?
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Feb 17 16:10:23 2006