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
Received on Thu Jun 14 20:19:04 2007