You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Jean-Francois Poilpret <jf...@hcm.vnn.vn> on 2004/10/24 05:08:11 UTC

Pooled Service Model enhancements

Hi all,

Currently, as far as I understand, HiveMind's Pooled ServiceModel does not
offer all benefits of a "real" pool in the sense that its size is unlimited
and unconfigurable (for the "initial size"), in addition it never shrinks
after a heavy-load, so even after load has gone back to normal, unnecessary
resources (pooled services) are still in memory.
I was wondering if there are some possibilities to enhance this ServiceModel
(or create a new one) that could implement those features as parameters
settings (for each service):
	- initial size
	- maximum size
	- wait or fail if exhausted resources (with timeout?)
	-...others?
Plus the definition of default values (to avoid configuration for all pooled
services).
I also wonder if this could be achieved easily (from the HiveMind internal
changes development viewpoint).
One idea that I had about configuration was to use the kind of parameter
settings as for the "translator", ie model="pooled,min=10,max=20...", this
way, there would be no changes in HiveMind schemas definitions.

I would have liked to dig into HiveMind "guts", but to be honest, I find it
hard to understand how the ServiceModels interact with the
ServiceImplementationFactories. Maybe some documentation (like activity
diagrams) would be useful for all of us who would like to take part into
HiveMind improvements?

Do other people in this list think such a kind of pooled model would be
worth?

Cheers




---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org

Re: Pooled Service Model enhancements

Posted by Howard Lewis Ship <hl...@gmail.com>.
Although the default pooled service model is limited, it is likely
sufficient for most needs.

By writing your own service model, you can implemented an improved
version of the pooled service and make use of a more full-featured
solution such as commons pool.


