[ 
http://issues.apache.org/jira/browse/XALANJ-2178?page=comments#action_12356639 
] 

Carsten Ziegeler commented on XALANJ-2178:
------------------------------------------

Hi Brian, yes, the issue still exists in 2.7.0. The problem is the thread local 
variable that does not get cleared. An XMLReader is stored in this thread local 
variable and this reader instance is not recycled after it has been used. So 
it's holding a whole tree of objects in memory until this thread with this 
reader instance is used again.
The file I attached contains a workaround: it completly removes the caching of 
the xml reader in a thread local variable. I think this reduces the performance 
in desktop applications (single threaded) while it solves the memory leak 
problem in multi threaded environments.
Now, I think the right way to solve this, is either to not cache xml readers 
(like my version does) or to recycle xml readers by adding a method that cleans 
up the object and it's references after it has been used. But I'm wondering if 
not caching the xml reader is really such a performance problem? I personally 
would go for not caching objects in memory.

> Possible memory leak in XMLReaderManager
> ----------------------------------------
>
>          Key: XALANJ-2178
>          URL: http://issues.apache.org/jira/browse/XALANJ-2178
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: 2.6
>     Reporter: Carsten Ziegeler
>     Priority: Critical
>  Attachments: XMLReaderManager.java
>
> The XMLReaderManager caches the used XMLReader in a thread local variable. In 
> multi tasking environments this is a possible memory leak, as the XMLReader 
> (and everything referenced by this component) is still referenced after the 
> process is finished - until another request uses the same thread.
> In our case this is causing out of memory exceptions.
> I don't know what the correct path to this problem is. For now, we removed 
> the thread locals in the XMLReaderManager completly and created a new reader 
> each time - which has a minor performance downside, but our application is 
> still running :)
> I think one possible solution would be to clean up the reader when the 
> transformation is finished - if this is possible.
> Another solution would be to make this configurable using a property?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to