[
https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157412#comment-15157412
]
stack commented on HBASE-15205:
-------------------------------
In the first above, the 'entry.getEdit().isReplay()', does that look totally
cryptic to you? Do we ever take this path? If so, when? And if we do, why is it
that we go on to do the append anyway though returning true from preWALWrite
means 'by-pass default behavior'.
For the second item in the above, I see that it is for the replay tool that we
need to set scopes to null in the WALSplitter.
bq. So if I directly pass the scope to WALKey every time during its constrution
then we may have to nullify it where ever it applies.
So, we nullify for a cryptic reason in 1. above and in 2. it makes sense, when
a tool is replaying edits into a live server (though why does it not want to
replicate edits in this second case? It should?)
bq. So if I directly pass the scope to WALKey every time during its constrution
then we may have to nullify it where ever it applies.
bq. I really understand your concern and it makes sense. Let me see what else
can be done but I thought that wil deviate from the scope of the JIRA in case
if we want to make things lighter for the WALEdit and WALKey.
Yeah. Was going to say the same. Whether scope passed on constructor to WALKey
is for another issue, not this one. Already enough going on. Lets not have
scope in two places though... in WALEdit and in WALKey. WALEdit already has
this which makes sense:
{code}
// Only here for legacy writable deserialization
/**
* @deprecated Legacy
*/
@Deprecated
private NavigableMap<byte[], Integer> scopes;
{code}
Let me look at last patch.
> 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,
> 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)
