search

bennidi / mbassador

Powerful event-bus optimized for high throughput in multi-threaded applications. Features: Sync and Async event publication, weak/strong references, event filtering, annotation driven
MIT License
958 stars 146 forks source link

Possible MemoryLeak #103

Closed eagle1985 closed 9 years ago

eagle1985 commented 9 years ago

Hi, I am currently using MBassador in a web application. I like it very much and its default approach with WeakReferences. As it is a Server side application I check the memmory footprint from time to time with Java VisualVM (from the Oracle JDK) to see the Objects in the Memmory.

The process now is as following: User logges in opens a fiew views that register different Handler to user and a global eventbus. After the logout every view calls unsubscribe on the user and global eventbus and the user eventbus is also shutdown properly. The Dispatch Threads are stoped and GC removes all my own classes.

Problem now is, everytime a user logs in and out again I have more MessageHandler Objects left. Even if there is no user logged in. The VisualVM shows that I don't have any of my classes with the Handlers left, so the WeakReferencing works as it should. Therefore I am wondering on why I still have net.engio.mbassy.listener.MessageHandler and net.engio.mbassy.subscription.Subscription Objects from the EventBus around? I know that the global EventBus is still alive but I didn't find a way to remove unrequired MessageHandlers

This is an issue since I don't want to restart the Server to regualry and keep it a live for a while. Therefore I am a bit worried about the Handlers that keep on increasing every time. Even waiting for a bit and trigger the GC doesn't change a thing.

Pleas let me know if forgot a clean up I could run or trigger. Thanks

memory_sampler

bennidi commented 9 years ago

I see your point. The classes you mention carry meta information on the handlers and are used to configure dispatch. There will be one for each distinct listener class registered to the bus. They are not cleaned up when no listeners are left because new subscriptions might occur in the future and construction of those objects is a bit expensive (annotations scanning). I wouldn't classify this as a memory leak because there won't be more than some hundred of them and they are really small objects. I will check whether a cleanup method in the SubscriptionManager could be implemented easily. But I don't consider this to be of high priority. I think there is no need to worry in your setup.

eagle1985 commented 9 years ago

Thanks for the quick reply. If you look at this in this way it makes sense. And it also isn't that big of an issue either if they only grow up to the amount of handlers we specified with annotatioins. Then it's perfeclty fine.

bennidi commented 9 years ago

Great!