[ https://issues.apache.org/jira/browse/ZOOKEEPER-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957750#comment-14957750 ]
Hadoop QA commented on ZOOKEEPER-1716: -------------------------------------- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12680477/ZOOKEEPER-1716.patch against trunk revision 1706631. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2918//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2918//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2918//console This message is automatically generated. > jute/Utils.fromCSVBuffer cannot parse data returnd by toCSVBuffer > ------------------------------------------------------------------ > > Key: ZOOKEEPER-1716 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1716 > Project: ZooKeeper > Issue Type: Bug > Components: jute > Affects Versions: 3.5.0 > Reporter: Robert Joseph Evans > Assignee: Charlie Helin > Attachments: ZOOKEEPER-1716.patch > > > I was trying to use org.apache.zookeeper.server.LogFormatter to analyze the > access pattern of a particular application. As part of this I wanted to get > the size of the data that was being written into ZK. > I ran into an issue where in some cases the hex data had an odd length. I > looked into it and found that the buffer is being written out using > Integer.toHexString(barr[idx]) > Looking at the javadoce for toHexString it indicates that it does not pad the > bits at all, and will output the twos compliment of the number if it is > negative. I then looked at how the data was being parsed and it assumed that > every byte consisted of exactly two characters, which is not true. > {code} > Utils.toCSVBuffer(new byte[] {0xff}) returns "#ffffffff" > Utils.toCSVBuffer(new byte[] {0x01}) returns "#1" > If I combine those > Utils.fromCSVBuffer(Utils.toCSVBuffer(new byte[] {0xff, 0x01, 0xff})) will > return {0xff, 0xff, 0xff, 0xff, 0x1f, 0xff, 0xff, 0xff} > {code} > I think what we want is something like > {code} > static final char[] NIBBLE_TO_HEX = { > '0', '1', '2', '3', '4', '5', '6', '7', > '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' > }; > static String toCSVBuffer(byte barr[]) { > if (barr == null || barr.length == 0) { > return ""; > } > StringBuilder sb = new StringBuilder(barr.length + 1); > sb.append('#'); > for(int idx = 0; idx < barr.length; idx++) { > byte b = barr[idx]; > sb.append(NIBBLE_TO_HEX[b&0x0f]); > sb.append(NIBBLE_TO_HEX[(b&0xf0)>>4]); > } > return sb.toString(); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)