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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
