June.Parks_at_Sun.COM wrote:
> On 10/14/09 13:59, Bill Shannon wrote:
>> June.Parks_at_sun.com wrote on 10/14/09 08:58:
>>> On 10/13/09 16:05, Bill Shannon wrote:
>>>> Nachiappan Veerappan Nachiappan wrote on 10/13/09 10:46 AM:
>>>>
>>>>> Dixie,
>>>>>
>>>>> In create-threadpool command man page the option --workqueues (V2) has
>>>>> been changed to --max-queue-size in V3.
>>>>> Please change that to --workqueues.
>>>>>
>>>>
>>>> I don't understand. Please change *what* to "--workqueues"?
>>>>
>>>> Why was the name of the option changed incompatibly between v2 and v3?
>>>> Did you mean that you were going to change the code to rename the
>>>> option
>>>> to be compatible with v2?
>>>>
>>> Behind the scenes the num-work-queues attribute has been removed and
>>> max-queue-size has been added in v3. The Grizzly engineers have the
>>> details. Perhaps --workqueues should be a no-op. It would be
>>> confusing to use --workqueues for the max-queue-size attribute,
>>> because --workqueues accepted a number of queues while max-queue-size
>>> accepts a number of bytes.
>>
>>
>> Nachiappan Veerappan Nachiappan wrote on 10/13/09 16:54:
>> > Bill Shannon wrote:
>> >> Nachiappan Veerappan Nachiappan wrote on 10/13/09 10:46 AM:
>> >>
>> >>> Dixie,
>> >>>
>> >>> In create-threadpool command man page the option --workqueues (V2)
>> has
>> >>> been changed to --max-queue-size in V3.
>> >>> Please change that to --workqueues.
>> >>>
>> >>
>> >> I don't understand. Please change *what* to "--workqueues"?
>> >>
>> > The create-threadpool command man page which was sent for review had
>> the
>> > option --workqueues changed to --max-queue-size. So i requested
>> Dixie to
>> > change that to --workqueues, because the command implementation has
>> > --workqueues as option name.
>> >> Why was the name of the option changed incompatibly between v2 and v3?
>> >>
>> > The name of the option was not changed in the command implementation.
>> > There is no incompatibility issue with regards to command
>> implementation
>> > between v2 and v3. All the options have the same name as in V2.
>>
>>
>> Which of the above is correct?
> You can verify for yourself that num-work-queues doesn't exist and
> max-queue-size does by running Tim Quinn's ConfigAnalyzer tool:
>
> http://wiki.glassfish.java.net/Wiki.jsp?page=DomainXMLv3Structure
>
> As for what the create-threadpool command does, I'd suggest making
> --workqueues a no-op and adding an option with a name like
> --maxqueuesize or --max-queue-size. (Option names without spaces are
> what we've used in the past, and they're slightly shorter, but if you
> want to move toward having new options match their attribute names, I
> won't object.)
>
> The units for max-queue-size are messages, not bytes as I stated
> previously.
>
> June
>>
>> Hopefully you didn't keep the option name the same but change its
>> semantics.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
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).
-Kedar