[
https://issues.apache.org/jira/browse/COUCHDB-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147228#comment-15147228
]
Robert Newson commented on COUCHDB-2947:
----------------------------------------
The continuous mode is implemented as two stages;
1) the changes that you'd get as if you didn't say 'continuous' come first then;
2) all new changes from that point onward
so the limit=1 applied to stage 1.
for "1 doc is emitted, the _changes feed emits the last_seq line, then the
request is terminated.", you should use feed=longpoll instead, that will let
you wait for an update and it ends on the next update that passes your filter
(if present).
> Applying limit and continuous to _changes results in odd behavior when
> writing documents during request
> -------------------------------------------------------------------------------------------------------
>
> Key: COUCHDB-2947
> URL: https://issues.apache.org/jira/browse/COUCHDB-2947
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Reporter: Mike Rhodes
>
> If I have a database that is continuously receiving updates, applying
> continuous and limit parameters to my database query gives odd behaviour.
> Take this URL:
> http://localhost:5984/database/_changes?since=0&limit=1&feed=continuous
> If I call this URL while running a script writing documents to the database
> at a great enough rate that the continuous changes timeout is not hit, the
> behaviour isn't as I'd expect.
> What I'd expect to happen:
> 1 doc is emitted, the _changes feed emits the last_seq line, then the request
> is terminated.
> What actually happens:
> Once `limit` items have been returned, entries continue being emitted until
> writing documents to the database stops. After writing stops, entries stop
> being emitted into the response. If I start writing again, the response
> starts to emit changes entries again. If I don't start writing again, the
> request eventually times out via the default setting in couch.ini and emits
> the last_seq line and closes.
> If a timeout is applied in the URL, this overrides the default timeout as
> expected, but otherwise the behaviour remains the same.
> To be clear, the feed is emitting the correct stuff -- entries in sequence
> order from the since parameter, and last_seq has the expected value given the
> items emitted into the response -- it's just emitting stuff longer than I'd
> expect. The _changes feed isn't catching up to the current seq, it's just
> continuing to emit while the documents are being written. Once writing to the
> database stops, the request stops emitting changes wherever it's managed to
> get up to. From what I can tell, the emitted entries into the changes feed
> are in the right sequence, so we're not missing items from the feed, just
> emitting too many of them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
