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
>