On Wed, May 27, 2009 at 02:44:53PM +0200, Erik Huelsmann wrote:
> On Wed, May 27, 2009 at 2:41 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Wed, May 27, 2009 at 11:38:48AM +0200, Erik Huelsmann wrote:
> >> On Wed, May 27, 2009 at 1:28 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> >> > http://subversion.tigris.org/issues/show_bug.cgi?id=3347
> >> >
> >> >
> >> >
> >> > User stsp changed the following:
> >> >
> >> > What |Old value |New value
> >> > ================================================================================
> >> > Status|NEW |RESOLVED
> >> > --------------------------------------------------------------------------------
> >> > Resolution| |FIXED
> >> > --------------------------------------------------------------------------------
> >> >
> >> >
> >> >
> >> >
> >> > ------- Additional comments from stsp_at_tigris.org Tue May 26 16:27:59 -0700 2009 -------
> >> > I've finally looked at this again, and there was indeed code which
> >> > explicitly set the timeout for a socket to infinity when reading
> >> > data from a socket used for the svn:// protocol. Very bad.
> >>
> >> Actually, that was by design. Please ask Greg Hudson why, but I know
> >> he's been referring to timeouts as used by HTTP being a real pain in
> >> the butt for serious application development.
> >
> > Hmm... I've only changed ra_svn.
> > Does that have anything to do with HTTP?
>
> Yes: HTTP already had a time out like that. ra_svn explicitly didn't.
> So, now you changed things to be like HTTP - a situation Greg
> explicitly excluded in his original code. That's all I meant to say.
Ah, OK.
Well, we can set the timeout to anything we want.
But I'd say an infinate timeout is just not a good idea.
We can set it to 6 hours or so for all I care, but infinity is just
silly because it creates problems like issue #3347.
Currently the default timeout is used, and I don't even know what
that timeout is. But all tests pass over ra_svn, so we'll need more
specific information as to what the timeout requirements for ra_svn
are, and why.
A better comment in the original code would have helped a lot, btw.
It said /* Always block on read. */. Well, reading the code gives
you the same information as the comment. But I could not find any
information as to *why* this was done.
Stefan
Received on 2009-05-27 15:06:18 CEST