Well, yes, and I will fix it. Sorry.
dixie
On 10/19/09 18:19, Bill Shannon wrote:
> Shouldn't the description for --workqueues say that it's just there for
> compatibility and you shouldn't specify it (as you've done for other
> similar options elsewhere)?
>
>
> Dixie Pine wrote on 10/16/09 5:04 PM:
>
>> Attached is udpated man page for create-threadpool. Let me know if
>> further changes are needed. I used june's description for maxqueuesize.
>> Dixie
>>
>> On 10/16/09 11:45, Justin Lee wrote:
>>
>>> Right. And to ignore the classname attribute.
>>>
>>> June.Parks_at_Sun.COM wrote:
>>>
>>>> Hi Dixie,
>>>>
>>>> The emerging consensus seems to be to retain --workqueues so user
>>>> scripts don't break but have it do nothing, and to add --maxqueuesize
>>>> to allow setting of the new attribute. But the engineers would know
>>>> for sure.
>>>>
>>>> June
>>>>
>>>> On 10/16/09 10:45, Dixie Pine wrote:
>>>>
>>>>> Justin, Nachi,
>>>>>
>>>>> There's no way your hapless man page writer can tell if I need to
>>>>> make changes to any of these man pages. It looks as
>>>>> if the discussion has wound down, so please let me know if I need to
>>>>> change anything. Attached latest pdfs.
>>>>>
>>>>> Dixie
>>>>>
>>>>> On 10/14/09 19:41, Justin Lee wrote:
>>>>>
>>>>>> The classname attribute of the ThreadPool interface is, as I
>>>>>> understand, largely for grizzly stand alone users. It's not
>>>>>> expected that glassfish users would ever have cause to change this
>>>>>> value. While it's certainly a possibility, the chances are pretty
>>>>>> remote. I think it's fine not to expose this value through the
>>>>>> asadmin command as it will only lead to support issues. To be
>>>>>> honest, that value doesn't appear to be supported in grizzly
>>>>>> anymore due to a recent refactoring done to address some http vs
>>>>>> https support. It might even be ok to drop that attribute
>>>>>> altogether, though Jeanfrancois/Alexey would have to comment on
>>>>>> that as I'm not familiar with the original need that led to its
>>>>>> inclusion.
>>>>>>
>>>>>> I'm not terribly familiar with the grizzly implementation in 2.1,
>>>>>> but for the *webcontainer* usage of the thread pool definition, its
>>>>>> sets those values (among others) on the SelectorThread class
>>>>>> (specifically the GrizzlyEmbeddedHttp[s] subclass of
>>>>>> SelectorThread). The exact code is this below. The default
>>>>>> implementation uses StatsThreadPool.
>>>>>>
>>>>>> private void configureThreadPool(NetworkListener networkListener,
>>>>>> ThreadPool threadPool, int keepAlive) {
>>>>>> if (threadPool == null) {
>>>>>> return;
>>>>>> }
>>>>>> try {
>>>>>> final int maxQueueSize = threadPool.getMaxQueueSize() !=
>>>>>> null ? Integer.MAX_VALUE
>>>>>> : Integer.parseInt(threadPool.getMaxQueueSize());
>>>>>> final int minThreads =
>>>>>> Integer.parseInt(threadPool.getMinThreadPoolSize());
>>>>>> final int maxThreads =
>>>>>> Integer.parseInt(threadPool.getMaxThreadPoolSize());
>>>>>> final int timeout =
>>>>>> Integer.parseInt(threadPool.getIdleThreadTimeoutSeconds());
>>>>>> final String name = networkListener.getName();
>>>>>>
>>>>>> setThreadPool(newThreadPool(name, minThreads, maxThreads,
>>>>>> maxQueueSize,
>>>>>> keepAlive < 0 ? Long.MAX_VALUE : keepAlive * 1000,
>>>>>> TimeUnit.MILLISECONDS));
>>>>>> setCoreThreads(minThreads);
>>>>>> setMaxThreads(maxThreads);
>>>>>>
>>>>>> List<String> l =
>>>>>> ManagementFactory.getRuntimeMXBean().getInputArguments();
>>>>>> boolean debugMode = false;
>>>>>> for (String s : l) {
>>>>>> if (s.trim().startsWith("-Xrunjdwp:")) {
>>>>>> debugMode = true;
>>>>>> break;
>>>>>> }
>>>>>> }
>>>>>> if (!debugMode && timeout > 0) {
>>>>>> // Idle Threads cannot be alive more than 15 minutes
>>>>>> by default
>>>>>> setTransactionTimeout(timeout * 1000);
>>>>>> } else {
>>>>>> // Disable the mechanism
>>>>>> setTransactionTimeout(-1);
>>>>>> }
>>>>>> } catch (NumberFormatException ex) {
>>>>>> logger.log(Level.WARNING, " Invalid thread-pool
>>>>>> attribute", ex);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kedar Mhaswade wrote:
>>>>>>
>>>>>>> June.Parks_at_Sun.COM wrote:
>>>>>>>
>>>>>>>> On 10/14/09 16:38, Kedar Mhaswade wrote:
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>> If that's the case, then we should deprecate the --workqueues
>>>>>>>>>> (make it
>>>>>>>>>> a no-op, really) to add --maxqueuesize.
>>>>>>>>>>
>>>>>>>>> Another question: Does anyone know upgrade implications of having
>>>>>>>>> a thread-pool (i.e. used by ejb container) defined in domain.xml?
>>>>>>>>> Is that thread-pool upgraded by the SchemaUpdater?
>>>>>>>>> Does it work the same way after upgrade?
>>>>>>>>>
>>>>>>>>> asadmin create-threadpool is the command line reflection of the
>>>>>>>>> <thread-pool> element. So, if <thread-pool> has changed,
>>>>>>>>> the command has to change, preferably compatibly.
>>>>>>>>>
>>>>>>>> If you want full support for the new thread-pool element, you
>>>>>>>> should add --classname too.
>>>>>>>>
>>>>>>> I was hoping to not go into that. I know nothing about the status of
>>>>>>> pluggable thread pool implementation which is what --classname
>>>>>>> configures.
>>>>>>>
>>>>>>> For now, this command does not expose --classname, till we know if
>>>>>>> that
>>>>>>> is exposed. All thread pools created by this command use the same
>>>>>>> Grizzly thread pool implementation named
>>>>>>> com.sun.grizzly.http.StatsThreadPool. I believe that's ok for v3.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> June
>>>>>>>>
>>>>>>>>> -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
>>>>>>>>
>>>>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> 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
>
>