Hi Archie,
Archie Cobbs wrote:
There was a post recently about long running Batik applications running out of memory. I've experienced this problem too. Here is my current theory about what's going on, at least in my case..
Our application animates an SVG document by adding and removing nodes, and also by modifying node attributes. A mouse listener is alwyas added to newly added nodes - and the same listener object is added every time.
But this listener is your listener not a "bridge context listener". I hope you aren't registering it with the BridgeContext are you?
I've checked that we are removing the nodes that we add, so that we're not just growing the document itself.
Are you certain that the nodes you remove are going to GC? I suspect they are not (this may be a Batik problem or it may be a problem in your app). Note that this can't be a Memento problem since it uses soft references.
The objects that accumulate in my heap are never-freed are instances of BridgeContext$EventListenerMemento. These instances remain in the BridgeContext instance field "eventListenerSet", causing this set to grow in size until memory is exhausted. In our application, this takes a couple of days to occur.
What type of objects are you adding/removing? Text/use/image?
One SoftReference points into the DOM and the other points to the Listener. Clearly, live DOM objects are always going to be referenced.
But if you remove nodes from the DOM and keep no references from your code the 'old' nodes should go to GC and the memento should go away.
As for the Listener, suppose the application uses the same Listener object over and over again. Then any EventListenerMemento objects that reference that Listener will never be cleared either.
Except it isn't your listeners that are in the memento it's Batik's listeners.
When I load a completely new document, the EventListenerMemento objects are all freed as expected because the old DOM is no longer referenced.
This is because the whole reason for the existence of the Memento is so Batik knows what listeners it needs to remove from the document when the document becomes 'unattached' (i.e. when BridgeContext.dispose() is called). Batik is careful to "cleanup after it's self" so the resultant document is not "polluted".
I'm not sure what the right way to fix this would be. In any case it seems like the Memento class has a design flaw. But also I don't understand why my workaround didn't fix the problem... i.e., perhaps there is some code that is calling BridgeContext.storeEventListener() that shouldn't be.
There may be a flaw but I don't think it's with the Memento class. Someone is most likely keeping the old DOM nodes alive.
There are only 24 instances in Batik where BridgeContext.storeEventListener() is invoked.. perhaps one or more of these is inappropriate?
Any help or insights greatly appreciated.
I've done my best ;)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
