[
https://issues.apache.org/jira/browse/HBASE-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780340#comment-13780340
]
stack commented on HBASE-9390:
------------------------------
Looking more, would getReplayMutations be better as a static over under wal
package?
We could size these arrays rather than have them expand since we know edit
count on way in?
List<Pair<MutationType, Mutation>> mutations = new
ArrayList<Pair<MutationType, Mutation>>();
List<Pair<MutationType, Mutation>> tmpEditMutations =
new ArrayList<Pair<MutationType, Mutation>>();
getReplayMutations returns a List of Pairs but it seems like we are also
populating the passed in logEntries list as we go. In caller, we use first the
return and then the logEntries. Its kinda odd that the CP on postWALRestore
takes the original form, rather than what we add to the server; I suppose it
would work. Little confusing though.
Structurally it is also odd calling the cp preWAL down inside in
getReplayMutations but the postWAL is up in the calling method.
> coprocessors observers are not called during a recovery with the new log
> replay algorithm
> -----------------------------------------------------------------------------------------
>
> Key: HBASE-9390
> URL: https://issues.apache.org/jira/browse/HBASE-9390
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, MTTR
> Affects Versions: 0.95.2
> Reporter: Nicolas Liochon
> Assignee: Jeffrey Zhong
> Attachments: copro.patch, hbase-9390-part2.patch,
> hbase-9390-part2-v2.patch, hbase-9390.patch, hbase-9390-v2.patch
>
>
> See the patch to reproduce the issue: If we activate log replay we don't have
> the events on WAL restore.
> Pinging [~jeffreyz], we discussed this offline.
--
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
