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.
>
> 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
>