Thanks Jan, you’ve got the analysis correct from my perspective. I agree with Alexander that setting the buffer to 0 is the preferred way to control the instance-level configuration, though I need to triple-check that it does exactly restore the original behavior across all the endpoints. Assuming that checks out we can start with #3 and fall back to #2 with a one-line change in the codebase.
Allowing per-query configuration is certainly possible but I think we need to be cognizant of throwing too many magic parameters at users. Maybe we can defer that until we get additional feedback about the magnitude of the breakage here. Adam > On Jul 22, 2015, at 6:39 AM, Alexander Shorin <kxe...@gmail.com> wrote: > > 4. +1 > 3. Is possible if chunk size in config set to zero. Using query > parameter to control that option is not a good idea. So server > administrator may decide if his clients needs in such compatibility or > not. > -- > ,,,^..^,,, > > > On Wed, Jul 22, 2015 at 1:23 PM, Jan Lehnardt <j...@apache.org> wrote: >> Heya, >> >> nice one Adam! :) >> >> As I see it, here are our options: >> >> 1. don’t apply this >> >> 2. apply this, but disable it by default and let people opt in, either >> - on a per-request basis like _all_docs?multichunkinator=true >> - on a per-instance config basis: [httpd] multichunkinator=true >> >> 3. apply this and enable it by default and let people opt out as per 2. with >> false as the option >> - this requires breaking BC and documenting the upgrade path >> >> 4. apply this, enable by default and leave no way back >> - BC break needs to be set up as per 3 >> >> For either 2. or 3. we get the opportunity of a nice bikeshed over the name >> of the query param / config value. >> >> I think 1. is not a good idea. >> >> 2. is a good choice, if we discover that this would cause major >> inconveniences for lots of people in the field (we then could think about >> swapping this to be the default in 3.0.0). >> >> 4. seems needlessly aggressive. >> >> Given that this is not a major issue (as per our information now), I’d be >> confident with 3. making 2.0 the BC breaking version number. >> >> Once 2.0.0 betas come out, I’d like to work with all the major CouchDB >> clients to ensure compatibility, we should find out then, the latest, >> whether we need to reverse our stance to, say, 2. >> >> >> This will require some extra work to allow either behaviour and >> configuration, but I think that’d be worth it. >> >> Did I miss anything? >> >> Best >> Jan >> -- >> >> >> >> >> >>> On 21 Jul 2015, at 17:42, Adam Kocoloski <kocol...@apache.org> wrote: >>> >>> Hi all, >>> >>> CouchDB uses the chunked transfer-encoding capability of HTTP/1.1 to stream >>> _all_docs, _changes, _view and similar responses to clients. We have always >>> sent each row of these responses in a dedicated chunk. Coalescing multiple >>> rows into a single chunk is more efficient and yields throughput >>> improvements of approximately 30%, but this could break clients that have >>> implicitly relied on the row-per-chunk organization. >>> >>> So — do any of you knowingly rely on this behavior? How difficult would it >>> be to accommodate this change? Thanks, >>> >>> Adam >>> >>> P.S. more details on this topic can be found in COUCHDB-2724 and associated >>> Pull Requests: >>> >>> https://issues.apache.org/jira/browse/COUCHDB-2724 >>> https://github.com/apache/couchdb-couch-mrview/pull/22 >>> https://github.com/apache/couchdb-chttpd/pull/38 >>> https://github.com/apache/couchdb-mango/pull/9 >>> >> >> -- >> Professional Support for Apache CouchDB: >> http://www.neighbourhood.ie/couchdb-support/ >> >
