[
https://issues.apache.org/jira/browse/COUCHDB-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955835#comment-15955835
]
ASF subversion and git services commented on COUCHDB-2964:
----------------------------------------------------------
Commit d00b981445c03622497088eb872059ab4f48b298 in couchdb-couch-replicator's
branch refs/heads/COUCHDB-3287-pluggable-storage-engines from [~vatamane]
[
https://git-wip-us.apache.org/repos/asf?p=couchdb-couch-replicator.git;h=d00b981
]
Prevent replicator manager change feeds from getting stuck
Switch them them from `longpoll` to `normal`
This would prevent them being stuck. That could happen if more than one
`resume_scan` message arrives for the same shard. The first time a longpoll
changef feed would finish and end sequence is checkpointed. But if another
resume_scan arrives and database hasn't changed then the longpoll change
feed would hang until db is updated.
The reason there would be multiple `resume_scan` messages is because there
is a race condition between db update handler and scanner component. They are
both started asynchronously roughly at the same. Scanner finds new shard while
db handler notices changes for those shards. If shards are modified quickly
after they are discovered by the scanner both of those components would issue
a resume_scan.
The effect of this would be more pronounced if there are a large number of
_replicator shards and constant db creation/deletion/updates.
COUCHDB-2964
> 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: kzx
> Fix For: 2.1
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
