Thanks everyone for answers. Questions below:
Ken Cavanaugh wrote:
> Kenneth Saks wrote:
>>
>> On Mar 11, 2009, at 8:45 PM, Kedar Mhaswade wrote:
>>
>>>
>>>
>>> Kenneth Saks wrote:
>>>>
>>>> sun-ejb-jar.xml
>>>> called use-thread-pool-id. The value is set by the ejb container on
>>>> the underlying
>>>> remote object associated with the bean. The value is used by the
>>>> orb since it's their
>>>> code that's choosing threads to handle the remote invocations.
>>>
>>> This is a little weird in that we refer to something in domain.xml from
>>> within sun-ejb-jar.xml, by name.
>>
>> That's a good part of what our sun-*.xmls do. How is this any
>> different from mapping a
>> logical application resource like a resource-ref to the physical name
>> of a jdbc-resource?
>>
>>
>>>
>>>
>>>> I don't know whether there's some other orb-related thread-pool usage.
>>>
>>>
>>>>> and connectors?
>>>> Don't know. Isn't there an admin API for retrieving the thread
>>>> pools that are defined
>>>> in domain.xml? Maybe just search for usages.
>>>
>>> That would only tell me how runtime accesses the data in domain.xml.
>>> My question was regarding creating/deleting/listing the thread pools
>>> created.
>>>
>>> Also, since the server is now being more modular, we need to have
>>> someone
>>> who owns the configuration of these thread-pools.
>>>
> This all falls under the general category of resource management, and
> Sahoo and others
> have long been planning to clean up some of this. Grizzly, Corba,
> Connectors, and probably
> other parts of the app server use threads, and ultimately all of the
> thread usage should be
> managed, either by shared thread pools, or by assigning thread pools to
> the different consumers
> of threads in GFv3. Sahoo in particular is interested in request
> prioritization, which in large
> part is an issue for thread pool management.
>
> Grizzly (Jean-Francois in particular) has done a lot of work on thread
> pools, looking at a very simple
> threadpool in Grizzly, the ORB threadpool, and the full ExecutorService
> found in recent JDKs.
> We want to unify all of the different threadpools under a single
> interface (probably ExecutorService),
> with possibly different implementations, and certainly with the
> capability to flexibly assign threadpool instances
> to different services in GFv3.
>
> Unfortunately this work does not seem to have an owner, as far as I
> know. If there is an owner,
> the threadpool work probably is just not high priority enough right now.
Hmmm. So does it mean that implementing create-threadpool and delete-threadpool
is not a high priority asadmin command? Can we skip implementing it for v3?
Also, can a thread-pool be shared as of now? (I think not).
Ken C -- what's the plan for ORB -- is it going to use "thread-pool-1" as it
used to be (I guess) in v2?
-Kedar
>
> Ken.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>