[
https://issues.apache.org/jira/browse/ZOOKEEPER-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633563#comment-13633563
]
Patrick Hunt commented on ZOOKEEPER-1277:
-----------------------------------------
Hi [~davelatham], it seems unlikely to me. Are you only running hbase against
ZK? Because in that case the number of changes to zk are going to be <<<< than
4billion (the amount necessary to roll over the lower 32 bits), hbase just
doesn't generate that much traffic. I've only seen the rollover case with 10k's
of clients doing large numbers of operations per second. hbase just doesn't
drive that much traffic - it's mainly for failover and table management.
You might have hit an issue with 3.4 that was fixed in a subsequent release.
However the symptoms you mentioned don't ring a bell either....
> servers stop serving when lower 32bits of zxid roll over
> --------------------------------------------------------
>
> Key: ZOOKEEPER-1277
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1277
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.3.3
> Reporter: Patrick Hunt
> Assignee: Patrick Hunt
> Priority: Critical
> Fix For: 3.3.5, 3.4.4, 3.5.0
>
> Attachments: ZOOKEEPER-1277_br33.patch, ZOOKEEPER-1277_br33.patch,
> ZOOKEEPER-1277_br33.patch, ZOOKEEPER-1277_br33.patch,
> ZOOKEEPER-1277_br34.patch, ZOOKEEPER-1277_br34.patch,
> ZOOKEEPER-1277_trunk.patch, ZOOKEEPER-1277_trunk.patch
>
>
> When the lower 32bits of a zxid "roll over" (zxid is a 64 bit number, however
> the upper 32 are considered the epoch number) the epoch number (upper 32
> bits) are incremented and the lower 32 start at 0 again.
> This should work fine, however in the current 3.3 branch the followers see
> this as a NEWLEADER message, which it's not, and effectively stop serving
> clients. Attached clients seem to eventually time out given that heartbeats
> (or any operation) are no longer processed. The follower doesn't recover from
> this.
> I've tested this out on 3.3 branch and confirmed this problem, however I
> haven't tried it on 3.4/3.5. It may not happen on the newer branches due to
> ZOOKEEPER-335, however there is certainly an issue with updating the
> "acceptedEpoch" files contained in the datadir. (I'll enter a separate jira
> for that)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
