Hi Dixie,
Here's the max-queue-size attribute description from the DFFR, which can
help you doc --maxqueuesize:
Name: max-queue-size
Default: 4096
Description: (optional) 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.
June
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
>