Kenneth Saks wrote:
>
> On Oct 14, 2009, at 7:26 PM, 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?
>
> What changed? Don't the thread pools created in domain.xml still each
> have a unique name? All the ejb container does is take the
> thread pool id from the sun-ejb-jar.xml and set it on the orb.
Right, but is the behavior the same? Do the attributes on that thread-pool
mean the same thing as in v2?
>
>>
>> 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
>>
>