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