[
https://issues.apache.org/jira/browse/ZOOKEEPER-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357267#comment-14357267
]
Alexander Shraer commented on ZOOKEEPER-2136:
---------------------------------------------
Hi Flavio,
The problem is that right now, sync is the only operation in ZooKeeper that
makes timing assumptions for safety as opposed to liveness, and as pointed out
by [~hdeng] during reconfiguration the exposed race condition is especially
risky since its implemented in a way where when the leader is removed it is
abandoned by followers instead of being shutting down.
It wouldn't be nice to require users to use setData/create if they want strong
read semantics.
The idea to provide a strong read (quorum read) operation instead of fixing
sync may be a good option. I guess the unique thing about sync was supposed to
be that it gets this path as a parameter and was supposed to be able to sync
just part of the tree (right ?) but that never happened. I'm not sure, but
perhaps its better to just add a quorum read ?
> Sync() should get quorum acks.
> ------------------------------
>
> Key: ZOOKEEPER-2136
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2136
> Project: ZooKeeper
> Issue Type: Sub-task
> Reporter: Hongchao Deng
> Assignee: Hongchao Deng
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2000.patch
>
>
> Currently if the sync packet goes to leader it doesn't get quorum acks. This
> is a problem during reconfig and leader changes. testPortChange() flaky
> failure is caused by such case.
> I proposed to change sync() semantics to require quorum acks in any case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
