[ 
https://issues.apache.org/jira/browse/COUCHDB-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randall Leeds updated COUCHDB-1363:
-----------------------------------

    Description: After subscribing to notifications it's necessary to re-open 
the #db a so that the header points at all updates for which the updater 
notifier has already fired events. In practice, this is rarely problematic 
because the next change will cause everything to catch up, but if a quick burst 
of changes happens while, e.g., replication is starting the replication can go 
stale. Detected by intermittent replicator_db js test failures.  (was: It's 
necessary to re-open the #db after subscribing to notifications so that updates 
are not lost. In practice, this is rarely problematic because the next change 
will cause everything to catch up, but if a quick burst of changes happens 
while replication is starting the replication can go stale. Detected by 
intermittent replicator_db js test failures.)
        Summary: callback invocation for docs added during couch_changes 
startup can be delayed by race condition  (was: Race condition edge case when 
pulling local changes)
    
> callback invocation for docs added during couch_changes startup can be 
> delayed by race condition
> ------------------------------------------------------------------------------------------------
>
>                 Key: COUCHDB-1363
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1363
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>    Affects Versions: 1.0.3, 1.1.1
>            Reporter: Randall Leeds
>            Assignee: Filipe Manana
>            Priority: Minor
>             Fix For: 1.2, 1.3
>
>         Attachments: 0001-Fix-a-race-condition-starting-replications.patch
>
>
> After subscribing to notifications it's necessary to re-open the #db a so 
> that the header points at all updates for which the updater notifier has 
> already fired events. In practice, this is rarely problematic because the 
> next change will cause everything to catch up, but if a quick burst of 
> changes happens while, e.g., replication is starting the replication can go 
> stale. Detected by intermittent replicator_db js test failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to