[
https://issues.apache.org/jira/browse/HBASE-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881686#comment-15881686
]
Anoop Sam John commented on HBASE-17662:
----------------------------------------
I was just asking whether the WAL replay handling (And so this boolean write
and read) being done by single thread only or not. Did not read the code. My
worry on the 1st patch was that, it was doing a volatile read on every Cell
addition.. Now we have changed it so that once the in memory flush size limit
reached, we will do the boolean read to confirm it is not a replay time. So we
are ok IMO. Understood u made it AtomicBoolean in a preventive way. Am ok
with that way also provided we moved the boolean check as 2nd check now.
> 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, HBASE-17662-V05.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)
