Mailing-List: contact hivemind-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hivemind-user@jakarta.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
From: "Jean-Francois Poilpret" <jfpoilpret@hcm.vnn.vn>
To: <hivemind-user@jakarta.apache.org>
Subject: Potential memory leak with Threaded model and Events listeners
Date: Fri, 3 Dec 2004 23:42:33 +0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcTZVxZLJQOgDoWxSsygxMDNC2EVWw==
Message-Id: <20041203164226.KDPU79854.HCM-MS-185@nbjeff>

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