zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2901) Session ID that is negative causes mis-calculation of Ephemeral Type
Date Fri, 22 Sep 2017 22:21:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177260#comment-16177260
] 

ASF GitHub Bot commented on ZOOKEEPER-2901:
-------------------------------------------

GitHub user Randgalt opened a pull request:

    https://github.com/apache/zookeeper/pull/377

    [ZOOKEEPER-2901] TTL Nodes don't work with Server IDs > 127

    There was a major oversight when TTL nodes were implemented. The session ID generator
for each server is seeded with the configured Server ID in the high byte. TTL Nodes were using
the highest bit to denote a TTL node when used in the ephemeral owner. This meant that Server
IDs > 127 that created ephemeral nodes would have those nodes always considered TTL nodes
(with the TTL being essentially a random number).
    
    This PR fixes the issue by disabling TTL Nodes by default. They must now be enabled in
zoo.cfg. When TTL Nodes are enabled, the max Server ID changes from 255 to 254. This allows
the high byte of a session ID stored in the ephemeral owner to use 0xFF to denote a TTL node.
    
    About this change:
    
    - The doc has been updated to note that TTL nodes are disabled by default and must be
enabled via config. Also, the docs explains that when TTL nodes are enabled the max Server
ID becomes 254
    - The TTL implementation has been updated to use 0xFF in the high byte of the ephemeralOwner
to denote a TTL node. This decreases the max TTL by an insignificant amount
    - PrepRequestProcessor now throws `KeeperException.UnimplementedException` when an attempt
to create a TTL node is made but the server has not been configured to enable TTL Nodes.
    - QuorumPeer throws a `RuntimeException` if TTL Nodes are enabled but the Server ID >
254
    - Tests have been added to validate all of this

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/Randgalt/zookeeper ZOOKEEPER-2901

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/zookeeper/pull/377.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #377
    
----
commit 21fa7716133e903c8d43c1003012837f980cb044
Author: randgalt <jordan@jordanzimmerman.com>
Date:   2017-09-22T22:10:30Z

    There was a major oversight when TTL nodes were implemented. The session ID generator
for each server is seeded with the configured
    Server ID in the high byte. TTL Nodes were using the highest bit to denote a TTL node
when used in the ephemeral owner. This meant
    that Server IDs > 127 that created ephemeral nodes would have those nodes always considered
TTL nodes (with the TTL being essentially
    a random number).
    
    This PR fixes the issue by disabling TTL Nodes by default. They must now be enabled in
zoo.cfg. When TTL Nodes are enabled, the max
    Server ID changes from 255 to 254. This allows the high byte of a session ID stored in
the ephemeral owner to use 0xFF to denote
    a TTL node.

----


> 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