[
https://issues.apache.org/jira/browse/HBASE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773583#comment-13773583
]
Jean-Daniel Cryans commented on HBASE-9333:
-------------------------------------------
Latest patch works, but it consumes a lot more memory, so much that I can't run
my test with the default heap.
Comparing this to the solution where I set the per-AsyncProcess tasks to a
lower number (but equal to the default with this patch in aggregate, 256), it's
using 1GB less heap. In other words, it seems that having 200 tasks for the 16
AsyncProcess plus the queue for the executor pool uses a lot more memory for
the same result.
But just setting hbase.client.max.total.tasks doesn't scale well for single
clients that talk to multiple region servers.
Should we go back to the idea of making hbase.client.max.total.tasks truly
global?
> hbase.hconnection.threads.max should not be configurable else you get
> RejectedExecutionException
> ------------------------------------------------------------------------------------------------
>
> Key: HBASE-9333
> URL: https://issues.apache.org/jira/browse/HBASE-9333
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.95.2
> Reporter: Jean-Daniel Cryans
> Assignee: Elliott Clark
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9333-0.patch, HBASE-9333-1.patch,
> HBASE-9333-2.patch
>
>
> Trying to set hbase.hconnection.threads.max to a lower number than its
> default of Integer.MAX_VALUE simply results in a RejectedExecutionException
> when the max is reached. It seems there's no good reason to keep this
> configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
