geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Thread Pool vs WorkManager
Date Tue, 16 Aug 2005 21:44:21 GMT

On Aug 16, 2005, at 12:26 PM, Aaron Mulder wrote:

> 	Do you think it's appropriate to have a Geronimo configuration
> that includes J2CA WorkManager thread pools and other thread pools?  If
> so, how do you present it to a user?  "Thread Pools: J2CA" and "Thread
> Pools: Other"?  This seems silly.
>
> 	Or are you saying that we should manage all our thread pools as
> "just thread pools" and make our J2CA WorkManager a wrapper around a 
> plain
> thread pool?  That way you'd still manage all the thread pools in one
> place ("Thread Pools") and then in the WorkManager configuration you'd
> point a work manager to an existing thread pool it should use.  I'm OK
> that way too -- I just don't like having two separate pools of thread
> pools for no particularly good reason.

I think having the j2ca work manager reference an external thread 
pool(s) would be fine.  I've thought about it but never implemented it.

thanks
david jencks
>
> Aaron
>
> On Tue, 16 Aug 2005, David Jencks wrote:
>
>> I'll repeat that IMO it is really inappropriate to use a J2CA work
>> manager where a thread pool/executor would suffice.
>>
>> IIRC we could base a j2ca work manager on the proposed non-j2ca work
>> manager, but they have really different purposes.
>>
>> david jencks
>>
>> On Aug 16, 2005, at 11:24 AM, Aaron Mulder wrote:
>>
>>> 	Hmm... I don't like that there are two different classes of thread
>>> pools in Geronimo.  I'd like to have one set to manage and modify.  
>>> If
>>> we
>>> feel strongly that OpenEJB should use a different interface, can we
>>> make
>>> it so a Gernoimo J2CA WorkManager automatically exposes an Executor
>>> interface too so that OpenEJB can use the same object, even if 
>>> exposed
>>> via
>>> a different interface?
>>>
>>> 	Then if the other JSR WorkManager thing gets off the ground, maybe
>>> later we can base the implementation on that and have it expose both
>>> J2CA
>>> WorkManager and Executor interfaces to other parts of the system.
>>>
>>> Aaron
>>>
>>> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
>>>> They have different purposes.  The WorkManager is a lot more
>>>> powerful, but most server environments either don't have one or 
>>>> don't
>>>> have a publicly available implementation.  I would prefer that if
>>>> service does not need a work manager, it does not use one.  This 
>>>> will
>>>> allow a service to run in more environments.
>>>>
>>>> As for how the default Geronimo server is configured, I would prefer
>>>> that we always use WorkManager.
>>>>
>>>> -dain
>>>>
>>>> On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
>>>>
>>>>>     I guess what I was saying was, let's pick one abstraction and 
>>>>> go
>>>>> with it.  It seems weird to have half the threads managed via 
>>>>> thread
>>>>> pools, and half managed by work managers.  If we agree that work
>>>>> managers
>>>>> are the way to get, we can use an adapter like you suggest to make
>>>>> OpenEJB
>>>>> work with a work manager, and then dispense with the thread pools
>>>>> in the
>>>>> server configuration.  Is that OK with everyone?
>>>>>
>>>>> Aaron
>>>>>
>>>>> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
>>>>>
>>>>>> I don't think it is a big deal to use a concurrent Executor, since
>>>>>> it
>>>>>> is a subset of WorkManager.  Executor has one method:
>>>>>>
>>>>>>      public void execute(java.lang.Runnable command)
>>>>>>
>>>>>> which maps easily to:
>>>>>>
>>>>>>      public void scheduleWork(Work work)
>>>>>>
>>>>>> Now, we just need WorkManagerExector and RunnableWork classes :)
>>>>>>
>>>>>> -dain
>>>>>>
>>>>>> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
>>>>>>
>>>>>>
>>>>>>> Aaron,
>>>>>>>
>>>>>>> Ok I'm not an expert on the internals of J2EE
>>>>>>> architecture, but I'm going to give my .02$ here
>>>>>>> regardless and you can beat me up if/when you
>>>>>>> disagree:
>>>>>>>
>>>>>>> I think the standardization should be on the work
>>>>>>> manager api since it's purpose is to provide "...a
>>>>>>> concurrent programming API for use within managed
>>>>>>> environments on the Java TM platform, such as Servlets
>>>>>>> and EJBs" (I'm quoting directly from the paper
>>>>>>> Commonj-TimerAndWorkManager-Specification-v1.1).
>>>>>>>
>>>>>>> Using the work manager api also seems to make for a
>>>>>>> more sound architecture since the responsibility of
>>>>>>> task execution would be left to the api and would
>>>>>>> remove the requirement to maintain this logic in more
>>>>>>> than one place.
>>>>>>>
>>>>>>> Finally, it would seem appropriate that a future
>>>>>>> enhancement to the OpenEJB impl could involve the
>>>>>>> removal of the thread pools, replacing it with
>>>>>>> delegation of task execution directly to the work
>>>>>>> manager api; this is speculation and off topic,
>>>>>>> however, and so I won't continue.
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


Mime
View raw message