On Sun, Aug 28, 2011 at 4:22 PM, Stefan Fritsch <[email protected]> wrote: > On Sunday 28 August 2011, Ruediger Pluem wrote: >> On 08/28/2011 11:12 AM, Stefan Fritsch wrote: >> > On Saturday 27 August 2011, Eric Covener wrote: >> >> lots of threads. Trying to resynch here, not a vote. >> >> >> >> For 2.2: >> >> >> >> [ ] everything in 2.3 (brigade_copy, mergeing, validation, ???) >> > >> > We don't know how many clients are broken by merging. >> > >> >> [X ] just the cheap brigade copy + sum_len > clen failsafe >> > >> > I think this should be sufficient. >> >> I agree, but maybe we should pass the brigade down the chain after >> each range or at least after a specific number of ranges to avoid >> piling up too much buckets in the byte range filter. > > OK, I have added that to 2.3, too. > > At http://people.apache.org/~sf/byterange-no-merge.2.2.diff is an > adjusted version that has all range merging removed (but apart from > that, all recent changes from 2.3 are in). The code to parse ranges > into an array is not really necessary, but it keeps the diff to 2.3 > small. Is that the way to go?
+1 in concept, haven't reviewed. Test drove and looked good, but wondering if we should have a single merging switch in the trunk version and only flip it when we backport directly? I only worry about divergence between the two and the cost/risk of manually merging if there is continued churn. It did not look especially clean to make the merge respect a big on/off switch though either. I'd also like to dump the MaxRanges after it stews a bit, in a separate proposal, as the conensus in an early thread was that some bound beyond header length was desired. > Test byterange3.t fails, because it assumes range merging. Any idea > how to limit that test to >= 2.3.15? It is rather different from the > other tests (no explicit plan). I put a kludge in for this that at least keeps it from blowing up on old releases/versions.
