[
https://issues.apache.org/jira/browse/ZOOKEEPER-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355974#comment-14355974
]
Alexander Shraer commented on ZOOKEEPER-2136:
---------------------------------------------
Hi, I wasn't familiar with this before, but looks like the leader only replies
to a sync immediately if there are no pending operations. If there are such
operations, it waits until the last preceding pending op is committed. I think
its related to an optimization [~breed] mentioned in the thread I forwarded -
he is saying that this allows us to broadcast the syncs only if there are no
pending ops.
But I don't think this is correct (as John also says in the thread). Suppose,
for example, that the pending operation is "almost complete" -- the responses
have been received but not processed yet by the leader or sent but not received
yet). Then our leader looses leadership without knowing it yet, gets a sync
request, and finally processes the acks for the pending op. So just because we
delay the sync till after the pending op completes doesn't ensure that the
leader was the leader when the sync was invoked, which is the property we
probably want.
[~fpj], what do you think ? this delaying of syncs should probably be removed
in this JIRA and all syncs broadcasted, right ?
> 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)
