Ok, so I did some tweaking and found a workaround that will keep me in
business for the time being.
I tried setting MaxKeepAliveRequests to 0, and it got a lot farther than
before, but it now found a new point to consistently crap out at (same
error). So ... I turned off KeepAlive altogether, and that seems to do
the trick. I'm sure it's going to get me in trouble with scalability,
but that's a worry for another day. Do you think it would make sense to
open a bug for this and I'll attach information when I have tim eto do
some more investigation on the matter?
Thanks for your help so far!
> -----Original Message-----
> From: Klaus Rennecke [mailto:firstname.lastname@example.org]
> Sent: Saturday, June 26, 2004 6:43 AM
> To: Rob van Oostrum
> Cc: email@example.com
> Subject: Re: large checkout/update/switch fails (svn: The
> REPORT request
> returned invalid XML in response)
> Rob van Oostrum wrote:
> >I dumped the repository and loaded it into a sandbox. Ran
> svnserve and
> >tried a checkout ... runs like a charm. Much faster than
> mod_dav_svn and
> >checkout succeeded in one go. So I'd say it's a safe bet the
> problem is
> >somewhere in mod_dav_svn ... hope this helps ...
> Hmm just a thought - there is a maximum count of requests
> over one HTTP
> 1.1 connect session.
> Do you know how many files were successfully checked out?
> Can you do a cross-check with the same amount of files, but
> with smaller
> (near zero) size to them?
> Does it get any further if you raise MaxKeepAliveRequests
> above 100 (or
> set to 0 for unlimited)?
> Granted, the default of 100 sounds too low to not have
> occured earlier.
> But maybe it's a combination of this limit and another limit on
> reconnects in the client code . . .
> The documentation sounds a bit as if would be good to raise that
> parameter for svn anyway.
> Mind you, this is just a wild guess. I haven't got around
> checking these
> guesses against the implementation, my C skills have become
> quite rusty.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jun 28 16:50:43 2004