hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert Kwong <mandr...@yahoo.com>
Subject RE: Potential memory leak with Threaded model and Events listeners
Date Sun, 05 Dec 2004 08:58:06 GMT
We already have an <event-listener/> declaration for
BuilderFactory, so, how about insert a
Discardable/PoolManageable aspect between the proxy
and the underlying service?  This service would call
the event publisher's remove* method whenever they are
discarded.  

The aspect need not be another level of proxy.  It can
be a dynamic extension of the service implementation
class.

Albert

 --- Jean-Francois Poilpret <jfpoilpret@hcm.vnn.vn>
內容:
> No, I don't want each __created__ instance to
> receive notifications, I just
> want each __active__ instance to receive them, and
> any __inactive___
> instance not to receive them.
> Currently with either threaded or pooled model (as
> far as I can see), all
> created instances actually receive notifications,
> even when inactive. Worse,
> for threaded model, inactive instances never get
> garbage-collected because
> they are strongly referenced by the service which
> fire events.
> 
> For me, the expected behavior of HiveMind would be:
> - when a service instance gets created (threaded) or
> activated (pooled),
> then it should be added as a listener to the service
> firing events
> - when a service instance gets discarded (threaded)
> or deactivated (pooled),
> then it should be removed as a listener from the
> service supplying events.
> 
> NB: this description applies to the case where the
> event-firing service is a
> singleton (my situation right now), but the behavior
> would/should probably
> be different if that service used a different model.
> 
> Currently, the best work-around is:
> - for threaded model, the listening service must
> implement Discardable and
> remove itself from the listeners list of the event
> firing service, when its
> threadDidDiscardService() method is called. The
> registration as a listener
> can either be done by configuration (BuilderFactory)
> or in the constructor.
> 
> - for pooled model, the listening service must
> implement PoolManageable and
> it must register itself as a listener in its XXXX
> methods, and unregister
> itself when its XXXX() method is called. Here
> automatic Event registration
> through BuilderFactory is useless.
> 
> These work-arounds work well, but they are not very
> "clean" in the sense
> that this is code the end-developer has to write
> that HiveMind could
> directly handle for him.
> In addition, in the threaded situation, if we use
> the BuilderFactory to wire
> the listener to the event supplier, then the
> work-around introduces some
> asymmetry (registration in config, unregistration in
> the code), making the
> use of BuilderFactory for this aspect useless.
> 
> I think before changing anything in HiveMind, we
> (all concerned developers)
> should discuss the various situations (models for
> supplier/consumer:
> singleton/threaded, singleton/pooled,
> threaded/singleton,
> threaded/threaded...) and specify for each what the
> behavior should be, then
> the actual coding can start. Should we start a new
> page on the WIKI?
> 
> Cheers
> 
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com] 
> Sent: Sunday, December 05, 2004 4:09 AM
> To: hivemind-user@jakarta.apache.org
> Subject: Re: Potential memory leak with Threaded
> model and Events listeners
> 
> If you want each created instance to receive the
> notification, use the
> pooled, not threaded, service model.  Pooled
> instances exist
> indefinately once created.  The only down side is
> that code related to
> the event needs to be thread safe, and that
> deactivated instances in
> the pool will also receive notifications.
> 
> 
> On Sun, 5 Dec 2004 00:18:27 +0700, Jean-Francois
> Poilpret
> <jfpoilpret@hcm.vnn.vn> wrote:
> > Hi Luke,
> > 
> > Thank you for your remark.
> > Although your remark is correct in many cases of
> Listeners, I think it
> would
> > generally not apply in HiveMind context, I mean
> (if people follow the
> "right
> > path") that normally, only a service will
> implement a Listener interface,
> > thus at least HiveMind itself (through one of the
> generated proxies) will
> > hold a strong reference to that service/listener.
> But of course, if
> someone
> > decides to create a Listener on-the-fly and add it
> "by hand" to the event
> > supplier service, then the problem you described
> would occur.
> > 
> > Anyway, I just did some tests (with strong and
> with weak references) and
> in
> > fact, the result is not "as good" as I expected
> initially. Indeed, when
> > suggesting that idea, I simply forgot that the
> handling of weak references
> > is totally non-deterministic, ie the weak ref
> could still be valid even
> > though there is no more existing strong ref. The
> time at which the weak
> ref
> > would be cleaned is totally up to the GC...
> > So as my test have shown me, using weak refs
> improve the issue, but they
> do
> > not solve it really:-(
> > 
> > In my tests, I did something like that:
> > - create EventSupplier service (singleton)
> > - create EventConsumer service (threaded)
> > - instantiate EventConsumer in 1000 "threads"
> (they are real threads but
> > they do not run concurrently, but I force
> consecutive runs, with a call to
> > Registry.cleanupThread() at the end of each
> thread)
> > - each thread call the EventSupplier to generate a
> new event
> > - all calls are traced
> > - each EventConsumer instance allocates 10KB on
> the heap and never release
> > them.
> > 
> > With strong refs:
> > - the 1000th thread sends an event that is
> received by 1000 EventConsumer
> > instances
> > 
> > With weak refs:
> > - the 1000th thread sends an event that is
> received by about 30
> > EventConsumer instances.
> > 
> > Of course that is much better, but the ideal, here
> in my testcase, would
> be
> > always just one EventConsumer instance receiving
> the event.
> > 
> > So finally, maybe I will stick with the previous
> -not very clean from
> design
> > viewpoint- workaround:
> > - have EventConsumer implement Discardable and
> remove itself from the
> > EventSupplier list of listeners, when
> threadDidDiscardService() is called.
> > 
> > And then I will eagerly wait for HM1.1 release
> (hope it will fix this
> > issue).
> > 
> > Cheers
> > 
> > 
> > 
> > -----Original Message-----
> > From: Luke Blanshard [mailto:luke@blanshard.us]
> > Sent: Saturday, December 04, 2004 8:13 PM
> > To: hivemind-user@jakarta.apache.org
> > Subject: Re: Potential memory leak with Threaded
> model and Events
> listeners
> > 
> > Jean-Francois,
> > 
> > The problem with holding listeners weakly is that
> people commonly create
> > listener objects on the fly and then retain no
> other references to them
> > once they've added them.  So these listeners are
> thrown away on the next
> > GC cycle, and they stop working.
> > 
> 
=== message truncated === 

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


Mime
View raw message