[
https://issues.apache.org/jira/browse/HBASE-17937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973257#comment-15973257
]
Abhishek Singh Chouhan commented on HBASE-17937:
------------------------------------------------
Have moved the size update to be just after step 5 and removed from finally as
suggested by [~Apache9] since we don't do the rollback now with the chenged
mvcc.
[~lhofhansl] Agreed that this is a temporary condition till the time we return
from the coprocessor call and proceed to the finally part, however if we have
multiple such requests that seem to take a large amount of time or are stuck,
like our observation recently we can possibly run into large negatives of
memstore sizes (lets say -x mb) so the next flush will happen at x+memstore
flush size which will take more time and so forth.
> Memstore size becomes negative in case of expensive postPut/Delete
> Coprocessor call
> -----------------------------------------------------------------------------------
>
> Key: HBASE-17937
> URL: https://issues.apache.org/jira/browse/HBASE-17937
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0, 1.3.1, 0.98.24
> Reporter: Abhishek Singh Chouhan
> Assignee: Abhishek Singh Chouhan
> Attachments: HBASE-17937.master.001.patch,
> HBASE-17937.master.002.patch
>
>
> We ran into a situation where the memstore size became negative due to
> expensive postPut/Delete Coprocessor calls in doMiniBatchMutate. We update
> the memstore size in the finally block of doMiniBatchMutate, however a queued
> flush can be triggered during the coprocessor calls(if they are taking time
> eg. index updates) since we have released the locks and advanced mvcc at this
> point. The flush will turn the memstore size negative since the value
> subtracted is the actual value flushed from stores. The negative value
> impacts the future flushes amongst others that depend on memstore size.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
