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