[
https://issues.apache.org/jira/browse/HBASE-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923974#action_12923974
]
HBase Review Board commented on HBASE-3136:
-------------------------------------------
Message from: [email protected]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1056/#review1620
-----------------------------------------------------------
Ship it!
+1 on getting it in as is. I think its going to kill my bulk assign
improvements but yesterday discussing w/ Jon and Karthik, there are plenty of
options to explore yet... We'll do in another issue.
- stack
> Stale reads from ZK can break the atomic CAS operations we have in ZKAssign
> ---------------------------------------------------------------------------
>
> Key: HBASE-3136
> URL: https://issues.apache.org/jira/browse/HBASE-3136
> Project: HBase
> Issue Type: Bug
> Components: zookeeper
> Affects Versions: 0.89.20100621, 0.89.20100924, 0.90.0
> Reporter: Jonathan Gray
> Assignee: Jonathan Gray
> Priority: Blocker
> Fix For: 0.90.0
>
>
> With ZK based region transitions, we rely on atomic state changes of regions
> in transition. For example, an RS needs to atomically switch a node from
> OFFLINE to OPENING, or the master needs to delete nodes that are in OPENED
> state, etc...
> The way we implement this is by:
> - Read existing data (returns byte[] and version in Stat)
> - Verify data is in expected state
> - Update to the new state, passing the expected version previously read
> This doesn't always work as expected because that initial read of the
> existing data could be a stale read (in ZK, writes are quorum writes but
> reads are not so you can get stale data).
> Can provide a more explicit example if anyone is interested, but a fix is
> coming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
