Hi Dixie,
from Grizzly side it looks fine.
Thanks.
WBR,
Alexey.
On Oct 17, 2009, at 2: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
>>
> <create-threadpool.1.pdf>