Date: Thu, 12 Mar 2015 08:53:01 +0000
Thanks Alexey for the quick response
It will take us few more days to test the "latest 2.3.20-SNAPSHOT".
I will keep you update
Thanks
Uri
From: Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Sent: Wednesday, March 11, 2015 9:22 PM
To: users_at_grizzly.java.net
Subject: Re: Grizzly Thread Pool Monitoring
Hi Uri,
On 11.03.15 07:54, Broide Uri wrote:
1. We opened the requested BUG (GRIZZLY-1748<http://cp.mcafee.com/d/avndzgQrhojshKye7c6XCQQmrFIEEFL6QQmrFIELFL6QQmrIEL3DCjqdXLK9I9FLCSUOUx6IAf1iVDUQ_BPqVDUQ_BPrZT3hPuXX_nV5wsMzvHTbFTovVdVBNV7BHFShhlhKPOEuvkzaT0QSyrhdTV5MQsFIT7e6zBcTsSjDdqymo8WpTwrwzaeUgzkNjY2gb3g90AawsKyeoudJQ-d2Zj4fy2ycp2wEumUhQPL0QSyZtB5MS2_id40iz8k53ONEw19efWwq80JmFVEw6WMBeIpg8CSm3qCJWcYkr>).
2. Can you answer my Questions below
The questions are as follows:
1. Are we looking on the right MBean attributes?
Yes.
2. Assuming 1 is true, then why for the same load model the thread pool is reaching this high number (max = core + allocated)?
It's because the probe values reported based on events coming from the thread pool and at the time of probe registration some events are already missed.
3. Why the thread-pool-started attribute is false?
same as above.
I think I've fixed the issue, can you pls. check the latest 2.3.20-SNAPSHOT?
Thanks.
WBR,
Alexey.
From: Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Sent: Tuesday, March 10, 2015 8:15 PM
To: users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>
Subject: Re: Grizzly Thread Pool Monitoring
Hi Uri,
looks like a bug to me, 12 core threads are not counted as allocated.
Can you pls. file an issue?
Thanks.
WBR,
Alexey.
On 10.03.15 10:26, Broide Uri wrote:
Hi
We are performing Stability load run against our Grizzly based application.
We are trying to determine how to monitor the Thread Pool usage via JMX.
We are looking at the ThreadPool MBean (org.glassfish.grizzly:pp=/gmbal-root/TCPNIOTransport[EndPoint.IMAP.NON_SECURED],type=ThreadPool,name=ThreadPool), on the following attributes:
* thread-pool-max-num-threads
* thread-pool-allocated-thread-count
* thread-pool-core-pool-size
We have conducted 2 load runs (with exactly the same load model):
1. max threads was configured to be 200 (verified against thread-pool-max-num-threads)
o from some point of the load run the thread-pool-allocated-thread-count was stabilized on 188
o thread-pool-core-pool-size was fixed on 12
2. max threads was configured to be 300 (verified against thread-pool-max-num-threads)
o from some point of the load run the thread-pool-allocated-thread-count was stabilized on 288
o thread-pool-core-pool-size was fixed on 12
The questions are as follows:
1. Are we looking on the right MBean attributes?
2. Assuming 1 is true, then why for the same load model the thread pool is reaching this high number (max = core + allocated)?
3. Why the thread-pool-started attribute is false?
Attaching the JConsole print screen of the second run
[cid:image001.png_at_01D05B52.9D7A53B0]
Thanks
Uri
________________________________
"This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Comverse Inc. or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to: security_at_comverse.com<mailto:security_at_comverse.com>. Thank You."
________________________________
"This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Comverse Inc. or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to: security_at_comverse.com<mailto:security_at_comverse.com>. Thank You."
________________________________
"This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Comverse Inc. or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to: security_at_comverse.com. Thank You."
(image/png attachment: image001.png)