[
https://issues.apache.org/jira/browse/HBASE-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879887#comment-15879887
]
ramkrishna.s.vasudevan commented on HBASE-17662:
------------------------------------------------
The changes looks good to me. did you check for [~anoop.hbase]'s suggestion
that if AtomicBoolean is a must here? Once you feel you have checked it then we
can get this in.
[[email protected]]
What ever Anoop says. They are just avoiding in memory flushes not the flush to
disk. The only thing could be that in case we have lot of duplicates in the
actual write path and this in memory flush had avoided those duplicates but the
server crashed on replay we may get lot of duplicates for those WAL entries. I
think it is not going to affect the data that can be seen but just that they
will be removed on a compaction only.
> 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)
