hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anastasia Braginsky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17662) Disable in-memory flush when replaying from WAL
Date Thu, 23 Feb 2017 10:04:44 GMT

    [ 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

View raw message