[
https://issues.apache.org/jira/browse/HBASE-16407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15436333#comment-15436333
]
ramkrishna.s.vasudevan commented on HBASE-16407:
------------------------------------------------
went thro the patch. Looks great overall. All threading issues seems to be
addressed.
Two things - you can check
{code}
- void putbackChunks(BlockingQueue<PooledChunk> chunks) {
- assert reclaimedChunks.size() < this.maxCount;
+ synchronized void putbackChunks(BlockingQueue<PooledChunk> chunks) {
+ int toAdd = Math.min(chunks.size(), this.maxCount -
reclaimedChunks.size());
PooledChunk chunk = null;
- while ((chunk = chunks.poll()) != null) {
+ while ((chunk = chunks.poll()) != null && toAdd > 0) {
reclaimedChunks.add(chunk);
+ toAdd--;
}
{code}
It is good that the assertion is changed. But with the above condition
when will we clear the chunks in the 'chunks' queue? I think the toAdd
condition should be used only to avoid reclaimedChunk.add() but chunks.poll
should happen anyway? There is a chance that the toAdd may be negative at the
first time itself. So no one to remove from chunks.
bq.public void registerTuneObserver(HeapMemoryTuneObserver observer) {
Should this have a method to deregister things? For clearing things and for
proper RS shutdown.
Should there be a % after which the maxCount should be adjusted? Rather than
just adjusting it every time the value changes?
> Handle MemstoreChunkPool size when HeapMemoryManager tunes memory
> -----------------------------------------------------------------
>
> Key: HBASE-16407
> URL: https://issues.apache.org/jira/browse/HBASE-16407
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-16407.patch, HBASE-16407_V2.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
