Follow up question: does anyone have a production cluster that handles a 
similar sustained rate of changes?

-----Original Message-----
From: Benjamin Reed [] 
Sent: Tuesday, October 19, 2010 2:53 PM
Subject: Re: zxid integer overflow

  we should put in a test for that. it is certainly a plausible scenario. in 
theory it will just flow into the next epoch and everything will be fine, but 
we should try it and see.


On 10/19/2010 11:33 AM, Sandy Pratt wrote:
> Just as a thought experiment, I was pondering the following:
> ZK stamps each change to its managed state with a zxid 
> (  
> That ID consists of a 64 bit number in which the upper 32 bits are the epoch, 
> which changes when the leader does, and the bottom 32 bits are a counter, 
> which is incremented by the leader with every change.  If 1000 changes are 
> made to ZK state each second (which is 1/20th of the peak rate advertised), 
> then the counter portion will roll over in 2^32 / (86400 * 1000) = 49 days.
> Now, assuming that my math is correct, is this an actual concern?  For 
> example, if I'm using ZK to provide locking for a key value store that 
> handles transactions at about that rate, am I setting myself up for failure?
> Thanks,
> Sandy

Reply via email to