You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Randall Leeds (Updated) (JIRA)" <ji...@apache.org> on 2011/12/15 23:53:30 UTC
[jira] [Updated] (COUCHDB-1363) callback invocation for docs added
during couch_changes startup can be delayed by race condition
[ 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