June.Parks_at_Sun.COM wrote:
> 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
I agree. But there is a bigger CCC task here -- changes to thread-pool
implementation from v2 to v3 and its impact on users who use newly
created/configured thread-pools for their applications. IMO, the CCC
request in that case should be filed by those who know how it has
changed. We in admin team don't know that.
-Kedar
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>