You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Christian Daudt <cs...@daudt.org> on 2003/03/05 22:41:45 UTC

socket read timeout

Hi,
 I tracked down the problem I was having last week with importing many linux 
trees via http. The problem is that the neon code has a read timeout of 2 
minutes currently (in neon/src/ne_socket.c line 142) and to do the merge I 
needed a timeout higher than that. After going all out and changing that to a 
30 minute timeout, I was able to complete the merge process via http 
sucesfully. I'm not submitting a patch because I have no idea what the proper 
upper bound would be for this. My mod fixed my problem but the eventual 
solution should probably be that the server send periodic keepalives of sorts 
so that the client can properly distinguish between network/computer outages 
and the server just taking a long time to finish what it is doing. Any 
thoughts?

 cheers,
   csd

PS: In the process, my client svn grew to 2GB... Lots of swapping...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: socket read timeout

Posted by mark benedetto king <mb...@boredom.org>.
On Wed, Mar 05, 2003 at 02:41:45PM -0800, Christian Daudt wrote:
> Hi,
>  I tracked down the problem I was having last week with importing many linux 
> trees via http. The problem is that the neon code has a read timeout of 2 
> minutes currently (in neon/src/ne_socket.c line 142) and to do the merge I 
> needed a timeout higher than that. After going all out and changing that to a 
> 30 minute timeout, I was able to complete the merge process via http 

This is configurable in ~/.subversion/servers (http-timeout).

> sucesfully. I'm not submitting a patch because I have no idea what the proper 
> upper bound would be for this. My mod fixed my problem but the eventual 
> solution should probably be that the server send periodic keepalives of sorts 
> so that the client can properly distinguish between network/computer outages 
> and the server just taking a long time to finish what it is doing. Any 
> thoughts?
> 
>  cheers,
>    csd
> 

One option would be to turn on TCP Keep-Alives, and then wait "forever".
Personally, I think this behaviour should be the default.


> PS: In the process, my client svn grew to 2GB... Lots of swapping...
> 

There are some changes in progress that should address the scalability
of svn merge.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org