[
https://issues.apache.org/jira/browse/ZOOKEEPER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006250#comment-13006250
]
Vishal K commented on ZOOKEEPER-335:
------------------------------------
{quote}
to fix this issue we require server -server protocol change. Thsi protocol
change will break backwards compatibility. To maintain backwards compatibility
the code becomes quite complex and tricky. Instead of making a last minute
change and having to do all the testing to check if backwards compatibily for
servers is maintained, I am moving it to 3.3 to see if we want to fix it in a
backwards compatible manner or fix it in 4.0 and break backwards compatibility.
{quote}
Until the bug is fixed, will it be possible to avoid running into this scenario
by doing the following:
1. Create a znode /dummy
2. After receiving a SyncConnected write some data to /dummy
3. Then proceed with other write transactions
Essentially, do a NULL transaction from the client. Will this prevent the log
divergence to affect divergence of ordering of client transactions?
> zookeeper servers should commit the new leader txn to their logs.
> -----------------------------------------------------------------
>
> Key: ZOOKEEPER-335
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-335
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.1.0
> Reporter: Mahadev konar
> Assignee: Mahadev konar
> Priority: Blocker
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-790.travis.log.bz2, faultynode-vishal.txt,
> zk.log.gz, zklogs.tar.gz
>
>
> currently the zookeeper followers do not commit the new leader election. This
> will cause problems in a failure scenarios with a follower acking to the same
> leader txn id twice, which might be two different intermittent leaders and
> allowing them to propose two different txn's of the same zxid.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
