I notice that the thread pool used by the ORB (thread-pool-1) now has a
max queue size value of 4096, not -1. So is it still the case that -1 is
the recommended value for an ORB thread pool? Or should we stop saying that?
The only difference between the two default thread pools now is their
max thread pool size. According to
https://glassfish.dev.java.net/issues/show_bug.cgi?id=8960 the ORB
thread pool cannot use the default value of 5 for this.
Thanks,
Kim
On 10/16/09 20:04, Dixie Pine wrote:
> 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