[
https://issues.apache.org/jira/browse/HBASE-10844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967680#comment-13967680
]
Lars Hofhansl commented on HBASE-10844:
---------------------------------------
I do not think this is right.
The point of no return is when the WAL is synced. If the region server dies
after the sync the edit are replayed and hence the change *will* be visible.
Hence the memstore should not be rolled back after the WAL edit is synced.
postBatchMutate is "post" the batch mutate, so it cannot undo the mutation, it
happened already.
-1 on this change.
> Coprocessor failure during batchmutation leaves the memstore datastructs in
> an inconsistent state
> -------------------------------------------------------------------------------------------------
>
> Key: HBASE-10844
> URL: https://issues.apache.org/jira/browse/HBASE-10844
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Devaraj Das
> Assignee: Devaraj Das
> Fix For: 0.99.0, 0.94.19, 0.98.2, 0.96.3
>
> Attachments: 10844-1.txt
>
>
> Observed this in the testing with Phoenix. The test in Phoenix -
> MutableIndexFailureIT deliberately fails the batchmutation call via the
> installed coprocessor. But the update is not rolled back. That leaves the
> memstore inconsistent. In particular, I observed that getFlushableSize is
> updated before the coprocessor was called but the update is not rolled back.
> When the region is being closed at some later point, the assert introduced in
> HBASE-10514 in the HRegion.doClose() causes the RegionServer to shutdown
> abnormally.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
