> On Mar 15, 2015, at 5:10 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>
>> On 15.03.2015 19:30, Bert Huijben wrote:
>>
>>> -----Original Message-----
>>> From: Marc Strapetz [mailto:marc.strapetz_at_syntevo.com]
>>> Sent: zondag 15 maart 2015 12:02
>>> To: dev_at_subversion.apache.org
>>> Subject: Re: 1.9.x JavaHL: long initial delay when performing a log
>>>
>>>> Same here on OSX. However, I can't any place in the code that would
>>>> cause the delay. I added similar time-printing code to the C++ part of
>>>> JavaHL and got extremely strange results:
>>>>
>>>> TestStatus (Java): 2015-03-13 22:21:40.403
>>>> svn_ra_get_log2: 2015-03-13T21:21:40.404731Z
>>>> callback: 2015-03-13T21:21:50.098592Z
>>>> invoke: 2015-03-13T21:21:50.098671Z
>>>> TestStatus (Java): 2015-03-13 22:21:50.098 1666354
>>>> return: 2015-03-13T21:21:50.099058Z
>>> I can confirm this delay in native code on Windows. I've tried to dig
>>> deeper into svn_ra_get_log2, however I'm lost at
>>> session->vtable->get_log ... is there some kind of "core loop" which
>>> processes incoming HTTP data, so we could place debug output there?
>>>
>>>> Now I'm really beginning to wonder what the native JavaHL implementation
>>>> is doing differently from libsvn_client.
>>> Just a vague idea: could there be some kind of input caching in
>>> low-level HTTP libraries before information is sent to Subversion and
>>> converted to log entries? Maybe JavaHL would initialize this caching
>>> differently than command line or not at all?
>> Are you using the same libraries in both cases?
>> (I think TortoiseSVN still explicitly disables ipv6 support in apr)
>>
>> One case where I sometimes get reports of slow operations is when the used hostname resolves to both an IPv4 and an IPv6 address. (Localhost is such a name on modern windows versions). Using 127.0.0.1 in your local testcode (or making sure the server process and network also work properly on ipv6) might help here. Declaring a specific host-/dns-name for Subversion, resolving to only the addresses really listening is usually the best approach... like it would be for a normal website.
>
> I reproduced this with trunk, built locally, with JavaHL using exactly
> the same RA libs as the comand line client.
>
Does JavaHL reverse the start/end revisions when calling the API? Sending a range of 0:HEAD to the server could explain the difference. That said, I'd assume you would have spotted that by now. I cannot imagine what else it could be, but I have also not tried this new ISVNRemote API.
Mark
Received on 2015-03-15 22:34:17 CET