[
https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ramkrishna.s.vasudevan updated HBASE-15205:
-------------------------------------------
Attachment: HBASE-15205_7.patch
bq.FSWALEntry still has replicationScope. That intentional? I thought only
WALKey was going to have scopes?
Yes Stack as said in my earlier comments I was not able to directly pass it to
WALKey on construction. Hence using the replicationScope in FSWAlEntry to be
passed directly to HLog.append() and use that scope to be set on the WALKey.
Corrected the failing testcase. Patch for QA before commit.
> 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-15204_6.patch, HBASE-15205.patch,
> HBASE-15205_1.patch, HBASE-15205_2.patch, HBASE-15205_3.patch,
> HBASE-15205_4.patch, HBASE-15205_6.patch, HBASE-15205_6.patch,
> HBASE-15205_7.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)