On Mon, 25 Oct 2004 23:01:54 +0700, Jean-Francois Poilpret
<jf...@hcm.vnn.vn> wrote:
>  
>  
> 
> I much agree with James. 
> 
>   
> 
> Having a pooled service model that brings some enhancements to the current
> one is one point. 
> 
> Having a service that provides asynchroneous execution of services (possibly
> with a scheduler) is another point. 
> 
>   
> 
> For me a service model should not be limited to work only with services that
> have only void methods (and also non throwing exceptions, by the way: this
> reminds me of the "oneway" keyword in CORBA, as far as I remember at the end
> nobody would use that keyword because it prevents any assurance of a method
> -correct- execution). 
> 
> My original request was really in this sense: extending the current pooled
> service model in a way to, primarily, avoid resource waste (after a period
> of heavy load for instance). 
> 
>   
> 
> I don't know how the pooled model is currently implemented in HiveMind, I am
> not sure that having it changed to use commons pool would be easy, nor
> advisable (it seems one of Howard's goals is to keep dependencies to the
> minimum). I will try to have a quick look at it when I have time (at least
> to understand how service models are developed). 
> 
>   
> 
> One additional comment about the use of concurrent packages (for an
> asynchroneous scheduler for instance): if it was to be a part of HiveMind
> core, then this would introduce still another dependency (since HiveMind is
> claimed to work on JDK1.3, and I see no reason why this should change until
> some time: I do not think we can expect everybody to switch to JDK5 until
> years, personally I did not try it yet!) 
> 
>   
> 
> Cheers 
> 
>   
>  
>  ________________________________
>  
> 
> From: James Carman [mailto:james@carmanconsulting.com] 
>  Sent: Monday, October 25, 2004 9:42 PM
>  To: hivemind-dev@jakarta.apache.org
>  Subject: RE: Pooled Service Model enhancements 
> 
>   
> 
> Well, I don't really like it and I don't think it should be part of core
> HiveMind, but you can feel free to implement it yourself.  I don't like it
> because you really have to be careful what you're doing when you start using
> asynchronous calls like this seamlessly.  Clients have no idea that the call
> goes on asynchronously!  I see the merits of what you're proposing, but I
> think making it very explicit (using a service point and implementing
> Runnable or providing some reflective mechanism) is a bit safer.  It's one
> thing to manage what specific INSTANCE of an implementation object is used
> behind the scenes to carry out the logic of a method call (the job of a
> service model), but it's a completely different thing to seamlessly switch
> the method call to asynchronous behind the scenes.  Not only that, but you
> have to make sure your methods are ALL void methods in your service
> interface.  Also, what do you do with exceptions that are thrown during
> execution of the service method?  What about transactions? 
> 
>   
> 
> -----Original Message-----
>  From: Pablo Lalloni [mailto:plalloni@afip.gov.ar] 
>  Sent: Monday, October 25, 2004 10:12 AM
>  To: hivemind-dev
>  Subject: RE: Pooled Service Model enhancements 
> 
>   
> 
> El lun, 25-10-2004 a las 10:37, James Carman escribió: 
> 
> What if the service interface's method returns something?  How can it be
> asynchronous? 
> 
> 
>  Of course, asynchronous calls doesn't expect to return a value... that's
> the whole point.
>  
>  
> 
>   I agree that the Executor interface could be used as a service itself, but
> to use that idea as a service model doesn't work IMHO.  My suggestion would
> be to expose the Executor (or actually ExecutorService in JDK 5.0) interface
> as a service in your registry (as you've already done it seems) and let
> other services use it.  A service model itself cannot be asynchronous, as it
> is a mechanism for performing a method call (which is inherently
> synchronous) on an object.  Even when you call the Executor.execute()
> method, it's a synchronous call.  The method does what it's supposed to do
> (adds the Runnable to a queue or something) and returns.  
> 
> 
>  I partially agree with you, but I think that wrapping the asynch/pool/queue
> behaviour in the service-model would make things a lot cleaner and
> shorter... no need the extra SPs, no need to implement runnable, etc... Of
> course the methods called with this model/s should not return any value but
> void. 
>  
> 
> -- Pablo I. Lalloni Teléfono +54 (11) 4347-3177 Proyecto PampaDirección
> Informática TributariaAFIP   


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org

RE: Pooled Service Model enhancements

Posted by Jean-Francois Poilpret <jf...@hcm.vnn.vn>.
I much agree with James.

 

Having a pooled service model that brings some enhancements to the current
one is one point.

Having a service that provides asynchroneous execution of services (possibly
with a scheduler) is another point.

 

For me a service model should not be limited to work only with services that
have only void methods (and also non throwing exceptions, by the way: this
reminds me of the “oneway” keyword in CORBA, as far as I remember at the end
nobody would use that keyword because it prevents any assurance of a method
-correct- execution).

My original request was really in this sense: extending the current pooled
service model in a way to, primarily, avoid resource waste (after a period
of heavy load for instance).

 

I don’t know how the pooled model is currently implemented in HiveMind, I am
not sure that having it changed to use commons pool would be easy, nor
advisable (it seems one of Howard’s goals is to keep dependencies to the
minimum). I will try to have a quick look at it when I have time (at least
to understand how service models are developed).

 

One additional comment about the use of concurrent packages (for an
asynchroneous scheduler for instance): if it was to be a part of HiveMind
core, then this would introduce still another dependency (since HiveMind is
claimed to work on JDK1.3, and I see no reason why this should change until
some time: I do not think we can expect everybody to switch to JDK5 until
years, personally I did not try it yet!)

 

Cheers

 

  _____  

From: James Carman [mailto:james@carmanconsulting.com] 
Sent: Monday, October 25, 2004 9:42 PM
To: hivemind-dev@jakarta.apache.org
Subject: RE: Pooled Service Model enhancements

 

Well, I don’t really like it and I don’t think it should be part of core
HiveMind, but you can feel free to implement it yourself.  I don’t like it
because you really have to be careful what you’re doing when you start using
asynchronous calls like this seamlessly.  Clients have no idea that the call
goes on asynchronously!  I see the merits of what you’re proposing, but I
think making it very explicit (using a service point and implementing
Runnable or providing some reflective mechanism) is a bit safer.  It’s one
thing to manage what specific INSTANCE of an implementation object is used
behind the scenes to carry out the logic of a method call (the job of a
service model), but it’s a completely different thing to seamlessly switch
the method call to asynchronous behind the scenes.  Not only that, but you
have to make sure your methods are ALL void methods in your service
interface.  Also, what do you do with exceptions that are thrown during
execution of the service method?  What about transactions? 

 

-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar] 
Sent: Monday, October 25, 2004 10:12 AM
To: hivemind-dev
Subject: RE: Pooled Service Model enhancements

 

El lun, 25-10-2004 a las 10:37, James Carman escribió: 

What if the service interface’s method returns something?  How can it be
asynchronous? 


Of course, asynchronous calls doesn't expect to return a value... that's the
whole point.



  I agree that the Executor interface could be used as a service itself, but
to use that idea as a service model doesn’t work IMHO.  My suggestion would
be to expose the Executor (or actually ExecutorService in JDK 5.0) interface
as a service in your registry (as you’ve already done it seems) and let
other services use it.  A service model itself cannot be asynchronous, as it
is a mechanism for performing a method call (which is inherently
synchronous) on an object.  Even when you call the Executor.execute()
method, it’s a synchronous call.  The method does what it’s supposed to do
(adds the Runnable to a queue or something) and returns.  


I partially agree with you, but I think that wrapping the asynch/pool/queue
behaviour in the service-model would make things a lot cleaner and
shorter... no need the extra SPs, no need to implement runnable, etc... Of
course the methods called with this model/s should not return any value but
void.


