[
https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154033#comment-15154033
]
ramkrishna.s.vasudevan commented on HBASE-15205:
------------------------------------------------
bq.So, you think passing replications scopes through to WALKey the way to go?
It already has scopes so makes sense?
My main concern is that not always the replication scope is needed (like in
replica and DLRs). So once we pass the replication scope we need to nullify it
based on the logEdit. Also take the case of scoping the walEdits. Here too some
times we may not need the replicationScope to be set in the WALKey if there are
no normal edits and only bulk load edits are found (and if the bulk load
replication is not enabled).
I think that is why explicitly WALKey was designed to do setReplicationScopes()
rather than in constrution.
> Do not find the replication scope for every WAL#append()
> --------------------------------------------------------
>
> Key: HBASE-15205
> URL: https://issues.apache.org/jira/browse/HBASE-15205
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15205.patch, HBASE-15205_1.patch,
> HBASE-15205_2.patch, HBASE-15205_3.patch, HBASE-15205_4.patch,
> ScopeWALEdits.jpg, ScopeWALEdits_afterpatch.jpg
>
>
> After the byte[] and char[] the other top contributor for lot of GC (though
> it is only 2.86%) is the UTF_8.newDecoder.
> This happens because for every WAL append we try to calculate the replication
> scope associate with the families associated with the TableDescriptor. I
> think per WAL append doing this is very costly and creates lot of garbage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
