Skip to main content

WorkManager queue size

5 replies [Last post]
Anonymous

Hi.
I have been looking at using the WorkManager API to execute HTTP requests
asynchronously. The hand-off and everything works like a champ, but now I am
interested in checking the queue size of the WorkManager. If the queue size
is bigger than a certain limit I want to fail fast rather than to pile up
request on the thread pool.

So. Basically I'm getting my WorkManager like this:
CommonWorkManager workManager =
(CommonWorkManager)WorkManagerFactory.getWorkManager(threadpool);

But when I try to access any statistical methods, like this:
long queueSize = workManager.getWaitQueueength();
I get NullPointers.

I have set monitoring service for 'Thread Pool' in glassfish to HIGH. I can
see the statistics in the glassfish admin interface and through JMX.

I have tried to set the monitoring flag directly in my code like this:
workManager.setMonitoringEnabled(true);

That fixes the NullPointers, but now I get zeros only. I am suspecting this
may be incorrect usage, but anyway. I see the stats increasing (queue-size
etc) when applying load, but only in the admin & JMX, never in my
application.

So, my question is: Does anyone know how to got the queue size of a
WorkManager in Glassfish programmatically?

It seems like such a waste to have to go through JMX just to get the size of
the underlying queue in the thread pool.

--
View this message in context: http://www.nabble.com/WorkManager-queue-size-tp23158627p23158627.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
FredrikJ

Update -

It seems like the CommonWorkManager is created once per request and is not
designed to be used as a shared resource (thread unsafe?). The statistical
methods are tied to the CWM instance only and no the underlying thread pool.

This means that when you call getWaitQueueength() for instance, you only get
the count of task you have assigned to this specific instance of CWM. Why I
would be interested in this instead of the shared queue size is beyond me...
but anyway, that seems to be the case.

So, since I can't use the work manager to inspect the work queue I made a
hack to get and check the queue directly, it looks a bit like this (without
failure handling etc):

public int getQueueSize(String threadpool) {
ThreadPoolManager threadpoolManager =
S1ASThreadPoolManager.getThreadPoolManager();
ThreadPool tp = threadpoolManager.getThreadPool(threadpool);
WorkQueue queue = tp.getAnyWorkQueue();
return queue.workItemsInQueue();
}

So we do have a working queue size lookup now, but it feels like a major
hack. I would argue that the returned CommonWorkManager should be able to
return proper data for the shared thread pool(s) and not the instance local
data.

--
View this message in context: http://www.nabble.com/WorkManager-queue-size-tp23158627p23197363.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jagadish Prasath Ramu

On Thu, 2009-04-23 at 07:29 -0700, FredrikJ wrote:
> Update -
>
> It seems like the CommonWorkManager is created once per request and is not
> designed to be used as a shared resource (thread unsafe?). The statistical
> methods are tied to the CWM instance only and no the underlying thread pool.
>
> This means that when you call getWaitQueueength() for instance, you only get
> the count of task you have assigned to this specific instance of CWM. Why I
> would be interested in this instead of the shared queue size is beyond me...
> but anyway, that seems to be the case.
Yes, it represents the work-manager's usage of threads.
You can dedicate the thread-pool (asadmin create-thread-pool) only for a
particular task and hence the statistics will be the real representation
of the task that you are trying to monitor.

>
> So, since I can't use the work manager to inspect the work queue I made a
> hack to get and check the queue directly, it looks a bit like this (without
> failure handling etc):
>
> public int getQueueSize(String threadpool) {
> ThreadPoolManager threadpoolManager =
> S1ASThreadPoolManager.getThreadPoolManager();
> ThreadPool tp = threadpoolManager.getThreadPool(threadpool);
> WorkQueue queue = tp.getAnyWorkQueue();
> return queue.workItemsInQueue();
> }
>
> So we do have a working queue size lookup now, but it feels like a major
> hack. I would argue that the returned CommonWorkManager should be able to
> return proper data for the shared thread pool(s) and not the instance local
> data.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

FredrikJ

Jagadish Prasath Ramu wrote:
>
> Yes, it represents the work-manager's usage of threads.
> You can dedicate the thread-pool (asadmin create-thread-pool) only for a
> particular task and hence the statistics will be the real representation
> of the task that you are trying to monitor.
>

Let me try to explain what I mean a bit better;

