[
https://issues.apache.org/jira/browse/ZOOKEEPER-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14203428#comment-14203428
]
Hadoop QA commented on ZOOKEEPER-1716:
--------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12680296/ZOOKEEPER-1716.patch
against trunk revision 1637293.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
+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/2432//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2432//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2432//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
> 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)
