Hello Marc,
>> 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.
Both JavaHL and SVNKit works against the same server (svnserve). Servers
prior to 1.4.0 wasn't able to reuse the same connection (socket) for
several subsequent operations (and each higher level operation may
require several low level ones) on the same repository. 1.4.0 version
introduced "reparent" protocol command that allowed to reuse the same
connection for different operations against the same repository.
I think the time closed socket spends in TIME_WAIT mode depends on the
way socket is created. There is SO_LIGNER option:
/**
* Specify a linger-on-close timeout. This option disables/enables
* immediate return from a <B>close()</B> of a TCP Socket. Enabling
* this option with a non-zero Integer <I>timeout</I> means that a
* <B>close()</B> will block pending the transmission and acknowledgement
* of all data written to the peer, at which point the socket is closed
* <I>gracefully</I>. Upon reaching the linger timeout, the socket is
* closed <I>forcefully</I>, with a TCP RST. Enabling the option with a
* timeout of zero does a forceful close immediately. If the specified
* timeout value exceeds 65,535 it will be reduced to 65,535.
* <P>
* Valid only for TCP: SocketImpl
*
* @see Socket#setSoLinger
* @see Socket#getSoLinger
*/
public final static int SO_LINGER = 0x0080;
So far SVNKit doesn't set this option. I've just checked and found that
by default SO_LINGER is disabled, at least on Windows. May be it makes
sense to set it.
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
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?
>
---------------------------------------------------------------------
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:59:46 2007