[ 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 <jor...@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)