[
https://issues.apache.org/jira/browse/HBASE-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643324#comment-15643324
]
Anoop Sam John commented on HBASE-16992:
----------------------------------------
{code}
@VisibleForTesting
+ static long estimatedHeapSizeOf(final Cell cell) {
+ // TODO we need include tags length also here.
+ return KeyValueUtil.keyLength(cell) + cell.getValueLength();
+ }
{code}
Sorry we can not call it estimatedHeapSize(Cell).. The name says it is the
heap space occupied by this Cell. Similar API is there in CellUtil
What we do here is calculate the length of the cell in KV format. And we dont
include tags length. U can see the TODO.
What u can do is use the API KeyValueUtil#length(Cell). This will include tags
length also. That is fine we need that any way.
In place of KeyValueUtil.keyLength(cell) + cell.getValueLength() use the new
length() call. From test also u can use that. No need to add an extra API
within HRegion.
Else ok
Pls attach latest patch for branch-1 also.
Plan to commit to branch-1 and trunk only.
> The usage of mutation from CP is weird.
> ---------------------------------------
>
> Key: HBASE-16992
> URL: https://issues.apache.org/jira/browse/HBASE-16992
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0, 1.3.0, 1.4.0
> Reporter: ChiaPing Tsai
> Assignee: ChiaPing Tsai
> Priority: Minor
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-16992.branch-1.v0.patch, HBASE-16992.v0.patch
>
>
> {code:title=HRegion#doMiniBatchMutate|borderStyle=solid}
> Mutation cpMutation = cpMutations[j];
> Map<byte[], List<Cell>> cpFamilyMap = cpMutation.getFamilyCellMap();
> checkAndPrepareMutation(cpMutation, replay, cpFamilyMap, now);
> // Acquire row locks. If not, the whole batch will fail.
> acquiredRowLocks.add(getRowLockInternal(cpMutation.getRow(), true));
> if (cpMutation.getDurability() == Durability.SKIP_WAL) {
> recordMutationWithoutWal(cpFamilyMap);
> }
> // Returned mutations from coprocessor correspond to the Mutation at index i.
> We can
> // directly add the cells from those mutations to the familyMaps of this
> mutation.
> mergeFamilyMaps(familyMaps[i], cpFamilyMap); // will get added to the
> memstore later
> {code}
> 1. Does the returned mutation from coprocessor have the same row as the
> corresponded mutation? If so, the acquiredRowLocks() can be saved. If not,
> the corresponded mutation may maintain the cells with different row due to
> mergeFamilyMaps().
> 2. Is returned mutation's durability useful? If so, we should deal with the
> different durabilities before mergeFamilyMaps(). If not, the
> recordMutationWithoutWal can be saved.
> 3. If both the returned mutation and corresponded mutation have
> Durability.SKIP_WAL, the recordMutationWithoutWal() may record the duplicate
> cells due to mergeFamilyMaps().
> Any comment? Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
