Kedar Mhaswade wrote:
> 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.
Another question: Does anyone know upgrade implications of having
a thread-pool (i.e. used by ejb container) defined in domain.xml?
Is that thread-pool upgraded by the SchemaUpdater?
Does it work the same way after upgrade?
asadmin create-threadpool is the command line reflection of the
<thread-pool> element. So, if <thread-pool> has changed,
the command has to change, preferably compatibly.
-Kedar
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
>