[
https://issues.apache.org/jira/browse/HBASE-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349703#comment-14349703
]
Enis Soztutar commented on HBASE-12562:
---------------------------------------
Thanks Jeff for the review.
bq. You can break the loop after set canDrop to false
done.
bq. 2) Just to check acquiring lock on writestate and memstore are always in
this order
Good point. Moved the {{synchronized (this)}} block out.
bq. 3) There maybe no need for the following condition
Yes, it was there to skip doing refresh if the secondary is already in between
replaying a start flush and commit flush. But removed that as a safe guard (we
can end up with all regions in that state).
bq. 4. Rename getBiggestMemstoreOfSecondaryRegion to
getBiggestMemstoreOfRegionReplica may be better
done
> Handling memory pressure for secondary region replicas
> ------------------------------------------------------
>
> Key: HBASE-12562
> URL: https://issues.apache.org/jira/browse/HBASE-12562
> Project: HBase
> Issue Type: Sub-task
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.1.0
>
> Attachments: hbase-12562_v1.patch
>
>
> This issue will track the implementation of how to handle the memory pressure
> for secondary region replicas. Since the replicas cannot flush by themselves,
> the region server might get blocked or cause extensive flushing for its
> primary regions. The design doc attached at HBASE-11183 contains two possible
> solutions that we can pursue. The first one is to not allow secondary region
> replicas to not flush by themselves, but instead of needed allow them to
> refresh their store files on demand (which possibly allows them to drop their
> memstore snapshots or memstores). The second approach is to allow the
> secondaries to flush to a temporary space.
> Both have pros and cons, but for simplicity and to not cause extra write
> amplification, we have implemented the first approach. More details can be
> found in the design doc, but we can also discuss other options here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
