[
https://issues.apache.org/jira/browse/HBASE-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14545775#comment-14545775
]
Esteban Gutierrez commented on HBASE-13694:
-------------------------------------------
[~anoop.hbase] what StAck said, the decrement is done in finally and we use the
CallQueueSize value to make a decision to push back the client. Is not really
that we are using that amount of heap in the queue, but it can slow down
requests a lot.
[~stack] that is correct, the decrement can be done right away the RPC has been
processed, the time it takes to send the response to the client we max out the
CallQueueSize with new requests. For instance, the queue size is 1GB by default
and if I bump it to 2GB (too bad is a signed int) and I run into the problem
just few seconds later (2x the time with 1GB as expected). After my patch the
reported CallQueueSize is decremented faster and can keep processing requests
for a longer (around 20x the time, after that I've been running into another
issue that pushes back the client in one RS but seems unrelated). Thanks!
> CallQueueSize is incorrectly decremented until the response is sent
> -------------------------------------------------------------------
>
> Key: HBASE-13694
> URL: https://issues.apache.org/jira/browse/HBASE-13694
> Project: HBase
> Issue Type: Bug
> Components: master, regionserver, rpc
> Affects Versions: 2.0.0, 1.1.0, 1.0.2, 1.2.0
> Reporter: Esteban Gutierrez
> Assignee: Esteban Gutierrez
> Attachments:
> 0001-HBASE-13694-CallQueueSize-is-incorrectly-decremented.patch
>
>
> We should decrement the CallQueueSize as soon as we no longer need the call
> around, e.g. after {{RpcServer.CurCall.set(null)}} otherwise we will be only
> pushing back other client requests while we send the response back to the
> client that originated the call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
