[
https://issues.apache.org/jira/browse/HBASE-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790587#comment-14790587
]
stack commented on HBASE-10449:
-------------------------------
Thanks [~nkeywal]
bq. We should not see 256 threads, because they should expire already
Maybe they spin up inside the keepalive time of 60 seconds.
bq. We will still have 60 threads, because each new request will create a new
thread until we reach coreSize
Well, I was thinking that we'd go to core size -- say # of cores -- and then if
one request a second, we'd just stay at core size because there would be a free
thread when the request-per-second came in (assuming request took a good deal <
a second).
Let me look at HBASE-11590.
What I saw was each client with hundreds -- up to 256 on one -- threads all in
WAITING like follows:
{code}
"hconnection-0x3065a6a9-shared--pool13-t247" daemon prio=10
tid=0x00007f31c1ab2000 nid=0x7718 waiting on condition [0x00007f2f9ecec000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007f841b388> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
at
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{code}
... usually in TestReplicasClient. Here is example:
https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/15581/consoleText
See zombies on the end.
I also have second thoughts on HBASE-114433. I am going to change it so we set
config for tests only. We need to do more work before can set the core threads
down from max is what I am thinking.
Thanks [~nkeywal] I'll look at HBASE-11590.
Didn't we have a mock server somewhere such that we could standup a client with
no friction and watch it in operation? I thought we'd make such a beast....
> Wrong execution pool configuration in HConnectionManager
> --------------------------------------------------------
>
> Key: HBASE-10449
> URL: https://issues.apache.org/jira/browse/HBASE-10449
> Project: HBase
> Issue Type: Bug
> Components: Client
> Affects Versions: 0.98.0, 0.99.0, 0.96.1.1
> Reporter: Nicolas Liochon
> Assignee: Nicolas Liochon
> Priority: Critical
> Fix For: 0.98.0, 0.96.2, 0.99.0
>
> Attachments: HBASE-10449.v1.patch
>
>
> There is a confusion in the configuration of the pool. The attached patch
> fixes this. This may change the client performances, as we were using a
> single thread.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
