I (Julian Foad) wrote:
> To me this algorithm seems better.
Oops.
My argument for wanting something 'better' than the current trunk
implementation (which flushes after 4, 16, 64, 256 log entries) has
been blown out of the water. My argument depended on an assumption
that the rate of discovery of
Philip Martin wrote:
> "Bert Huijben" writes:
>> BTW 500 msec is about two or three the time you expect for google page of
>> results Why this arbritrary number?
>
> How do you explain the 2 and 2048 in the current code? They are all
> just arbitrary numbers. Make it 100ms instead of 500ms.
"Bert Huijben" writes:
> Nice idea on the concept, but this patch doesn't implement that behavior
>
> You will see the first result very fast. (No behavior change)
I don't understand, I see a behaviour change when I try it.
The first few writes with my patch:
[pid 8814] writev(17, [{"HTTP/1.1
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: maandag 16 maart 2015 18:10
> To: Julian Foad
> Cc: Bert Huijben; Marc Strapetz; dev
> Subject: Re: 1.9.x JavaHL: long initial delay when performing a log
>
> Julian Foad
Philip Martin wrote:
> Philip Martin writes:
>> Julian Foad writes:
>>> Flushing after the 1st, 2nd, 4th, 8th, ... log entry provides a crude
>>> approximation to the desired semantics which is more like "don't delay
>>> the first result more than a small fraction of a second, and don't
>>> delay t
Philip Martin writes:
> Julian Foad writes:
>
>> Flushing after the 1st, 2nd, 4th, 8th, ... log entry provides a crude
>> approximation to the desired semantics which is more like "don't delay
>> the first result more than a small fraction of a second, and don't
>> delay the next few results muc
Julian Foad writes:
> Flushing after the 1st, 2nd, 4th, 8th, ... log entry provides a crude
> approximation to the desired semantics which is more like "don't delay
> the first result more than a small fraction of a second, and don't
> delay the next few results much more than that either". In ot
I voiced some concerns on IRC (
http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-03-16#l80
) about the patch http://svn.apache.org/r1666965 nominated for
backport to 1.9.x. More details below.
Bert Huijben wrote:
> Julian Foad wrote:
>> Marc Strapetz wrote:
>>> On 16.03.2015 01:50, Ber
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: maandag 16 maart 2015 14:32
> To: Marc Strapetz
> Cc: Bert Huijben; dev
> Subject: Re: 1.9.x JavaHL: long initial delay when performing a log
>
> On 16 March 2015 at 11:00
On 16 March 2015 at 11:00, Marc Strapetz wrote:
> On 16.03.2015 01:50, Bert Huijben wrote:
>> Our server reports use an apr feature that buffers +- 8 KByte data before
>> sending out the first data.
>>
>> In this specific JavaHL case you ask for just the revision numbers.
>> (Unlike the C api, Jav
On 16.03.2015 01:50, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Once the log responds, a bunch of revisions are reported, so it seems
that there is some kind of caching of log records.
I've tested with latest 1.9.x sources on Windows but
> -Original Message-
> From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
> Sent: vrijdag 13 maart 2015 20:34
> To: dev@subversion.apache.org
> Subject: 1.9.x JavaHL: long initial delay when performing a log
>
> I'm experiencing a strange initial delay when performing a log using Jav
ev@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
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 perform
> -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'
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:5
[Since when are we top-posting? grr...]
On 13.03.2015 21:17, Bert Huijben wrote:
> Are you requesting the results in the same order in both cases? (I
> don't know what the arguments in your code represent)
>
> If you retrieve oldest to youngest some delay is expected as then
> first all interestin
Are you requesting the results in the same order in both cases? (I don't know
what the arguments in your code represent)
If you retrieve oldest to youngest some delay is expected as then first all
interesting revisions are fetched (youngest to oldest) and then
results+detailed are spooled back
18 matches
Mail list logo
