Michele wrote:
Hi Marcel,
you are right, a cleanup is needed when shutting down the queue.
Ok, i have now commited the patch,
Balázs could you please verify?
thanks
Marcel
Marcel Ruff wrote:
Póka Balázs wrote:
Hi again!
Reflecting on my memory leak post yesterday, today I went though some
source code, beginning with QueuePluginManager. I noticed that the
only place where unprocessedEvents.remove is called is method
registerFinished() (that means that the map can only be emptied
there); that method is called from nowhere else than
EventPlugin.init(Global, PluginInfo). The most important piece of
information by far is that I didn't have any EventPlugin enabled!
So, I suppose this memory leak must have been occuring from the
beginning, but it only became a problem because on of our clients
reconnects every 10 minutes.
Am I right or wrong? :)
right.
The leak sneaked in on 2007-06-19.
Michele, it seems the offending code is
QueuePluginManager.java:
public I_Queue getPlugin(PluginInfo pluginInfo, StorageId storageId,
QueuePropertyBase props) throws XmlBlasterException {
...
if (!props.isEmbedded()) {
EventHelper helper =
this.storageEventHandler.generateEventHelper(storageId);
this.storageEventHandler.registerListener(plugin, helper);
}
return plugin;
}
any idea why decided to always register the listener?
I think we need an own listener on each instance of the queue since the
configuration could allow different configurations for different (for
example) callback queues (on a per-client basis).
Regards
Michele
We could add to StorageEventHandler:
public void removeListener(I_Storage storage) throws
XmlBlasterException {
if (this.processedEvents != null) {
synchronized(this.processedEvents) {
this.processedEvents.remove(storage);
}
}
}
and somehow call it from I_Storage.shutdown() ...
Balázs, for the time being you could activate the EventPlugin (for some
dummy events)
to clean up the leak.
thanks
Marcel
regards,
Balázs Póka
--
Marcel Ruff
http://www.xmlBlaster.org
