> On Mar 15, 2015, at 5:10 PM, Branko Čibej <br...@wandisco.com> wrote: > >> On 15.03.2015 19:30, Bert Huijben wrote: >> >>> -----Original Message----- >>> From: Marc Strapetz [mailto:marc.strap...@syntevo.com] >>> Sent: zondag 15 maart 2015 12:02 >>> To: dev@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
