Re: JDOM parser reuse memory problem

Michael Kay <[email protected]>
Newsgroups gmane.comp.java.jdom.general
Message-ID <[email protected]>
On 10/11/2011 17:24, Randall Theobald wrote:
> Hi, I'm a performance analyst and found a spot where a product I'm
> analyzing is using JDOM. We are creating new SAXBuilders on each thread and
> are ending up with a hot lock on the classloader when trying to load up the
> XMLReader. I saw that the underlying parser in SAXBuilder can be reused,
> thus leading to a proper pooling strategy, but I have a memory concern. In
> the case where the parser is reused, nothing is cleared from it at the end
> of the build method (so the content handler is still held, which can
> reference lots of objects). Since SAXBuilder doesn't expose a way to clear
> anything on the reused parser, the only option is using ugly reflection to
> clear it, or to use (slightly less ugly) WeakReferences to the SAXBuilders
> in my pool so that they evenutally get cleaned up.
>
> Is there a reason that the content handler on 'this.parser' isn't set to
> null along with the local content handler being set to null in the finally
> block of the build method? If not, I'd suggest this change.
>
>
I have the same problem in Saxon. When returning a parser to the pool I 
set all the callbacks to null (ContentHandler, lexicalHandler, etc). 
Unfortunately some XMLReader implementations don't allow the callback to 
be set to null (the specs aren't explicit on the point). One approach is 
to catch the exception, another is to set a dummy ContentHandler or 
whatever that doesn't have any references to anything. Messy.

Michael Kay
Saxonica
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.