[
https://issues.apache.org/jira/browse/COUCHDB-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182327#comment-15182327
]
Nick Vatamaniuc commented on COUCHDB-2964:
------------------------------------------
Good questions Alex.
"longpoll" behavior, the way I understand it, would wait for a change to
happen (however long the timeout is, if 'infinity' then forever), and return
when it sees a change. The key part is the since parameter though. So if
current sequence id is 1 and we launch a "longpoll" within
since=1&timeout=infinity, and then never make any changes to the database, it
would wait forever. But if we give it since=0, it will return immediately with
all the changes it knows since sequence=0, in this case 1 change and then exit.
However, in the replicator manager case, we have a db event listener. {{
https://github.com/apache/couchdb-couch-replicator/blob/master/src/couch_replicator_manager.erl#L391
}}. It notifies first if there is a change, and only then the change feeds are
launched. So it is guaranteed there'd be some changes and the feeds would exit
when those changes are processed. In practice this means the feeds act like
"normal" feeds. It seems they'd never take advantage of the "waiting till a
change happens" part of the "longpoll" mode. Another way to look at it is, in
the idle state, the couch replicator manager would not have any active change
feeds running. They are spawned only when event listener sees databases change
and then exit.
That is why I thought, even though the behavior might not be different in
practice here between longpoll and normal. Making it "normal" makes more sense,
as pretty much acts like "normal" anyway. But again, I am not too familiar with
the code, and there are many subtle nuances in that code. So wanted to bring it
up for a wider discussion.
(Note: there other possible pattern is to use continuous feeds and then unlink
and kill them on rescan. So in this case, in the idle state, there would active
change feed processes alive and waiting on each replicator databases. But that
changes the logic a bit more, which might introduce new subtle bugs).
> Investigate switching replicator manager change feeds to using "normal"
> instead of "longpoll"
> ---------------------------------------------------------------------------------------------
>
> Key: COUCHDB-2964
> URL: https://issues.apache.org/jira/browse/COUCHDB-2964
> Project: CouchDB
> Issue Type: Improvement
> Components: Replication
> Reporter: Nick Vatamaniuc
> Assignee: Nick Vatamaniuc
> Fix For: 2.1
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