-- 

Pablo I. Lalloni 
Teléfono +54 (11) 4347-3177 
Proyecto Pampa
Dirección Informática Tributaria
AFIP

RE: Pooled Service Model enhancements

Posted by James Carman <ja...@carmanconsulting.com>.
Well, I don’t really like it and I don’t think it should be part of core
HiveMind, but you can feel free to implement it yourself.  I don’t like it
because you really have to be careful what you’re doing when you start using
asynchronous calls like this seamlessly.  Clients have no idea that the call
goes on asynchronously!  I see the merits of what you’re proposing, but I
think making it very explicit (using a service point and implementing
Runnable or providing some reflective mechanism) is a bit safer.  It’s one
thing to manage what specific INSTANCE of an implementation object is used
behind the scenes to carry out the logic of a method call (the job of a
service model), but it’s a completely different thing to seamlessly switch
the method call to asynchronous behind the scenes.  Not only that, but you
have to make sure your methods are ALL void methods in your service
interface.  Also, what do you do with exceptions that are thrown during
execution of the service method?  What about transactions? 

 

-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar] 
Sent: Monday, October 25, 2004 10:12 AM
To: hivemind-dev
Subject: RE: Pooled Service Model enhancements

 

El lun, 25-10-2004 a las 10:37, James Carman escribió: 

What if the service interface’s method returns something?  How can it be
asynchronous? 


Of course, asynchronous calls doesn't expect to return a value... that's the
whole point.




  I agree that the Executor interface could be used as a service itself, but
to use that idea as a service model doesn’t work IMHO.  My suggestion would
be to expose the Executor (or actually ExecutorService in JDK 5.0) interface
as a service in your registry (as you’ve already done it seems) and let
other services use it.  A service model itself cannot be asynchronous, as it
is a mechanism for performing a method call (which is inherently
synchronous) on an object.  Even when you call the Executor.execute()
method, it’s a synchronous call.  The method does what it’s supposed to do
(adds the Runnable to a queue or something) and returns.  


I partially agree with you, but I think that wrapping the asynch/pool/queue
behaviour in the service-model would make things a lot cleaner and
shorter... no need the extra SPs, no need to implement runnable, etc... Of
course the methods called with this model/s should not return any value but
void.




-- 

Pablo I. Lalloni 
Teléfono +54 (11) 4347-3177 
Proyecto Pampa
Dirección Informática Tributaria
AFIP

RE: Pooled Service Model enhancements

Posted by Pablo Lalloni <pl...@afip.gov.ar>.
El lun, 25-10-2004 a las 10:37, James Carman escribió:

> What if the service interface’s method returns something?  How can it
> be asynchronous?


Of course, asynchronous calls doesn't expect to return a value... that's
the whole point.


>   I agree that the Executor interface could be used as a service
> itself, but to use that idea as a service model doesn’t work IMHO.  My
> suggestion would be to expose the Executor (or actually
> ExecutorService in JDK 5.0) interface as a service in your registry
> (as you’ve already done it seems) and let other services use it.  A
> service model itself cannot be asynchronous, as it is a mechanism for
> performing a method call (which is inherently synchronous) on an
> object.  Even when you call the Executor.execute() method, it’s a
> synchronous call.  The method does what it’s supposed to do (adds the
> Runnable to a queue or something) and returns.  


I partially agree with you, but I think that wrapping the
asynch/pool/queue behaviour in the service-model would make things a lot
cleaner and shorter... no need the extra SPs, no need to implement
runnable, etc... Of course the methods called with this model/s should
not return any value but void.



-- 

Pablo I. Lalloni 
Teléfono +54 (11) 4347-3177 
Proyecto Pampa
Dirección Informática Tributaria
AFIP

RE: Pooled Service Model enhancements

Posted by James Carman <ja...@carmanconsulting.com>.
What if the service interface’s method returns something?  How can it be
asynchronous?  I agree that the Executor interface could be used as a
service itself, but to use that idea as a service model doesn’t work IMHO.
My suggestion would be to expose the Executor (or actually ExecutorService
in JDK 5.0) interface as a service in your registry (as you’ve already done
it seems) and let other services use it.  A service model itself cannot be
asynchronous, as it is a mechanism for performing a method call (which is
inherently synchronous) on an object.  Even when you call the
Executor.execute() method, it’s a synchronous call.  The method does what
it’s supposed to do (adds the Runnable to a queue or something) and returns.


 

-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar] 
Sent: Monday, October 25, 2004 9:23 AM
To: hivemind-dev
Cc: 'Marcus Brito'
Subject: RE: Pooled Service Model enhancements

 

El lun, 25-10-2004 a las 09:25, James Carman escribió: 

The service models need to be synchronous, 

