[
https://issues.apache.org/jira/browse/ZOOKEEPER-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16173758#comment-16173758
]
Jordan Zimmerman edited comment on ZOOKEEPER-2901 at 9/20/17 8:09 PM:
----------------------------------------------------------------------
There are a number of possibilities to address this:
* Remove the feature completely
* Quick fix now, larger fix later
* Find another way to denote container/TTL
The problem is that ServerIDs > 63 will now appear to be TTL nodes (server IDs
>= 255 will appear to be container nodes).
Commentary:
_Remove the Feature completely_
I don't see how we can do this without breaking existing clients. Even if we
remove TTLs, Container nodes have been out there for over a year (or more?).
Container nodes has the same problem.
_Quick fix now, larger fix later_
The quick fix is to mask the 2 high bits of the Server ID when seeding the
session ID. This has major implications for how the ServerID is chosen. But,
this is beyond my knowledge. The way the Server ID is/was stored prior to
TTL/Container nodes implied that the ServerID had to have unique bits across
the ensemble. I need other committers to comment on this. To be clear, this is
the change:
{code:java}
// in SessionTrackerImpl#initializeNextSession()
public static long initializeNextSession(long id) {
long nextSid;
nextSid = (Time.currentElapsedTime() << 24) >>> 8;
nextSid = nextSid | (id <<56);
return EphemeralType.maskSessionId(nextSid);
}
// in EphemeralType
public static long maskSessionId(long id) {
return id & EPHEMERAL_MASK;
}
{code}
_Find another way to denote container/TTL_
I need ideas here. Not sure how to handle this in a backward compatible way.
was (Author: randgalt):
There are a number of possibilities to address this:
* Remove the feature completely
* Quick fix now, larger fix later
* Find another way to denote container/TTL
The problem is that ServerIDs > 63 will now appear to be TTL nodes (server IDs
>= 255 will appear to be container nodes).
Commentary:
_Remove the Feature completely_
I don't see how we can do this without breaking existing clients. Even if we
remove TTLs, Container nodes have been out there for over a year (or more?).
Container nodes has the same problem.
_Quick fix now, larger fix later_
The quick fix is to mask the 2 high bits of the Server ID when seeding the
session ID. This has major implications for how the ServerID is chosen. But,
this is beyond my knowledge. The way the Server ID is/was stored prior to
TTL/Container nodes implied that the ServerID had to have unique bits across
the ensemble. I need other committers to comment on this. To be clear, this is
the change:
{{// in SessionTrackerImpl#initializeNextSession()
public static long initializeNextSession(long id) {
long nextSid;
nextSid = (Time.currentElapsedTime() << 24) >>> 8;
nextSid = nextSid | (id <<56);
return EphemeralType.maskSessionId(nextSid);
}
// in EphemeralType
public static long maskSessionId(long id) {
return id & EPHEMERAL_MASK;
}
}}
_Find another way to denote container/TTL_
I need ideas here. Not sure how to handle this in a backward compatible way.
> Session ID that is negative causes mis-calculation of Ephemeral Type
> --------------------------------------------------------------------
>
> Key: ZOOKEEPER-2901
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2901
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.5.3
> Environment: Running 3.5.3-beta in Docker container
> Reporter: Mark Johnson
> Assignee: Jordan Zimmerman
> Priority: Blocker
>
> In the code that determines the EphemeralType it is looking at the owner
> (which is the client ID or connection ID):
> EphemeralType.java:
> public static EphemeralType get(long ephemeralOwner) {
> if (ephemeralOwner == CONTAINER_EPHEMERAL_OWNER) {
> return CONTAINER;
> }
> if (ephemeralOwner < 0) {
> return TTL;
> }
> return (ephemeralOwner == 0) ? VOID : NORMAL;
> }
> However my connection ID is:
> header.getClientId(): -720548323429908480
> This causes the code to think this is a TTL Ephemeral node instead of a
> NORMAL Ephemeral node.
> This also explains why this is random - if my client ID is non-negative
> then the node gets added correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
