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