hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Francois Poilpret" <jfpoilp...@hcm.vnn.vn>
Subject RE: Potential memory leak with Threaded model and Events listeners
Date Sat, 04 Dec 2004 01:10:11 GMT
To James:
- I am using the BuilderFactory to do it for me through hivemind.xml
configuration.

To Howard:
During the night (French people say that the "night gives good advice";-)),
I thought of a quite easy workaround, that can be done at the event
supplying service level: just use a weak reference to the listeners (instead
of a strong one), I think that should do the trick.
Maybe it would even be possible to write a general "WeakEventListeners"
class to manage all that for the event supplier:
- when addListener, is called generate a weak reference to the added
listener and store it in the list
- create a specific Iterator for WeakEventListeners that would skip the refs
that have become weak-reachable (and remove these from its list at the same
time).

Don't you think it would be a better solution than to make the current
proxies more complex?

I will try to give it a try this week (but only after writing a simple test
case that exhibits the leakage problem).

Regarding the solution you have in mind, there is something that puzzles me:
You say that the proxy would delegate the EventListener methods calls to the
__thread-local__ service implementation. I am not sure this is the way we
want it (or at least that I need it in my current application):
- when I register to an Event supplier service, I want __all__ my
implementations to be notified when an event occurs, independently of which
thread originates the event, and not only the one implementation that is in
the same thread as the event supplier.

Cheers

	Jean-Francois

-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com] 
Sent: Saturday, December 04, 2004 12:08 AM
To: hivemind-user@jakarta.apache.org
Subject: Re: Potential memory leak with Threaded model and Events listeners

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




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