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. -- Brane
