You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by "Nick Vatamaniuc (JIRA)" <ji...@apache.org> on 2016/03/05 00:29:41 UTC

[jira] [Commented] (COUCHDB-2964) Investigate switching replicator manager change feeds to using "normal" instead of "longpoll"

    [ https://issues.apache.org/jira/browse/COUCHDB-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180747#comment-15180747 ] 

Nick Vatamaniuc commented on COUCHDB-2964:
------------------------------------------

Replicator manager currently uses "longpoll" mode just like the couch_replicator code.  Since replicator manager in 2.0 uses change feeds from local shards, it is interesting to investigate switching to "normal" mode.

Details:

Previous couch_replicator's change feeds go through the fabric layer so longpoll is needed because the set of shards which signaled the update, might not be the shards changes feed will hit. If normal is used then the change feed could immediately return without waiting for the new change. Longpoll mode ensures there is a wait for shards to receive the change and only then return.

CouchDB 2.0 replicator manager uses change feeds on individual shards. It seems even though "longpoll" mode will still work (replicator manager is notified there is an update to the database, then get changes from last checkpoint to the latest, and then saves the new checkpoint),  normal" mode might be more semantically correct, as effectively "longpoll" is used as normal in most cases.

> 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
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)