Hi Dixie,
Keep "A value of -1 specifies no limit." Delete "which is the optimal
value for a thread pool used with an IIOP listener."
June
On 10/20/09 11:45, Dixie Pine wrote:
> On 10/20/09 08:56, June.Parks_at_Sun.COM wrote:
>> On 10/19/09 08:51, Kim Haase wrote:
>>> 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?
>> Thanks for pointing this out. I'll delete the "-1 is recommended"
>> sentence from the DFFR. Dixie, this also needs to be deleted from
>> the create-threadpool man page.
> Here's what the man page says:
>
> maxqueuesize
> Specifies the maximum number of messages that can be queued until
> threads
> are available to process them for a network listener or IIOP
> listener. *A value*
> *of -1 specifies no limit, which is the optimal value for a thread
> pool used*
> *with an IIOP listener.* Default is 4096.
>
> Is the highlighted sentence still correct (even though not "recommended")?
> Dixie
>
>>
>> June
>>>
>>> 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
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>