hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Potential memory leak with Threaded model and Events listeners
Date Fri, 03 Dec 2004 17:08:08 GMT
This is something I am aware of.   I have a solution in mind, but
haven't had time to implement it.

Basically, for the threaded and pooled service models, a new type of
proxy must be created, one that implements the necessary listener
interfaces and delegates to the (thread-local) service implementation.

This will require a bit of refactoring, a tighter collaboration
between BuilderFactory and ServiceModel.

As a workaround: have the event source injected into the listener
service implementation, and have the listener service impl manage
itself: registrer for events inside activateService() or
initializeService(), unregister inside passivateService() or
threadDidDiscardService().


On Fri, 3 Dec 2004 23:42:33 +0700, Jean-Francois Poilpret
<jfpoilpret@hcm.vnn.vn> wrote:
> Hello,
> 
> I was wondering about one potential problem (I did not test it but I believe
> it happens and I wonder about whether it could be fixed in HiveMind should
> be worked around in applications):
> 
> - let's suppose I have a service A that supplies events
> - let's suppose I have a service B that listens to those events, and that
> uses the threaded model
> - when a new thread is executed and first time service B is used by this
> thread, a new instance of B is created for the thread, and it is added as a
> listener to events produced by service A: hence A retains a reference to the
> actual implementation of B for the thread
> - when the thread is cleaned up, then that service B instance ceases to
> exist (it has been "discarded") and nothing refers to it anymore...
> - ...nothing except service A that still holds a reference to that instance
> (in its list of listeners)
> 
> This means that in this situation if I have a huge amount of threads during
> my application's lifecycle, then a huge amount of service B instances will
> be created and never garbage collected.
> In addition, whenever service A produces an event, it will dispatch it to
> this huge amount of "zombie" instances, reducing performance a lot.
> 
> Is my reasoning correct? If necessary, I can try to write a simple test case
> to produce this problem.
> If this is correct, what should be the correct way to fix the problem?
> - in HiveMind? Actually, I do not see really where (the problem in HM1.0 is
> that the link of the Event listener to the producer is done by the Factory,
> but only the ServiceModel manages the full lifecycle of the service
> instance, and it knows nothing about what the factory did).
> I remember some time ago, Howard discussed the idea to change the
> responsibilities of ServiceModels and Factories to make it clearer. Will
> this be done in HM1.1? Will this possibly solve that problem?
> - in the application itself? Yes it is possible to implement the Discardable
> interface in the service B, and when the service is discarded then we can
> possibly call serviceA.removeEventListener(this). However, this means that
> the link that was configured dynamically through the module configuration
> has to be undone by some kind of hard-code, reducing the interest of using
> the BuilderFactory to link the event listener to the event supplier.
> 
> Has somebody already met such kind of problem and could come out with some
> satisfactory solution?
> 
> Some more info about why I ask: actually I am working on the "user" service
> model that I described a few days ago (ie, one different instance for each
> connected user, discarded when user logs out), it works correctly until now,
> but in one "real-life" application that I am currently working on and that
> needs to use it, I am faced with this kind of problem, so I wonder how I can
> circumvent this.
> 
> Thank you for any feedback
> 
> Cheers
> 
>         Jean-Francois
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> 
> 


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

---------------------------------------------------------------------
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