hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henry Robinson (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ZOOKEEPER-783) committedLog in ZKDatabase is not properly synchronized
Date Tue, 01 Jun 2010 19:42:36 GMT

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

Henry Robinson updated ZOOKEEPER-783:

    Attachment: ZOOKEEPER-783.patch

Defensive copying added to getCommittedLog() and synchronization during clear(). 

No tests added; really not sure how best to test for this. It does fix my test case but it's
very difficult to distill that into a test (plus it only fails once in about 100 runs). 

> committedLog in ZKDatabase is not properly synchronized
> -------------------------------------------------------
>                 Key: ZOOKEEPER-783
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-783
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.3.1
>            Reporter: Henry Robinson
>            Priority: Critical
>         Attachments: ZOOKEEPER-783.patch
> ZKDatabase.getCommittedLog() returns a reference to the LinkedList<Proposal> committedLog
in ZKDatabase. This is then iterated over by at least one caller. 
> I have seen a bug that causes a NPE in LinkedList.clear on committedLog, which I am pretty
sure is due to the lack of synchronization. This bug has not been apparent in normal ZK operation,
but in code that I have that starts and stops a ZK server in process repeatedly (clear() is
called from ZooKeeperServerMain.shutdown()). 
> It's better style to defensively copy the list in getCommittedLog, and to synchronize
on the list in ZKDatabase.clear.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message