[
https://issues.apache.org/jira/browse/COUCHDB-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645596#comment-15645596
]
Robert Frazier commented on COUCHDB-3227:
-----------------------------------------
Note that I did the above testing on a three node cluster. I'd imagine the
behaviour of 6) would probably be weirder still if I'd done it on, say, a 6
node cluster.
> Inconsistent/odd behaviour of the new ?stable=X&update=Y API
> ------------------------------------------------------------
>
> Key: COUCHDB-3227
> URL: https://issues.apache.org/jira/browse/COUCHDB-3227
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Reporter: Robert Frazier
>
> In COUCHDB-3063, the stale view-query mechanism was effectively deprecated in
> favour of two parameters that better express the independent concerns of
> getting stable results and whether or not to update the view. This replaced
> three parameter combinations with a total of six, meaning that there are now
> three new ways of querying views that were previously unavailable to us. On
> testing, the behaviour of two of the new combinations
> {{?stable=true&update=true}} and {{?stable=false&update=lazy}} seems a bit
> odd. This is best summarised by the following table (which I hope gets
> rendered as I expect it to...):
> ||#|| New API || Old API || Observed Behaviour (q=8,n=3) ||
> |1|{{?stable=true&update=true}}|Didn't exist|Blocks; Only 8 ushard indexers
> started
> |2|{{?stable=true&update=false}}|{{?stale=ok}}|Non-blocking; no indexers
> started; Matches previous API
> |3|{{?stable=true&update=lazy}}|{{?stale=update_after}}|Non-blocking; 24
> indexers started; Matches previous API
> |4|{{?stable=false&update=true}}|stale not defined|Blocks; 24 indexers
> started; Matches previous API
> |5|{{?stable=false&update=false}}|Didn't exist|Non-blocking; no indexers
> started
> |6|{{?stable=false&update=lazy}}|Didn't exist|Non-blocking; 8 indexers
> started, all same node
> I'd argue that combinations 1 and 6 in the above should probably start a full
> complement of q*n indexers. That said, maybe these behaviours are useful in
> some way? They do allow a way of limiting the CPU impact of indexing, for
> instance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
