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 <[EMAIL PROTECTED]> 內容： > 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:[EMAIL PROTECTED] > Sent: Sunday, December 05, 2004 4:09 AM > To: [email protected] > 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 > <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > Sent: Saturday, December 04, 2004 8:13 PM > > To: [email protected] > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
