couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1363) Race condition edge case when pulling local changes
Date Thu, 15 Dec 2011 22:49:30 GMT

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

Randall Leeds commented on COUCHDB-1363:
----------------------------------------

Thanks for the review. I'll explain more (I was distracted by talking after the CouchBase
meetup).

I've run into this during the course of my work for COUCHDB-1350. As part of that, I had to
change the replicator_db test and make the continuous_replication_survives_restart use bare
db names instead of urls (the url changes after /_restart). I'm guessing I uncovered this
race because the timing changes as a result of this different path.

In any case, unless I'm missing something fundamental it's most definitely a bug and this
patch definitely fixes it. I tested by removing the line to stop CouchDB after the tests,
so I could leave the replication running after the failure, which was line 700 of replicator_db.js.
The replication stays open in active tasks but the fourth change, to doc 'foo1000', isn't
replicated until I PUT another change to the source database. That is because the Db handle
that's passed into handle_changes is pointing at an old header and the update_notifier hasn't
been started yet. The patch re-opens the db after subscribing to notifications, which ensures
we can't miss an update and stall in this way.

It probably doesn't bite many people, though (replication starts again as soon as the next
change comes), but I can think of situations I've seen where this could be a problem.

Thanks for catching the shadowing issue. I didn't notice the warning when I compiled. I thought
that the DbName in the fun header would be matched against the DbName in the handle_changes
header instead of shadowing. My intention was not to change that functionality and I should
probably have left it alone.

Let me know if it's okay to commit (- the shadowing). I don't see a better fix. Do you?
                
> Race condition edge case when pulling local changes
> ---------------------------------------------------
>
>                 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
>
>
> 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.

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

        

Mime
View raw message