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