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
>>
>