hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Zhong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9390) coprocessors observers are not called during a recovery with the new log replay algorithm
Date Fri, 27 Sep 2013 21:14:04 GMT

    [ https://issues.apache.org/jira/browse/HBASE-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780410#comment-13780410
] 

Jeffrey Zhong commented on HBASE-9390:
--------------------------------------

[~saint.ack@gmail.com] Thanks for the good comments.

{quote}
The replay method got redone. What was objective?
{quote}
The reason is that we have to pass the original WALEdits in order to for us to skip replaying
individual WALEdit when preWALRestore(can only work on original WALEdit) returns true. If
we pass mutations(which are extracted from a WALEdit), we can't skip them because we can't
reconstruct the original WALEdit.

{qutoe}
Is this doBatchOp that different from the current one? Could they be the same?
{quote}
This is related to the first one. Since we pass WALEdits from a client, we would convert current
mutations to MutationProto and then inside the doBatchOp, those MutationProtos are converted
back to mutations. In addition, we don't need MultiResponse returned, so the current doBatchOp
will have an extra loop to construct MultiResponse which is eliminated from the override 
doBatchOp. 

{quote}
Looking more, would getReplayMutations be better as a static over under wal package?
...
Structurally it is also odd calling the cp preWAL down inside in getReplayMutations but the
postWAL is up in the calling method.
{quote}
Good question. The original thought is to save one extra loop to skip WALEdits by calling
preWALRestore inside getReplayMutations when we construct the list of mutations. It's possible
to create a static function convert one WALEntry at one time and the caller calls preWALRestore.
I can submit an addendum to cover that. 


{quote}
We could size these arrays rather than have them expand since we know edit count on way in?
{quote}
Good point. Yes for mutations but it's hard for tmpEditMutations as we reuse it for all WALEntries.


                
> 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

Mime
View raw message