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)
- thomas
>
> On 6/14/07, Thomas Hallgren <thomas@tada.se> wrote:
>> 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
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Thu Jun 14 19:21:38 2007