I have the exact same problem using SVNKit. I get a huge amount of
sockets opened when I do a resolution. They linger for about four
minutes (the windows default for TcpTimedWaitDelay) before they
disappear. I see other sockets vanish after a delay that is much shorter.
I added a line that obtains the underlying SVNClient and calls dispose()
on it but it didn't help.
Why are so many sockets being used? What can I do to limit this? Will it
help if I try to limit the number of client adapters that I make use of?
Would it be feasible to maintain a cache of client adapters (cached by
username/password since that seems to be the only relevant state that
they are holding)?
- thomas
Thomas Hallgren wrote:
> Hi Alexander,
> yes, I've read this thread before but I'm not sure if this is my
> problem. I'm hunting for ways to close more then we do now since it is
> starting to become a real problem at the receiving end. See:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=192385
>
> We have been using JavaHL mostly, hence my interest in the
> JhlClientAdapter. I'll try SVNkit also and see if there's a difference.
>
> Regards,
> Thomas Hallgren
>
> Alexander Kitaev wrote:
>> Hello Thomas,
>>
>> I once answered a question regarding sockets in TIME_WAIT state, may
>> be you'll find my answer useful:
>> http://www.nabble.com/Massive-TCP-client-sockets-on-TIME_WAIT-tf3874323.html
>>
>>
>> Alexander Kitaev,
>> TMate Software,
>> http://svnkit.com/ - Java [Sub]Versioning Library!
>>
>> Thomas Hallgren wrote:
>>> I'm looking at the source for the JhlClientAdapter class. It uses a
>>> SVNClientSynchronized. That class has a dispose() method. From what
>>> I can see, it never gets called and there's no way for me to get to
>>> it. Could this be the reason why I see so many sockets that are
>>> lingering in TIME_WAIT? We do implicitly create many instances of
>>> the client adapter.
>>>
>>> - thomas
>>>
>>>
>>>
>>> Mark Phippard wrote:
>>>> On 5/18/07, Thomas Hallgren <thomas@tada.se> wrote:
>>>>> The subject refers to a Buckminster bug
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=186092 that would like
>>>>> your input on.
>>>>>
>>>>> Buckminster uses several instances of ISVNClientAdapter (one per
>>>>> project
>>>>> that it resolves and eventually downloads). We use the following
>>>>> commands used on the adapter:
>>>>>
>>>>> getList(SVNUrl, SVNRevision, boolean)
>>>>> getContent(SVNUrl, SVNRevision)
>>>>> getDirEntry(SVNUrl, SVNRevision)
>>>>> checkout(SVNUrl, File, SVNRevision, boolean)
>>>>>
>>>>> This seems to result in a lot of TCP sockets lingering in a TIME_WAIT
>>>>> until they are closed due to a timeout. Is there clean-up needed
>>>>> on the
>>>>> ISVNClientAdapter to avoid this? Any other ideas?
>>>>
>>>> Our code lives several layers above something like that. You'd have
>>>> to write some tests that show your problem and take it up with the
>>>> adapter provider, JavaHL or SVNKit.
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
>>> For additional commands, e-mail: dev-help@subclipse.tigris.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
>> For additional commands, e-mail: dev-help@subclipse.tigris.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Thu Jun 14 18:57:50 2007