Excessive use of TCP sockets

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?

Regards,
Thomas Hallgren

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

On 5/18/07, Thomas Hallgren <thomastada.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.


-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

Hello,

If you're using SVNKit, please consider using latest version
from 
'trunk' - there were number of bugs fixed that could resolve
mentioned 
problem. Latest SVNKit binaries could be found at 
https://teamcity.svnkit.
com/

Please let me know if the problem persist even with the
latest version 
of SVNKit, thanks!

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java
[Sub]Versioning Library!

Thomas Hallgren 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?
> 
> Regards,
> Thomas Hallgren
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
> For additional commands, e-mail: dev-helpsubclipse.tigris.org
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

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 <thomastada.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-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

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 <thomastada.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 <thomastada.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-unsubscribesubclipse.tigris.org
> For additional commands, e-mail: dev-helpsubclipse.tigris.org
>
>


-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

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-cl
ient-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 <thomastada.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-unsubscribesubclipse.tigris.org
> For additional commands, e-mail: dev-helpsubclipse.tigris.org
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

My fault. I was looking at the source from
tags/svnClientAdapter/0.9.4. 
I incorrectly assumed that to be the latest since I didn't
realize that 
the module had moved to below the subclipse folder.

But now I'm looking at a more recent version and the
question remains. 
But this time for the SVNClient.dispose().

- thomas



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 <thomastada.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 <thomastada.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-unsubscribesubclipse.tigris.org
>> For additional commands, e-mail: dev-helpsubclipse.tigris.org
>>
>>
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

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-cl
ient-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 <thomastada.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-unsubscribesubclipse.tigris.org
>> For additional commands, e-mail: dev-helpsubclipse.tigris.org
>>
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
> For additional commands, e-mail: dev-helpsubclipse.tigris.org
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

I do not know if it is causing these TCP connection time
outs, but I
talked to the SVN developers and we should be calling the
dispose()
method.

The change I am looking into is to only ever create a
single
JhlClientAdapter object ... then we would not need to call
this
method.

I never understood why it did not work this way already.

Mark



On 6/14/07, Thomas Hallgren <thomastada.se> 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-cl
ient-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 <thomastada.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-unsubscribesubclipse.tigris.org
> >> For additional commands, e-mail: dev-helpsubclipse.tigris.org
> >>
> >>
> >
> >
------------------------------------------------------------
---------
> > To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
> > For additional commands, e-mail: dev-helpsubclipse.tigris.org
> >
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
> For additional commands, e-mail: dev-helpsubclipse.tigris.org
>
>


-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org

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-cl
ient-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 <thomastada.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-unsubscribesubclipse.tigris.org
>>> For additional commands, e-mail: dev-helpsubclipse.tigris.org
>>>
>>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
>> For additional commands, e-mail: dev-helpsubclipse.tigris.org
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
> For additional commands, e-mail: dev-helpsubclipse.tigris.org
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubclipse.tigris.org
For additional commands, e-mail: dev-helpsubclipse.tigris.org