I changed my code so that it temporarily will bypass the cache in the
SVNClientManager.createSVNClient() method and instead create a new
instance of the correct client adapter every time I ask for it. When I
do that, everything works just fine. Well almost. It runs fine until I
start obtaining clients from known repositories. The method
SVNRepositoryLocation.getSVNClient() also uses the createSVNClient()
method so it will get the same client instance every time. This results
in clashes when the client receives different username/password settings
from different connections. I will encounter this regardless of client
implementation.
In essence, this is blocking me from using the new Sublipse version. I
can only bypass the SVNClientManager in experiments since I loose the
config directory setting and I cannot bypass the
SVNRepositoryLocation.getSVNClient() since that's where the password for
the location is assigned.
Do you want me to file a JIRA on this?
Regards,
Thomas Hallgren
Thomas Hallgren wrote:
> Thanks Andrew,
> I'm on a x86_64 machine and I use 64-bit Java. I didn't find any
> binaries for that. I tried compiling the source but ran into apr
> incompatibility problems. Rather then divining in to that further, I
> took another approach and tried to debug the SVNKit implementation.
>
> I immediately ran into problems there too since the source found here:
> http://subclipse.tigris.org/svn/subclipse/tags/subclipse/1.3.16/svnClientAdapter
> doesn't compile. Apparently, the svnjavahl.jar that is bundled with
> the source revision is incompatible with the source. I get compilation
> errors such as:
>
> "The method copy(CopySource[], String, String, boolean, boolean) in
> the type SVNClientInterface is not applicable for the arguments
> (CopySource[], String, String, boolean, boolean, null)"
>
> One observation I made when looking at the code was that the
> SVNClientManager is caching its instances so in spite of the method
> name createSVNClient(), it actually returns the same instance every
> time. This is probably not ideal since the client, at least in the
> SVNKit implementation, doesn't appear to be thread safe. In fact, even
> if it were, it would then have to serialize all accesses which would
> be really bad, at least for us. We've found that in many cases, four
> simultaneous threads operate almost four times faster then one.
>
> Regards,
> Thomas Hallgren
>
>
> Andrew Vaughan wrote:
>> Hi Thomas
>>
>> On Tuesday 03 June 2008 18:26, Thomas Hallgren wrote:
>>
>>> Hi Mark,
>>> I tried this new release in Buckminster and ran into some fairly
>>> serious
>>> problems that seems to stem from concurrency issues in the client
>>> adapter.
>>>
>>> Buckminster normally performs resolution in multiple threads (four of
>>> them typically) and each thread will read individual files from remote
>>> SVN repositories using the ISVNClientAdapter.getContent() method. If I
>>> limit the number of threads to one, everything works as expected but
>>> without that limitation, I get strange errors such as files being
>>> considered directories or incorrect content in files that I
>>> successfully
>>> read. The 1.2.4 release does not have this problem.
>>>
>>> I'm using the SVNKit Beta at present as the threshold of getting JavaHL
>>> 1.5.0RC7 to run seems a bit high. I can't even find it ;-)
>>>
>>
>> Source
>> http://subversion.tigris.org/servlets/NewsItemView?newsItemID=2119
>>
>> Binaries (Windows + Redhat)
>> http://merge-tracking.open.collab.net/servlets/ProjectProcess;jsessionid=7E0ADF3D3F07B6234BEDD3C73DA464F1?pageID=3711
>>
>>
>> HTH
>> Andrew
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
>> For additional commands, e-mail: dev-help_at_subclipse.tigris.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
> For additional commands, e-mail: dev-help_at_subclipse.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-06-03 13:08:58 CEST