zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordan Zimmerman (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ZOOKEEPER-2901) Session ID that is negative causes mis-calculation of Ephemeral Type
Date Wed, 20 Sep 2017 20:10:00 GMT

    [ 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)

Mime
View raw message