On 10/14/09 16:38, Kedar Mhaswade wrote:
> 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.
If you want full support for the new thread-pool element, you should add
--classname too.
June
>
> -Kedar
>
>>
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>>
>