Brian Faull <[EMAIL PROTECTED]> writes:
> I am stress-testing my first Xerces application
good, I haven't stress tested it in a looooong time.
> and seem to be running into a HUGE memory leak.
not so good.
> Not sure if it's on my end, or in Xerces-p or in Xerces-C... need to
> do a bit more investigation before I draw conclusions. I'm streaming
> (as fast as possible) 500-byte (or so) XML strings... within 10
> minutes, X has locked up and the hard drive is thrashing... so this
> is pretty serious. :) Have you run into anything like this? Or, do
> you know if there's any Xerces call I need to make to be sure that
> objects are freed? I don't see any related posts...
Depends on what you are doing - if it is DOM related, then yes, you
must tell the parser to release the memory, otherwise it grows. From
the API docs:
void AbstractDOMParser::resetDocumentPool()
Reset the documents vector pool and release all the associated memory
back to the system.
When parsing a document using a DOM parser, all memory allocated for a
DOM tree is associated to the DOM document.
If you do multiple parse using the same DOM parser instance, then
multiple DOM documents will be generated and saved in a vector
pool. All these documents (and thus all the allocated memory) won't be
deleted until the parser instance is destroyed.
If you don't need these DOM documents anymore and don't want to
destroy the DOM parser instance at this moment, then you can call this
method to reset the document vector pool and release all the allocated
memory back to the system.
There are not likely to be Xerces-C leaks, they have been worked on
for a long time, but it is possible there are XML-Xerces leaks - I
haven't really tested this in some time.
Post any trouble to the list,
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
