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/sun/enterprise/connectors/work/WorkManagerFactory.java?r=1.5.6.1
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.