One thread pool will have many short-lived CommonWorkManagers associated
with it. The reason for this is that a new CommonWorkManager is created
every time I ask the WorkManagerFactory for a work manager.

When I ask the CommonWorkManager for the queue size, I would expect to get
the queue size of the thread pool, which is what I think you mean in your
reply as well.

But I don't. I basically get the number of task that I have added to this
particular CommonWorkManager (on the current thread, in the current
invocation scope). This count is completely unrelated to the thread pool's
queue size or thread usage.

So when you say 'it represents the work-manager's usage of threads', I think
that is not currently the case at all. The CWM will only live between my
call to the factory and to I have added my task local to my current thread
and method invocation.
--
View this message in context: http://www.nabble.com/WorkManager-queue-size-tp23158627p23211377.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jagadish Prasath Ramu

On Fri, 2009-04-24 at 00:34 -0700, FredrikJ wrote:
>
> Jagadish Prasath Ramu wrote:
> >
> > Yes, it represents the work-manager's usage of threads.
> > You can dedicate the thread-pool (asadmin create-thread-pool) only for a
> > particular task and hence the statistics will be the real representation
> > of the task that you are trying to monitor.
> >
>
> Let me try to explain what I mean a bit better;
>
> One thread pool will have many short-lived CommonWorkManagers associated
> with it.
CommonWorkManager is used *only* by connector container and the expected
usage is, one work-manager per resource-adapter (throughout its
life-cycle). I guess, you are using the CommonWorkManager outside of
this scope.
> The reason for this is that a new CommonWorkManager is created
> every time I ask the WorkManagerFactory for a work manager.
Yes, every time you ask the Factory, it will provide new work-manager
(in-line with the above design of connector container)
>
> When I ask the CommonWorkManager for the queue size, I would expect to get
> the queue size of the thread pool, which is what I think you mean in your
> reply as well.
No. It is the usage of the threads by a particular instance of the
WorkManager.
The monitoring stats are specific to the work manager and not for the
pool.
Hence, if you have dedicated the thread pool for only one work manager,
then it will help to achieve your requirement of work-manager statistics
reflecting the thread-pool usage also.
>
> But I don't. I basically get the number of task that I have added to this
> particular CommonWorkManager (on the current thread, in the current
> invocation scope). This count is completely unrelated to the thread pool's
> queue size or thread usage.
Please refer the above response.
Probably you may want to cache the work-manager across the requests to
achieve your requirement.

>
> So when you say 'it represents the work-manager's usage of threads', I think
> that is not currently the case at all. The CWM will only live between my
> call to the factory and to I have added my task local to my current thread
> and method invocation.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

FredrikJ

Jagadish Prasath Ramu wrote:
>
>
>> The reason for this is that a new CommonWorkManager is created
>> every time I ask the WorkManagerFactory for a work manager.
> Yes, every time you ask the Factory, it will provide new work-manager
> (in-line with the above design of connector container)
>>
>> When I ask the CommonWorkManager for the queue size, I would expect to
>> get
>> the queue size of the thread pool, which is what I think you mean in your
>> reply as well.
> No. It is the usage of the threads by a particular instance of the
> WorkManager.
> The monitoring stats are specific to the work manager and not for the
> pool.
> Hence, if you have dedicated the thread pool for only one work manager,
> then it will help to achieve your requirement of work-manager statistics
> reflecting the thread-pool usage also.
>
> ...
>
> Probably you may want to cache the work-manager across the requests to
> achieve your requirement.
>

Thanks for your quick answers!
What you describe that seems to be on par with what I am experiencing. I
have no problem with caching a single instance of the work manager so that
might work for me :)

However, the reason I decided no to do this was from looking at the source,
here is the WorkManagerFactory:
http://fisheye5.cenqua.com/browse/glassfish/appserv-core/src/java/com/su...

More specifically:
// Default work manager implementation is not a singleton.
if (className.equals(DEFAULT)) {
return new CommonWorkManager(poolName);
}

Which doesn't seem to guarantee or even imply that the returned
CommonWorkManager is thread safe, and thus ok to cache and share. Is it? (if
I cache the factory returned manager, then it certainly needs to be
guaranteed thread safe, not just for this version but presumably for future
upgrade versions as well...)

--
View this message in context: http://www.nabble.com/WorkManager-queue-size-tp23158627p23213203.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net