[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated HBASE-7801:
---------------------------------
Attachment: hbase-7801-addendum.patch
[~lhofhansl] Today, I happened to work on Mutation.java and found that
Mutation#MUTATION_OVERHEAD is off. The reason that TestHeapSize#testMutations
can pass is due to we still leave old {code}
// writeToWAL
Bytes.SIZEOF_BOOLEAN
{code} there. The one byte later is round up to 8 bytes which is matching the
newly added field durability which is a reference and has 8 bytes in len. Below
are detailed dump for the Mutation:
{code}
013-04-12 15:33:40,902 DEBUG [main] util.ClassSize(246): 0 row class [B
2013-04-12 15:33:40,903 DEBUG [main] util.ClassSize(246): 1 ts long
2013-04-12 15:33:40,903 DEBUG [main] util.ClassSize(246): 2 durability class
org.apache.hadoop.hbase.client.Durability
2013-04-12 15:33:40,903 DEBUG [main] util.ClassSize(246): 3 familyMap interface
java.util.NavigableMap
2013-04-12 15:33:40,903 DEBUG [main] util.ClassSize(246): 4 attributes
interface java.util.Map
2013-04-12 15:33:40,903 DEBUG [main] util.ClassSize(273): Primitives=8,
arrays=1, references(includes 2 for object overhead)=6, refSize 8, size=80,
prealign_size=80
{code}
I attached an addendum for your references.
Thanks,
-Jeffrey
> Allow a deferred sync option per Mutation.
> ------------------------------------------
>
> Key: HBASE-7801
> URL: https://issues.apache.org/jira/browse/HBASE-7801
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 0.94.6, 0.95.0
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.98.0, 0.94.7, 0.95.1
>
> Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt,
> 7801-0.94-v4.txt, 7801-0.94-v5.txt, 7801-0.96-full-v2.txt,
> 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, 7801-0.96-full-v5.txt,
> 7801-0.96-v10.txt, 7801-0.96-v1.txt, 7801-0.96-v6.txt, 7801-0.96-v7.txt,
> 7801-0.96-v8.txt, 7801-0.96-v9.txt, hbase-7801-addendum.patch
>
>
> Won't have time for parent. But a deferred sync option on a per operation
> basis comes up quite frequently.
> In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a
> special mutation attribute.
> For batch operation we'd take the safest sync option of any of the mutations.
> I.e. if there is at least one that wants to be flushed we'd sync the batch,
> if there's none of those but at least one that wants deferred flush we defer
> flush the batch, etc.
--
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
