On 10/14/09 15:27, Kedar Mhaswade wrote:
> 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"
This is going to confuse users.
June
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>