admin@glassfish.java.net

Re: Review of create-threadpool, delete-threadpool, list-threadpools man pages

From: Kedar Mhaswade <Kedar.Mhaswade_at_Sun.COM>
Date: Wed, 14 Oct 2009 16:26:50 -0700

Bill Shannon wrote:
> Kedar Mhaswade wrote on 10/14/09 15:27:
>> Bill,
>>
>> This has become more confusing than it needs to and one of the reasons
>> is that the way thread pool is used by the runtime has changed from v2
>> to v3.
>>
>> In v2, apparently we had two different thread pool implementations and
>> in v3 we have single thread pool implementation. This thread pool
>> implementation and its configuration (the ThreadPool config bean) comes
>> from Grizzly in v3, as part of the new Grizzly Config Project.
>> We should ask Ken/Justin if the configuration created by this command is
>> interpreted differently by the runtime in v3 and how.
>>
>> What Nachiappan has done is keep the asadmin command line the same and
>> only made the changes to domain.xml dictated by the new ThreadPool
>> config bean (changes are: --workqueues => bean's "max-queue-size"
>> attribute (it was "num-work-queues" before) and the "thread-pool-id" has
>> now become its "name") which now comes from Grizzly codebase.
>>
>> He does not know the runtime implications of running this command
>> (neither do I).
>
> But wait...
>
> Aren't the units different here?
>
> Isn't max-queue-size in units of messages, and workqueues is in units
> of number of queues?
>
> I think it's time for one of you to learn the runtime implications of
> running this command.
>
> If you can't support the semantics of the v2 option compatibly, then it's
> time to deprecate/remove the option and create a new option with a
> different
> name.
>
> Really, who thought it was compatible to keep the name but change the
> semantics?

I think it has fallen through cracks.

Ken Saks, can you please help here? Are we sure that
ejb-jar.xml/use-thread-pool-id behavior (which is what the thread pool
created by create-threadpool command is referenced by)
remaining compatible from v2 to v3?

If that's the case, then we should deprecate the --workqueues (make it
a no-op, really) to add --maxqueuesize.


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>