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
>