[
https://issues.apache.org/jira/browse/HBASE-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780224#comment-13780224
]
stack commented on HBASE-9390:
------------------------------
Looking at the patch again because I just clashed up against it trying to get
HBASE-9612 in.
Should getReplayMutations be in HRegion?
The replay method got redone. What was objective? In my patch from
HBASE-9612, I'd replaced the body of replay by a call to multi; it seemed like
replay hand nothing special going on that multi couldn't handle. W/ this
refactor, I can't do that any more so was wondering what was special (Looks
like its dumbed down just expecting success or an exception).
The new doBatchOp override where we now return state is a bit messy in that we
let the method state out of the method where before it was kept inside the
method and only came out as an exception added to the result pb. You think it
needed? Is this doBatchOp that different from the current one? Could they be
the same? The original returns status only its in the result pb. Would that
work?
Thanks J.
> 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
