[
https://issues.apache.org/jira/browse/HBASE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638802#comment-13638802
]
Hudson commented on HBASE-8384:
-------------------------------
Integrated in HBase-TRUNK #4074 (See
[https://builds.apache.org/job/HBase-TRUNK/4074/])
HBASE-8384 heap size computation for HStore is fishy (Revision 1470777)
Result = FAILURE
sershe :
Files :
*
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanInfo.java
> heap size computation for HStore is fishy
> -----------------------------------------
>
> Key: HBASE-8384
> URL: https://issues.apache.org/jira/browse/HBASE-8384
> Project: HBase
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Priority: Minor
> Attachments: HBASE-8384-v0.patch
>
>
> There's something off with heap size computation for HStore. If one adds a
> long to HStore, and size of long to the computation, TestHeapSize passes both
> locally (for me) and in jenkins. If one adds an int and size of int, it
> passes locally but fails in Jenkins. Perhaps the numbers are already off and
> some sort of packing is taking/not taking place differently.
> On a tangentially related note, if we can obtain size programmatically (the
> way we do it in test), and only need to do it once, I wonder if we should
> just do it and remove all the manually modifiable constants stuff.
--
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
