users@grizzly.java.net

Re: finding out the available threads in a thread pool

From: Ryan Lubke <ryan.lubke_at_oracle.com>
Date: Wed, 15 Sep 2010 08:15:57 -0700

I believe you can obtain the information you want from GrizzlyMonitoring:

------------------------------------
public ThreadPoolStatsProvider getThreadPoolStatsProvider(String name) {
         return threadPoolStatsProvidersMap.get(name);
  }
------------------------------------

The 'name' argument represents the network listener with which the pool is
associated.

In order to get the GrizzlyMonitoring instance, you will need to lookup
or @Inject
the GrizzlyService from the habitat. Once you have a reference to
GrizzlyService,
you can call GrizzlyService.getMonitoring().

On 9/14/10 12:47 PM, Carla Mott wrote:
>
> HI Alexey,
>
> I see in ThreadPoolStatsProvider the following:
>
>
> @ManagedAttribute(id = "currentthreadsbusy")
> @Description("Provides the number of request processing threads
> currently in use in the listener thread pool serving requests.")
> public CountStatistic getCurrentThreadsBusy() {
> return currentThreadsBusy;
> }
>
> Which seems to be what I want. I don't understand how to use the
> probe listeners to get that. What am I missing? I looked at the
> monitoring screens and didn't see anything that got this kind of info
> or any info about the thread pool.
>
> Thanks for your help.
>
> Carla
>
>
> Oleksiy Stashok wrote:
>> Hi Carla,
>>
>> sorry for the delay in response.
>> The current API just let's you register the monitoring probe and
>> listen for thread-pool events. In the GF environment you can use
>> probe listeners to achieve this.
>> Please look at the class [1] in the v3/core/kernel module. It has
>> registered probe listeners, which change the current stats values
>> like [3].
>>
>> Regarding the core/max pool size, you can get it from the GF
>> configuration objects [2]
>>
>> WBR,
>> Alexey.
>>
>> [1]
>> com.sun.enterprise.v3.services.impl.monitor.stats.ThreadPoolStatsProvider
>>
>> [2]@Inject(name=ServerEnvironment.DEFAULT_INSTANCE_NAME)
>> private Config serverConfig;
>>
>> [3]
>> @ProbeListener("glassfish:kernel:thread-pool:setMaxThreadsEvent")
>> public void setMaxThreadsEvent(
>> @ProbeParam("monitoringId") String monitoringId,
>> @ProbeParam("threadPoolName") String threadPoolName,
>> @ProbeParam("maxNumberOfThreads") int maxNumberOfThreads) {
>>
>> if (name.equals(monitoringId)) {
>> maxThreadsCount.setCount(maxNumberOfThreads);
>> }
>> }
>>
>> @ProbeListener("glassfish:kernel:thread-pool:setCoreThreadsEvent")
>> public void setCoreThreadsEvent(
>> @ProbeParam("monitoringId") String monitoringId,
>> @ProbeParam("threadPoolName") String threadPoolName,
>> @ProbeParam("coreNumberOfThreads") int
>> coreNumberOfThreads) {
>>
>> if (name.equals(monitoringId)) {
>> coreThreadsCount.setCount(coreNumberOfThreads);
>> }
>> }
>>
>> @ProbeListener("glassfish:kernel:thread-pool:threadAllocatedEvent")
>> public void threadAllocatedEvent(
>> @ProbeParam("monitoringId") String monitoringId,
>> @ProbeParam("threadPoolName") String threadPoolName,
>> @ProbeParam("threadId") String threadId) {
>>
>> if (name.equals(monitoringId)) {
>> currentThreadCount.increment();
>> }
>> }
>>
>> @ProbeListener("glassfish:kernel:thread-pool:threadReleasedEvent")
>> public void threadReleasedEvent(
>> @ProbeParam("monitoringId") String monitoringId,
>> @ProbeParam("threadPoolName") String threadPoolName,
>> @ProbeParam("threadId") String threadId) {
>>
>> if (name.equals(monitoringId)) {
>> currentThreadCount.decrement();
>> }
>> }
>>
>>
>> @ProbeListener("glassfish:kernel:thread-pool:threadDispatchedFromPoolEvent")
>>
>> public void threadDispatchedFromPoolEvent(
>> @ProbeParam("monitoringId") String monitoringId,
>> @ProbeParam("threadPoolName") String threadPoolName,
>> @ProbeParam("threadId") String threadId) {
>>
>> if (name.equals(monitoringId)) {
>> currentThreadsBusy.increment();
>> }
>> }
>>
>>
>> @ProbeListener("glassfish:kernel:thread-pool:threadReturnedToPoolEvent")
>> public void threadReturnedToPoolEvent(
>> @ProbeParam("monitoringId") String monitoringId,
>> @ProbeParam("threadPoolName") String threadPoolName,
>> @ProbeParam("threadId") String threadId) {
>>
>> if (name.equals(monitoringId)) {
>> totalExecutedTasksCount.increment();
>> currentThreadsBusy.decrement();
>> }
>> }
>>
>>
>>> Hi Alexey,
>>>
>>> Thanks for the info. I really just want to reduce the likely hood
>>> of there being a deadlock. We think that getting the max size and
>>> the current pool size and if there are at least 40% more available
>>> threads we will go ahead and try the operation is a reasonable
>>> measure for us. I understand that the current number of available
>>> threads is dynamic but that is ok because we don't need the exact
>>> number.
>>> It seems from you comments that there is a way to get that number.
>>> Is there an api?
>>>
>>> Thanks,
>>> Carla
>>>
>>> Oleksiy Stashok wrote:
>>>> Hi Carla,
>>>>
>>>> unfortunately it's not possible to reserve a thread in the thread
>>>> pool.
>>>> Checking the avail. threads number won't help, cause this value is
>>>> dynamic and could be used just for monitoring stats.
>>>>
>>>> The solution you may want to use - is to create custom thread pool,
>>>> which you'll be able to control within your code, use
>>>> synchronizations etc...
>>>>
>>>> So when HTTP request comes and you realize that it's *the* command
>>>> - you can suspend the request processing in the current thread and
>>>> pass it to the custom thread. Once processing is done - you can
>>>> resume the HTTP processing.
>>>> When saying suspend/resume, I'm referring to the
>>>> GrizzlyResponse.suspend/resume methods.
>>>>
>>>> Hope this will help.
>>>> If you have more questions - please ask.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>> On Sep 9, 2010, at 23:36 , Carla Mott wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm writing a command in glassfish and we found that we can
>>>>> potentially end up with a deadlock. The issue is that some
>>>>> commands use 2 threads to complete the operation. When we run the
>>>>> command simultaneously can run into a deadlock.
>>>>> We have increased the size of the pool but doesn't solve the
>>>>> problem. I would like to get the max size and either the number
>>>>> of threads in use or the number available so I can figure out if I
>>>>> should attempt the operation. It seems that the only thing that
>>>>> I'm able to find out is the max poll size number. Is there any
>>>>> way to figure out the info I'm looking for?
>>>>>
>>>>> Thanks,
>>>>> Carla
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>