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