Hello,
Thank you for your note, Karen. I fully agree with that, at least I read
exactly this while investigating what does TIME_WAIT state mean.
However, as far as I know there is an OS limit on amount of sockets
being in TIME_WAIT state. Am I wrong with that? I tried different
combinations of Socket options and found out that on Windows with JDK
1.4.2 setting SO_LINGER to "0" makes socket spend no time in TIME_WAIT
state. Any other values makes socket be in TIME_WAIT for default time
(about 60 seconds). I read that setting SO_LINGER to 0 means that socket
will be closed "forcefully" and some data being sent to the server may
be lost, but in Subversion client socket is closed only when data is
received from the server and there is no more data to send or read. I
hope it is safe to set SO_LIGNER to 0 in that case.
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
Karen Tracey wrote:
> Excuse me butting in, but what really is the problem here? TCP
> connections in TIME_WAIT are NOT an indication of any application-level
> cleanup issue. One side or the other of a TCP connection is always
> going to end up in TIME_WAIT even when the applications on both ends
> properly close their connections. It's part of the protocol, there to
> guard against delayed/resequenced packets from this connection
> disrupting subsequent connections between the same IP addresses using
> the same port numbers. TCP will time them out eventually.
>
> So >100 connections in TIME_WAIT is not a problem unless you believe
> that whatever the application was doing shouldn't have required >100
> individual connections in the first place. I know nothing of the code
> involved here but it seems possible that each call to
> getList/getContent/getDirEntry would use its own TCP connection, thus if
> you make 100+ calls you might wind up with about that many connections
> lingering in TIME_WAIT for a bit. Unless you think that many
> connections should NOT have been required for the calls made, then I
> don't see the problem here.
>
> Karen
>
> At 01:40 PM 6/14/2007, Mark Phippard wrote:
>> On 6/14/07, Thomas Hallgren <thomas@tada.se> wrote:
>>> Mark Phippard wrote:
>>> > On 6/14/07, Thomas Hallgren <thomas@tada.se> wrote:
>>> >> Mark Phippard wrote:
>>> >> > If you are constructing them yourself, try just making one.
>>> That is
>>> >> > the change I am playing with.
>>> >> >
>>> >> > Your best bet would be to write some kind of test code directly
>>> >> > against SVNClient and then ask the Subversion devs.
>>> >> >
>>> >> > Mark
>>> >> >
>>> >> OK, I'm cross-posting this to dev@subversion.tigris.org.
>>> >>
>>> >> I tried using one single instance of the client adapter and it
>>> doesn't
>>> >> help. It seems that all methods that I call opens up a socket that
>>> then
>>> >> lingers for four minutes. The number of sockets in TIME_WAIT quickly
>>> >> increase to >100.
>>> >>
>>> >> These are the methods that I call during resolution:
>>> >>
>>> >> getList(SVNUrl, SVNRevision, boolean)
>>> >> getContent(SVNUrl, SVNRevision)
>>> >> getDirEntry(SVNUrl, SVNRevision)
>>> >
>>> > svnClientAdapter is a pretty thin wrapper around JavaHL, but it would
>>> > still be useful if you wrote some test code that used only the JavaHL
>>> > classes and created the same problem.
>>> >
>>> I'll try to find some time to do that.
>>>
>>> > You are using SVN 1.4.3? What communication protocol to what version
>>> > of the server?
>>> I'm using Subclipse 1.0.5 or 1.2.2. Same problem in both and same
>>> problem with both JavaHL and SVNKit. I have Subversion 1.4.2 installed
>>> on my machine.
>>
>> It really baffles me that JavaHL and SVNKit could both have the
>> problem given that they do not share any code.
>>
>>
>>> > Eclipse.org is running svn+ssh, are you also testing this with other
>>> > servers?
>>> >
>>> For these tests I've used svn and not svn+ssh against Eclipse.org. The
>>> person who originally reported the problem was using another server.
>>
>> How are you determining the sockets that are open? What commands or
>> tools are you using? What client OS?
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 14 21:30:09 2007