[
https://issues.apache.org/jira/browse/HBASE-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880213#comment-15880213
]
Anastasia Braginsky commented on HBASE-17662:
---------------------------------------------
Hi Guys!
Great to see, you paid attention to this patch :)
[~anoop.hbase], regarding the Boolean vs AtomicBoolean issue: I made the
Boolean Atomic not because it was critical in the current path, but to be on
the safe side for the future, if the concurrency of the replay might change. I
feel that using AtomicBoolean may not cause any performance degradation, but I
can change it to simple boolean.
[~stack], please pay attention that we are talking about in-memory flush and
not flush to disk. Turning off flushing in-memory, will not mess anything up.
The flush to disk will still happen by the end of replay similarly to the case
with DefaultMemStore. As you have mention, requiring the replay process to take
the update lock is meaningless, because this will cause all in-memory flushes
to happen all together by the end of replay process and just before flushing to
disk.
[~ram_krish], in case we have lot of duplicates in the actual write path, then
those duplicates (after replay) will be removed by flush-to-disk instead of
in-memory-flush. So the final state of the data (after replay) will be the same
with and without the crash. Do you agree?
> Disable in-memory flush when replaying from WAL
> -----------------------------------------------
>
> Key: HBASE-17662
> URL: https://issues.apache.org/jira/browse/HBASE-17662
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
> Assignee: Anastasia Braginsky
> Attachments: HBASE-17662-V02.patch, HBASE-17662-V03.patch,
> HBASE-17662-V04.patch
>
>
> When replaying the edits from WAL, the region's updateLock is not taken,
> because a single threaded action is assumed. However, the thread-safeness of
> the in-memory flush of CompactingMemStore is based on taking the region's
> updateLock.
> The in-memory flush can be skipped in the replay time (anyway everything is
> flushed to disk just after the replay). Therefore it is acceptable to just
> skip the in-memory flush action while the updates come as part of replay from
> WAL.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
