[
https://issues.apache.org/jira/browse/HBASE-17487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833402#comment-15833402
]
Anastasia Braginsky commented on HBASE-17487:
---------------------------------------------
The snapshot() method's algorithm is as following:
If snapshot is empty (previous flush to disk finished)
a. Stop ongoing in-memory compaction (the stopping request may be missed if
compaction is just about to end)
b. Push active segment to compaction pipeline (as in-memory flush)
c. Push pipeline to snapshot:
# Push references to all pipeline segments to snapshot (the segments
are now referenced both in pipeline and in snapshot)
# Try to swap the pipeline, i.e. remove the references to the segments
in snapshot if no concurrent activity is done now
# If this is not successful (due to concurrent activity) reread the
pipeline and redo the steps 1-2 again.
# *Here is what we are talking about:* if for the third time the swap
is unsuccessful (due to some unknown problem) the snapshot is nullified and we
return with empty snapshot from the pushPipelineToSnapshot() method. All
segments remain as they were in pipeline.
d. The snapshot() method creates a MemStoreSnapshot object as an output. It can
be also an empty MemStoreSnapshot object, this is a valid output.
[~anoop.hbase], as you can see there is no buggy way of taking care in case
when (unexpectedly) the swap fails in third time. The snapshot() method call
fails as if the snapshot was not empty (previous flush to disk didn't finish).
[~ted_yu], I agree to change the LOG from warm to error. Indeed a more correct
to deal with it.
> Throw exception when pushing pipeline to snapshot fails twice
> -------------------------------------------------------------
>
> Key: HBASE-17487
> URL: https://issues.apache.org/jira/browse/HBASE-17487
> Project: HBase
> Issue Type: Improvement
> Reporter: Ted Yu
> Assignee: Ted Yu
> Priority: Minor
> Attachments: 17487.v2.txt
>
>
> In CompactingMemStore#pushPipelineToSnapshot() , there is limit of 3
> iterations of pipeline.swap() call after which an empty ImmutableSegment is
> used as snapshot.
> However, there should be at most two iterations in pushPipelineToSnapshot()
> since during the second iteration there is no concurrent write to memstore.
> We should throw exception in the 3rd iteration to signify that this scenario
> should never happen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
