[ZOOKEEPER-1278] acceptedEpoch not handling zxid rollover in lower 32bits

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Duplicate
• Affects Version/s: 3.4.0, 3.5.0
• Component/s: server

Release Note

Workaround: there is a simple workaround for this issue. Force a leader re-election before the lower 32bits reach 0xffffffff

Most users won't even see this given the number of writes on a typical installation - say you are doing 500 writes/second, you'd see this after ~3 months if the quorum is stable, any changes (such as upgrading the server software) would cause the xid to be reset, thereby staving off this issue for another period.

• Assignee: Patrick D. Hunt
• Reporter: Patrick D. Hunt
• Created: 02/Nov/11 16:54
• Updated: 23/Mar/12 00:36
• Resolved: 23/Mar/12 00:36

Description

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, afaict, in the current 3.4/3.5 the acceptedEpoch/currentEpoch files are not being updated for this case.

See ZOOKEEPER-335 for changes from 3.3 branch.

Issue Links

• is broken by: ZOOKEEPER-335 zookeeper servers should commit the new leader txn to their logs.
• is related to: ZOOKEEPER-1277 servers stop serving when lower 32bits of zxid roll over