Menu
▾
▴
zookeeper-developer — Mailing list to discuss development of zookeeper
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(27) |
Feb
(34) |
Mar
(30) |
Apr
(151) |
May
(184) |
Jun
(55) |
Jul
(2) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2007-12-13 23:15:31
|
Patches item #1850396, was opened at 2007-12-13 23:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1850396&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 to get the real quorumpeer id Initial Comment: this patch fixes a bug thats been in for a long time. The servers leader and follower were initialized with the thread id of quorum peer rather than the real server id. This patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1850396&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2007-12-13 22:14:29
|
Patches item #1844561, was opened at 2007-12-05 02:05 Message generated for change (Settings changed) made by mahadevkonar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&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: server Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mahadev Konar (mahadevkonar) >Assigned to: Mahadev Konar (mahadevkonar) Summary: fast sync between the leader and the follower. Initial Comment: this patch implements a fast sync between the leader adn the follower. THe leader maintains a queue of 500 requests in memory that have been committed and when a follower joins sends the diff to the follower. In case the follower is really behind, it will get the whole snapshot. In case the follower is ahead of the leader it will truncate the logs and then proceed.. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 22:14 Message: Logged In: YES user_id=1926680 Originator: YES with some more changes/documentation ... thanks ben File Added: fast-sync-follower-leader-5.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 21:40 Message: Logged In: YES user_id=1926680 Originator: YES thanks ben... for the first one... since removing from outstanding changes does not gurantee that the changes have been applied to the datatree, i am doing that later so that I am sure its been applied to the datatree before I add it to the committedLog. Doing it before would be ok as well but i feel comfortable with this control flow. for the second .. nice catch... you are right. I fixed that ... uploading a new patch. for the third, you are right this will not catch this case... but since the max zxid committed will be much much greater than the followers zxid, it will get the snapshot. The code gets a little messy if I have to take care of all the epoch transactions. In this case the follower gets the whole snapshot... what do you think? File Added: fast-sync-follower-leader-4.patch ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-13 21:24 Message: Logged In: YES user_id=154690 Originator: NO FinalRequestProcessor: Shouldn't the zks.addCommittedProposal happen inside the sync block of zks.outstandingChanges? I think that switch should happen atomically. Follower: in the case of Leader.DIFF it would be nice to have a comment that says after loadData // Now process the diffs that come from the leader as normal updates. Also, the zxid of truncate is the last zxid to KEEP not the first to DELETE right? In truncate() it looks like you are DELETEing zxid and up. FollowerHandler: It looks like you are missing a TRUNC case: Imagine the follower has seen (1,32) (where 1 is epoch and 32 is the count) and the leader has seen and committed: (1,31), (2,0), (2,1), (2,1). It doesn't look like (1,32) will be truncated from the follower's log. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 19:38 Message: Logged In: YES user_id=1926680 Originator: YES uploading the patch becaue the previous one conflicts with the trunk.. File Added: fast-sync-follower-leader-3.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:37 Message: Logged In: YES user_id=1926680 Originator: YES can you guys review this patch before I go off for vacation? i want to get it in so that it does not get stale. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-07 23:06 Message: Logged In: YES user_id=1926680 Originator: YES this patch applies to the current trunk. No specific changes. File Added: fast-sync-follower-leader-2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2007-12-13 22:14:03
|
Patches item #1844561, was opened at 2007-12-05 02:05 Message generated for change (Comment added) made by mahadevkonar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&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: server Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mahadev Konar (mahadevkonar) Assigned to: Nobody/Anonymous (nobody) Summary: fast sync between the leader and the follower. Initial Comment: this patch implements a fast sync between the leader adn the follower. THe leader maintains a queue of 500 requests in memory that have been committed and when a follower joins sends the diff to the follower. In case the follower is really behind, it will get the whole snapshot. In case the follower is ahead of the leader it will truncate the logs and then proceed.. ---------------------------------------------------------------------- >Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 22:14 Message: Logged In: YES user_id=1926680 Originator: YES with some more changes/documentation ... thanks ben File Added: fast-sync-follower-leader-5.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 21:40 Message: Logged In: YES user_id=1926680 Originator: YES thanks ben... for the first one... since removing from outstanding changes does not gurantee that the changes have been applied to the datatree, i am doing that later so that I am sure its been applied to the datatree before I add it to the committedLog. Doing it before would be ok as well but i feel comfortable with this control flow. for the second .. nice catch... you are right. I fixed that ... uploading a new patch. for the third, you are right this will not catch this case... but since the max zxid committed will be much much greater than the followers zxid, it will get the snapshot. The code gets a little messy if I have to take care of all the epoch transactions. In this case the follower gets the whole snapshot... what do you think? File Added: fast-sync-follower-leader-4.patch ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-13 21:24 Message: Logged In: YES user_id=154690 Originator: NO FinalRequestProcessor: Shouldn't the zks.addCommittedProposal happen inside the sync block of zks.outstandingChanges? I think that switch should happen atomically. Follower: in the case of Leader.DIFF it would be nice to have a comment that says after loadData // Now process the diffs that come from the leader as normal updates. Also, the zxid of truncate is the last zxid to KEEP not the first to DELETE right? In truncate() it looks like you are DELETEing zxid and up. FollowerHandler: It looks like you are missing a TRUNC case: Imagine the follower has seen (1,32) (where 1 is epoch and 32 is the count) and the leader has seen and committed: (1,31), (2,0), (2,1), (2,1). It doesn't look like (1,32) will be truncated from the follower's log. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 19:38 Message: Logged In: YES user_id=1926680 Originator: YES uploading the patch becaue the previous one conflicts with the trunk.. File Added: fast-sync-follower-leader-3.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:37 Message: Logged In: YES user_id=1926680 Originator: YES can you guys review this patch before I go off for vacation? i want to get it in so that it does not get stale. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-07 23:06 Message: Logged In: YES user_id=1926680 Originator: YES this patch applies to the current trunk. No specific changes. File Added: fast-sync-follower-leader-2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2007-12-13 21:40:06
|
Patches item #1844561, was opened at 2007-12-05 02:05 Message generated for change (Comment added) made by mahadevkonar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&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: server Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mahadev Konar (mahadevkonar) Assigned to: Nobody/Anonymous (nobody) Summary: fast sync between the leader and the follower. Initial Comment: this patch implements a fast sync between the leader adn the follower. THe leader maintains a queue of 500 requests in memory that have been committed and when a follower joins sends the diff to the follower. In case the follower is really behind, it will get the whole snapshot. In case the follower is ahead of the leader it will truncate the logs and then proceed.. ---------------------------------------------------------------------- >Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 21:40 Message: Logged In: YES user_id=1926680 Originator: YES thanks ben... for the first one... since removing from outstanding changes does not gurantee that the changes have been applied to the datatree, i am doing that later so that I am sure its been applied to the datatree before I add it to the committedLog. Doing it before would be ok as well but i feel comfortable with this control flow. for the second .. nice catch... you are right. I fixed that ... uploading a new patch. for the third, you are right this will not catch this case... but since the max zxid committed will be much much greater than the followers zxid, it will get the snapshot. The code gets a little messy if I have to take care of all the epoch transactions. In this case the follower gets the whole snapshot... what do you think? File Added: fast-sync-follower-leader-4.patch ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-13 21:24 Message: Logged In: YES user_id=154690 Originator: NO FinalRequestProcessor: Shouldn't the zks.addCommittedProposal happen inside the sync block of zks.outstandingChanges? I think that switch should happen atomically. Follower: in the case of Leader.DIFF it would be nice to have a comment that says after loadData // Now process the diffs that come from the leader as normal updates. Also, the zxid of truncate is the last zxid to KEEP not the first to DELETE right? In truncate() it looks like you are DELETEing zxid and up. FollowerHandler: It looks like you are missing a TRUNC case: Imagine the follower has seen (1,32) (where 1 is epoch and 32 is the count) and the leader has seen and committed: (1,31), (2,0), (2,1), (2,1). It doesn't look like (1,32) will be truncated from the follower's log. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 19:38 Message: Logged In: YES user_id=1926680 Originator: YES uploading the patch becaue the previous one conflicts with the trunk.. File Added: fast-sync-follower-leader-3.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:37 Message: Logged In: YES user_id=1926680 Originator: YES can you guys review this patch before I go off for vacation? i want to get it in so that it does not get stale. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-07 23:06 Message: Logged In: YES user_id=1926680 Originator: YES this patch applies to the current trunk. No specific changes. File Added: fast-sync-follower-leader-2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2007-12-13 21:24:31
|
Patches item #1844561, was opened at 2007-12-04 18:05 Message generated for change (Comment added) made by breed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&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: server Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mahadev Konar (mahadevkonar) Assigned to: Nobody/Anonymous (nobody) Summary: fast sync between the leader and the follower. Initial Comment: this patch implements a fast sync between the leader adn the follower. THe leader maintains a queue of 500 requests in memory that have been committed and when a follower joins sends the diff to the follower. In case the follower is really behind, it will get the whole snapshot. In case the follower is ahead of the leader it will truncate the logs and then proceed.. ---------------------------------------------------------------------- >Comment By: Benjamin Reed (breed) Date: 2007-12-13 13:24 Message: Logged In: YES user_id=154690 Originator: NO FinalRequestProcessor: Shouldn't the zks.addCommittedProposal happen inside the sync block of zks.outstandingChanges? I think that switch should happen atomically. Follower: in the case of Leader.DIFF it would be nice to have a comment that says after loadData // Now process the diffs that come from the leader as normal updates. Also, the zxid of truncate is the last zxid to KEEP not the first to DELETE right? In truncate() it looks like you are DELETEing zxid and up. FollowerHandler: It looks like you are missing a TRUNC case: Imagine the follower has seen (1,32) (where 1 is epoch and 32 is the count) and the leader has seen and committed: (1,31), (2,0), (2,1), (2,1). It doesn't look like (1,32) will be truncated from the follower's log. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 11:38 Message: Logged In: YES user_id=1926680 Originator: YES uploading the patch becaue the previous one conflicts with the trunk.. File Added: fast-sync-follower-leader-3.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 12:37 Message: Logged In: YES user_id=1926680 Originator: YES can you guys review this patch before I go off for vacation? i want to get it in so that it does not get stale. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-07 15:06 Message: Logged In: YES user_id=1926680 Originator: YES this patch applies to the current trunk. No specific changes. File Added: fast-sync-follower-leader-2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&group_id=209147 |
|
From: Mahadev K. <ma...@ya...> - 2007-12-13 19:41:42
|
Please review. Mahadev |
|
From: SourceForge.net <no...@so...> - 2007-12-13 19:38:16
|
Patches item #1844561, was opened at 2007-12-05 02:05 Message generated for change (Comment added) made by mahadevkonar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&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: server Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mahadev Konar (mahadevkonar) Assigned to: Nobody/Anonymous (nobody) Summary: fast sync between the leader and the follower. Initial Comment: this patch implements a fast sync between the leader adn the follower. THe leader maintains a queue of 500 requests in memory that have been committed and when a follower joins sends the diff to the follower. In case the follower is really behind, it will get the whole snapshot. In case the follower is ahead of the leader it will truncate the logs and then proceed.. ---------------------------------------------------------------------- >Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-13 19:38 Message: Logged In: YES user_id=1926680 Originator: YES uploading the patch becaue the previous one conflicts with the trunk.. File Added: fast-sync-follower-leader-3.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:37 Message: Logged In: YES user_id=1926680 Originator: YES can you guys review this patch before I go off for vacation? i want to get it in so that it does not get stale. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-07 23:06 Message: Logged In: YES user_id=1926680 Originator: YES this patch applies to the current trunk. No specific changes. File Added: fast-sync-follower-leader-2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2007-12-13 18:18:10
|
Patches item #1850239, was opened at 2007-12-13 10:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1850239&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: c client Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Benjamin Reed (breed) Summary: Patch to allow context to be set in zookeeper_init Initial Comment: This patch allows context to be set in zookeeper_init. Unfortunately, we are using C, so this is an API break. I fixed cli.c. I've also added a flags parameter since we are breaking the API and we will probably need this option in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1850239&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 23:01:16
|
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 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 |
|
From: Mahadev K. <ma...@ya...> - 2007-12-12 22:05:08
|
|
From: SourceForge.net <no...@so...> - 2007-12-12 20:37:04
|
Patches item #1844561, was opened at 2007-12-05 02:05 Message generated for change (Comment added) made by mahadevkonar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&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: server Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mahadev Konar (mahadevkonar) Assigned to: Nobody/Anonymous (nobody) Summary: fast sync between the leader and the follower. Initial Comment: this patch implements a fast sync between the leader adn the follower. THe leader maintains a queue of 500 requests in memory that have been committed and when a follower joins sends the diff to the follower. In case the follower is really behind, it will get the whole snapshot. In case the follower is ahead of the leader it will truncate the logs and then proceed.. ---------------------------------------------------------------------- >Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:37 Message: Logged In: YES user_id=1926680 Originator: YES can you guys review this patch before I go off for vacation? i want to get it in so that it does not get stale. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-07 23:06 Message: Logged In: YES user_id=1926680 Originator: YES this patch applies to the current trunk. No specific changes. File Added: fast-sync-follower-leader-2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1844561&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 20:36:18
|
Patches item #1848999, was opened at 2007-12-11 23:27 Message generated for change (Comment added) made by mahadevkonar 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: Closed 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: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:36 Message: Logged In: YES user_id=1926680 Originator: YES committed the patch. thanks andrew and ben!! ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:35 Message: Logged In: YES user_id=1926680 Originator: YES committed the patch. thanks andrew and ben!! ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:10 Message: Logged In: YES user_id=1926680 Originator: YES committed the patch. thanks andrew and ben!! ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-12 20:08 Message: Logged In: YES user_id=1926652 Originator: NO +1 looks even better now! ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:01 Message: Logged In: YES user_id=1926680 Originator: YES ok am uploading the patch with the session initialization into a static method in sessiontrackerimpl. do review it as soon as you can. File Added: session_unique-2.patch ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-12 19:26 Message: Logged In: YES user_id=1926652 Originator: NO +1 The change looks good. I'm wondering if we should factor this session id generating functionality out into a separate class to avoid code duplication in SessionTracketImpl and FollowerSessionTracker? I leave it for your consideration. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-12 19: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 18: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 18: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 18: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 16: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-12 00: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 23: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 23: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 23: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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 20:35:53
|
Patches item #1848999, was opened at 2007-12-11 23:27 Message generated for change (Comment added) made by mahadevkonar 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: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:35 Message: Logged In: YES user_id=1926680 Originator: YES committed the patch. thanks andrew and ben!! ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:10 Message: Logged In: YES user_id=1926680 Originator: YES committed the patch. thanks andrew and ben!! ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-12 20:08 Message: Logged In: YES user_id=1926652 Originator: NO +1 looks even better now! ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:01 Message: Logged In: YES user_id=1926680 Originator: YES ok am uploading the patch with the session initialization into a static method in sessiontrackerimpl. do review it as soon as you can. File Added: session_unique-2.patch ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-12 19:26 Message: Logged In: YES user_id=1926652 Originator: NO +1 The change looks good. I'm wondering if we should factor this session id generating functionality out into a separate class to avoid code duplication in SessionTracketImpl and FollowerSessionTracker? I leave it for your consideration. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-12 19: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 18: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 18: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 18: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 16: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-12 00: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 23: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 23: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 23: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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 20:10:05
|
Patches item #1848999, was opened at 2007-12-11 23:27 Message generated for change (Comment added) made by mahadevkonar 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: Closed 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: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:10 Message: Logged In: YES user_id=1926680 Originator: YES committed the patch. thanks andrew and ben!! ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-12 20:08 Message: Logged In: YES user_id=1926652 Originator: NO +1 looks even better now! ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:01 Message: Logged In: YES user_id=1926680 Originator: YES ok am uploading the patch with the session initialization into a static method in sessiontrackerimpl. do review it as soon as you can. File Added: session_unique-2.patch ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-12 19:26 Message: Logged In: YES user_id=1926652 Originator: NO +1 The change looks good. I'm wondering if we should factor this session id generating functionality out into a separate class to avoid code duplication in SessionTracketImpl and FollowerSessionTracker? I leave it for your consideration. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-12 19: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 18: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 18: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 18: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 16: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-12 00: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 23: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 23: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 23: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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 20:08:31
|
Patches item #1848999, was opened at 2007-12-11 15:27 Message generated for change (Comment added) made by akornev 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: Andrew Kornev (akornev) Date: 2007-12-12 12:08 Message: Logged In: YES user_id=1926652 Originator: NO +1 looks even better now! ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2007-12-12 12:01 Message: Logged In: YES user_id=1926680 Originator: YES ok am uploading the patch with the session initialization into a static method in sessiontrackerimpl. do review it as soon as you can. File Added: session_unique-2.patch ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-12 11:26 Message: Logged In: YES user_id=1926652 Originator: NO +1 The change looks good. I'm wondering if we should factor this session id generating functionality out into a separate class to avoid code duplication in SessionTracketImpl and FollowerSessionTracker? I leave it for your consideration. ---------------------------------------------------------------------- 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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 20:01:41
|
Patches item #1848999, was opened at 2007-12-11 23:27 Message generated for change (Comment added) made by mahadevkonar 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: Mahadev Konar (mahadevkonar) Date: 2007-12-12 20:01 Message: Logged In: YES user_id=1926680 Originator: YES ok am uploading the patch with the session initialization into a static method in sessiontrackerimpl. do review it as soon as you can. File Added: session_unique-2.patch ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2007-12-12 19:26 Message: Logged In: YES user_id=1926652 Originator: NO +1 The change looks good. I'm wondering if we should factor this session id generating functionality out into a separate class to avoid code duplication in SessionTracketImpl and FollowerSessionTracker? I leave it for your consideration. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2007-12-12 19: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 18: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 18: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 18: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 16: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-12 00: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 23: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 23: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 23: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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 19:26:32
|
Patches item #1848999, was opened at 2007-12-11 15:27 Message generated for change (Comment added) made by akornev 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: Andrew Kornev (akornev) Date: 2007-12-12 11:26 Message: Logged In: YES user_id=1926652 Originator: NO +1 The change looks good. I'm wondering if we should factor this session id generating functionality out into a separate class to avoid code duplication in SessionTracketImpl and FollowerSessionTracker? I leave it for your consideration. ---------------------------------------------------------------------- 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 |
|
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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 18:54:20
|
Patches item #1848999, was opened at 2007-12-11 23:27 Message generated for change (Comment added) made by mahadevkonar 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: Mahadev Konar (mahadevkonar) Date: 2007-12-12 18: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 18: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 18: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 16: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-12 00: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 23: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 23: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 23: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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 18:40:40
|
Patches item #1848999, was opened at 2007-12-11 23:27 Message generated for change (Comment added) made by mahadevkonar 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: Mahadev Konar (mahadevkonar) Date: 2007-12-12 18: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 18: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 16: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-12 00: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 23: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 23: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 23: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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 18:20:35
|
Patches item #1848999, was opened at 2007-12-11 23:27 Message generated for change (Comment added) made by mahadevkonar 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: Mahadev Konar (mahadevkonar) Date: 2007-12-12 18: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 16: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-12 00: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 23: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 23: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 23: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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 00:10:11
|
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-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 |
|
From: SourceForge.net <no...@so...> - 2007-12-12 00:00:03
|
Patches item #1848999, was opened at 2007-12-11 15:27 Message generated for change (Comment added) made by bartniechwiej 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: 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 |
|
From: SourceForge.net <no...@so...> - 2007-12-11 23:55:55
|
Patches item #1848999, was opened at 2007-12-11 23:27 Message generated for change (Comment added) made by mahadevkonar 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: Mahadev Konar (mahadevkonar) Date: 2007-12-11 23: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 23: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 |
|
From: SourceForge.net <no...@so...> - 2007-12-11 23:46:27
|
Patches item #1848999, was opened at 2007-12-11 15:27 Message generated for change (Comment added) made by akornev 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: 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 |
