[jira] [Commented] (COUCHDB-3227) Inconsistent/odd behaviour of the new ?stable=X&update=Y API

["Robert Frazier (JIRA)" <ji...@apache.org>]

    [ 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)