June.Parks_at_Sun.COM wrote:
> 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.
I was hoping to not go into that. I know nothing about the status of
pluggable thread pool implementation which is what --classname
configures.
For now, this command does not expose --classname, till we know if that
is exposed. All thread pools created by this command use the same
Grizzly thread pool implementation named
com.sun.grizzly.http.StatsThreadPool. I believe that's ok for v3.
>
> 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
>>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>