Ken Cavanaugh,
Can you please help with the answers with respect to ORB?
What's the overall plan?
We will use thread-pools from domain.xml, right?
We need asadmin commands to create/delete/list thread pools right?
Thanks,
Kedar
Kedar Mhaswade wrote:
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>