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
>