Hello Mark,
I think with SVNKit currently it is not safe to call SVNClient.dispose()
when there are other instances of SVNClient exist and used. The reason
is that currently SVNKit closes all sessions and open connections that
were established at runtime in dispose method, not only those created
through this very instance of SVNClient.
I hope to fix this problem in the next version of SVNKit that we're
going to publish on Monday.
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
Mark Phippard wrote:
> I believe we stopped using the SVNClientSynchronized class before the
> 1.0.0 release. Where do you see that class being used?
>
> It just calls the dispose method of SVNClient, which we do use. But I
> do not believe its dispose() method needs to be called regardless.
>
> Mark
>
>
> On 6/14/07, Thomas Hallgren <thomas@tada.se> 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
Received on Thu Jun 14 20:44:38 2007