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.
>
>