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