On Mar 16, 2009, at 11:24 AM, Kedar Mhaswade wrote:
> Ken Cavanaugh,
>
> Can you please help with the answers with respect to ORB?
Ultimately my plan is to use whatever threadpool is a standard part of
GFv3. The ORB-provided threadpool should be replaced with a design
that considers the currently anticipated needs for GF resource
management.
The ORB needs for a threadpool are pretty simple: just create work
items for
a threadpool to be executed according to the threadpool policy.
The ORB does not depend on the policy, but it does have the capability
to control things like which threadpool instance should be used for a
particular request. That is done with information in the object
reference (the
EJB instance from GF's viewpoint). The ORB does not need more complex
facilities like cancellation of work items.
>
> What's the overall plan?
I don't know. Sahoo and others have proposed things in this area, but
I don't
recall seeing a spec or one-pager yet about this.
>
> We will use thread-pools from domain.xml, right?
Yes, that's where the configuration data should be.
>
> We need asadmin commands to create/delete/list thread pools right?
I believe so.
Ken.
>
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>