accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Newton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-965) Zookeeper session ids created as unsigned long, parsed in ZooUtils.java as signed long
Date Tue, 15 Jan 2013 16:58:12 GMT

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

Eric Newton commented on ACCUMULO-965:
--------------------------------------

Digging into the zookeeper code, it looks like session ids consist of 8 bits of myid, time
shifted 16 bits left.

The problem is that time is now 41 bits... and they shift those bits left 24, then right 8.
 The shift right is an arithmetic shift, so sign extension is possible.  The myid bits are
or'd into the upper most bits, so if sign extension happens, they will all be set to 1's.
 The current time, in hex, looks like this:

0x13c3f143771

It would be very strange to have a time value where the upper bit of the second hex digit
would be set. That will be 0x18000000000 (April, 2022), or 0xffffffffff (November, 2004)

Or, we could be using a myid up in the range of 0x80.  If someone was to put the zookeeper
port number (2181, or 0x885) into the myid file, that might cause this problem.

                
> Zookeeper session ids created as unsigned long, parsed in ZooUtils.java as signed long
> --------------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-965
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-965
>             Project: Accumulo
>          Issue Type: Bug
>          Components: start
>    Affects Versions: 1.4.2
>         Environment: Hadoop 0.20, ZooKeeper 3.4.3, CentOS 2.6, x64 CPU, Java 1.6.0_24
>            Reporter: Rich Alberth
>            Assignee: Eric Newton
>            Priority: Critical
>             Fix For: 1.5.0, 1.4.3
>
>
> Seems like this may be a bug.  I looked at
> LiveTServerSet.assignTablet() it eventually calls Long.toHexString().
> The javadoc for toHexString() says the following.
> {code}Returns a string representation of the <code>long</code>
> argument as an unsigned integer in base 16.
> {code}
> However, the method we are using to parse the Long can not handle
> unsigned longs greater than MAX_LONG.  There does not seem to be a
> method in long that can parse the output of  toHexString().  For
> example the following will fail, any negative number will fail.
> {code}Long.parseLong(Long.toHexString(-1), 16);{code}
> Original Stack Dump:
> {code}
> java.lang.NumberFormatException: For input string: "b53c3a3610ce0001"
> 	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> 	at java.lang.Long.parseLong(Long.java:422)
> 	at org.apache.accumulo.core.zookeeper.ZooUtil$LockID.<init>(ZooUtil.java:64)
> 	at org.apache.accumulo.server.tabletserver.TabletServer$ThriftClientHandler.checkPermission(TabletServer.java:1794)
> 	at org.apache.accumulo.server.tabletserver.TabletServer$ThriftClientHandler.loadTablet(TabletServer.java:1814)
> 	at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor.process(TabletClientService.java:2037)
> 	at org.apache.accumulo.server.util.TServerUtils$TimedProcessor.process(TServerUtils.java:154)
> 	at org.apache.thrift.server.TNonblockingServer$FrameBuffer.invoke(TNonblockingServer.java:631)
> 	at org.apache.accumulo.server.util.TServerUtils$THsHaServer$Invocation.run(TServerUtils.java:202)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message