Not necessarily... we've made extensive use of ThreadPoolExecutor (as a
service) for firing events that need to be processed asynchronously with
great success so far. Of course, event-listeners are other services.
We used the Executor interface from concurrent as a service interface and
defined a set of executors which can be plugged in services that represent
events to be fired, then when some other service fires an event, it's
event-service use the executor provided to notify the registered listeners.
We also provide the executors with a ThreadFactory (another SP) which
surround the run() method with appropriate calls to fireThreadCleanup(),
hence it all works great!
We have asynchronous processing, and with a lot of tuning possible through
PooledExecutor, ThreadedExecutor and QueuedExecutor (from oswego.concurrent)
params.

In fact, we're looking forward to implement schedulers to use as a HiveMind
service probably wrapping functionality from concurrent as well.

Regards.


-- 

Pablo I. Lalloni 
Teléfono +54 (11) 4347-3177 
Proyecto Pampa
Dirección Informática Tributaria
AFIP

RE: Pooled Service Model enhancements

Posted by Pablo Lalloni <pl...@afip.gov.ar>.
El lun, 25-10-2004 a las 09:25, James Carman escribió:

> The service models need to be synchronous, 

Not necessarily... we've made extensive use of ThreadPoolExecutor (as a
service) for firing events that need to be processed asynchronously with
great success so far. Of course, event-listeners are other services.
We used the Executor interface from concurrent as a service interface
and defined a set of executors which can be plugged in services that
represent events to be fired, then when some other service fires an
event, it's event-service use the executor provided to notify the
registered listeners.
We also provide the executors with a ThreadFactory (another SP) which
surround the run() method with appropriate calls to fireThreadCleanup(),
hence it all works great!
We have asynchronous processing, and with a lot of tuning possible
through PooledExecutor, ThreadedExecutor and QueuedExecutor (from
oswego.concurrent) params.

In fact, we're looking forward to implement schedulers to use as a
HiveMind service probably wrapping functionality from concurrent as
well.

Regards.


-- 

Pablo I. Lalloni 
Teléfono +54 (11) 4347-3177 
Proyecto Pampa
Dirección Informática Tributaria
AFIP

RE: Pooled Service Model enhancements

Posted by James Carman <ja...@carmanconsulting.com>.
However, with the "executors", they (aside from DirectExecutor or whatever
it's called) do not run the operation (the Runnable object) within the
calling thread.  In essence, they're typically asynchronous.  The service
models need to be synchronous, unless you want to block the calling thread
and wait until the executor finishes executing the runnable task, but then
why would you use an executor in the first place?  Anyway, if you were just
using the ThreadPoolExecutor as an example of the kinds of
parameters/settings we should have available on the threaded service model,
I agree, but I don't think that using the ThreadPoolExecutor is the answer.


-----Original Message-----
From: Marcus Brito [mailto:mbrito@gmail.com] 
Sent: Monday, October 25, 2004 7:11 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: Pooled Service Model enhancements

> Do other people in this list think such a kind of pooled model would be
> worth?

Right now none of my services are using the pooled model, but I can
see how/when it could be used. There's another project (which is not
using hivemind) that would benefit greatly from this model.

>>From my point of view, the "concurrent executors" kind of services
would benefit the best from this model -- and if we're serious about
this there's more than just a minimum and a maximum number of
instances. We need to configure timeouts, queues, etc. In other words,
we just need a service model that works like a
java.util.concurrent.ThreadPoolExecutor :)

-- Marcus Brito <mb...@gmail.com>

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org

Re: Pooled Service Model enhancements

Posted by Marcus Brito <mb...@gmail.com>.
> Do other people in this list think such a kind of pooled model would be
> worth?

Right now none of my services are using the pooled model, but I can
see how/when it could be used. There's another project (which is not
using hivemind) that would benefit greatly from this model.

>From my point of view, the "concurrent executors" kind of services
would benefit the best from this model -- and if we're serious about
this there's more than just a minimum and a maximum number of
instances. We need to configure timeouts, queues, etc. In other words,
we just need a service model that works like a
java.util.concurrent.ThreadPoolExecutor :)

-- Marcus Brito <mb...@gmail.com>

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org

Re: Pooled Service Model enhancements

Posted by Bob Arnott <bo...@aungate.com>.
Jean-Francois Poilpret wrote:
> Hi all,
> 
> Currently, as far as I understand, HiveMind's Pooled ServiceModel does not
> offer all benefits of a "real" pool in the sense that its size is unlimited
> and unconfigurable (for the "initial size"), in addition it never shrinks
> after a heavy-load, so even after load has gone back to normal, unnecessary
> resources (pooled services) are still in memory.

Could you not back it with the Commons Pool stuff...?

-- 
Bob Arnott


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org