Menu
▾
▴
[Zookeeper-developer] [ zookeeper-Patches-1848999 ] Patch for session conflicsts on leader and followers
|
From: SourceForge.net <no...@so...> - 2007-12-12 19:26:12
|
Patches item #1848999, was opened at 2007-12-11 15:27 Message generated for change (Comment added) made by breed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1848999&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mahadev Konar (mahadevkonar) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for session conflicsts on leader and followers Initial Comment: This patch fixes the session id conflict. This uses the id of the server as the first 8 bits, system.currentmillis() last 32 bits as the next 32 bits as the initial session id. ---------------------------------------------------------------------- >Comment By: Benjamin Reed (breed) Date: 2007-12-12 11:26 Message: Logged In: YES user_id=154690 Originator: NO Looks good. My only complaint is that you have the initial session ID logic in two places: FollowerSessionTracker and SessionTrackerImpl. It would be nice to make a static method in SessionTrackerImpl that FollowerSessionTracker calls so that the logic is only in one place. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 10:54 Message: Logged In: YES user_id=1926680 Originator: YES uploaded the patch with my last comments. File Added: session_unique-1.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 10:40 Message: Logged In: YES user_id=1926680 Originator: YES well actually now I think of it .. i dont think there is any problem with the last 24 bits overflowing. The only problem that is see that on a leader election if we use the same 32 bits for time that we started with then we might have a client that was already connected and a new client getting the same id. I think we can increase the time bits to 40 and leave 16 bits for the counter. There is no problem with the 16 bits overflowing. Does that sound right to everyone? ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 10:20 Message: Logged In: YES user_id=1926680 Originator: YES no I think what andrew means is that if we have long running clients say 2 months or 3 months then we might have problem with this approach.. dont we? ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-12 08:31 Message: Logged In: YES user_id=154690 Originator: NO On overflow we do not need to recalculate the high order bits. It will just tick forward one millisecond. Since it is impossible to create 16M sessions in one millisecond we will still have a unique session ID. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-11 16:10 Message: Logged In: YES user_id=154690 Originator: NO +1 looks good. Check in. Let's bring it up on the mailing list as well to make sure everyone is comfortable. ---------------------------------------------------------------------- Comment By: Bartlomiej Niechwiej (bartniechwiej) Date: 2007-12-11 15:59 Message: Logged In: YES user_id=1957815 Originator: NO What about System.nanoTime() instead of System.currentTimeMillis(), just to use microseconds (forget about nano precision =P) ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-11 15:55 Message: Logged In: YES user_id=1926680 Originator: YES you mean the rightmost 24 bits overflow? Thats true... in that case we should recalculate. let me put in the logic for that... ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-11 15:46 Message: Logged In: YES user_id=1926652 Originator: NO What about the case when the leftmost 24-bit overflow? At this point, to make the algorithm completely bullet proof we should recalculate the top 40 bits... What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1848999&group_id=209147 |
