[
https://issues.apache.org/jira/browse/COUCHDB-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15814924#comment-15814924
]
Robert Newson commented on COUCHDB-3269:
----------------------------------------
This isn't quite right. What I've seen is a _changes request that 'hangs'
despite sending as many rows as requested by the limit parameter.
In the hang cases, filter and limit and since are specified, and I think it's
the combination of all three that gets us here.
The current fabric_view_changes code around no_pass looks right to me on
reflection. We can't update offset until we get a _hit_ from a shard since
offset is the distance to the first row from the beginning of the view, and
without updating offset for each worker, maybe_stop will not stop.
So, what must be happening is that the combination of the filter and the since
value means at least one worker has not seen a hit yet. That is takes so long
to hit one implies that there are no hits in that shard range at all and we're
just processing the feed from it, sending no_pass messages, until we hit the
end.
Not immediately clear how we short-circuit correctly here.
> view response can 'hang' with filter and limit specified
> --------------------------------------------------------
>
> Key: COUCHDB-3269
> URL: https://issues.apache.org/jira/browse/COUCHDB-3269
> Project: CouchDB
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Robert Newson
>
> If you query a large view with both 'filter' and 'limit' specified, couchdb
> will not promptly complete the view response after the requested number of
> rows has been returned.
> This is because view completion happens on receipt of a 'change' or
> 'completed' message from a worker. In the case of a filtered view request,
> the worker might instead return a 'no_pass' message, indicating that no
> documents passed the filter at a given sequence.
> Add a clause in fabric_view_changes to handle this special case and end the
> view response promptly where possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
