[
https://issues.apache.org/jira/browse/COUCHDB-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181305#comment-15181305
]
ASF subversion and git services commented on COUCHDB-2963:
----------------------------------------------------------
Commit a7e7565d6a743961ebdec155fbfd70f609337ce2 in couchdb-couch-replicator's
branch refs/heads/master from [~kzx]
[
https://git-wip-us.apache.org/repos/asf?p=couchdb-couch-replicator.git;h=a7e7565
]
Switch replicator manager change feeds to "longpoll"
Fixes replication manager rescans on cluster membership
change.
Replication manager resets all replication db
sequence checkpoints, and starts a new replicator db
background scanner. Each replicator database is signaled
to rescan from sequence 0. However previous change feeds
for each db have to exit first. If they never exit, because
they are "continuous" new change feeds will never start.
Putting change feeds in "longpoll" mode ensures they will
eventually exit.
JIRA: COUCHDB-2963
> Replication manager does not rescan databases on cluster membership change
> --------------------------------------------------------------------------
>
> Key: COUCHDB-2963
> URL: https://issues.apache.org/jira/browse/COUCHDB-2963
> Project: CouchDB
> Issue Type: Bug
> Reporter: Nick Vatamaniuc
>
> Replication manager should rescan all replicator databases on cluster
> membership changes from sequence 0, in order to possibly pick up new
> replication it might be an owner of.
> On receipt of nodedown or nodeup message, replication manager attempts to
> start a new scan by resetting the checkpointed sequence IDs ets table. With
> the intent that change feeds will exit and then check if they need to rescan
> again. However because change feeds used for the replicator databases are
> "continuous" they never exit, so consequently they never get a chance start
> rescanning from 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
