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?