You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "David Abeita (JIRA)" <ji...@apache.org> on 2010/01/28 22:40:25 UTC
[jira] Created: (STR-3197) Memory leak detected in
org.apache.struts.tiles.xmlDefinition.I18nFactorySet
Memory leak detected in org.apache.struts.tiles.xmlDefinition.I18nFactorySet
----------------------------------------------------------------------------
Key: STR-3197
URL: https://issues.apache.org/struts/browse/STR-3197
Project: Struts 1
Issue Type: Bug
Components: Tiles 1 Plugin
Affects Versions: 1.3.8, 1.1.1
Environment: AIX, Windows, WebSphere 6.1, DB2 9.5
Reporter: David Abeita
Attachments: patchfile.txt
During performance testing we discovered an Out of Memory exception. While looking into the heap dump produced, I detected two separate tiles objects (namely org.apache.struts.tiles.xmlDefinition.XmlParser and org.apache.struts.tiles.xmlDefinition.DefinitionsFactory) which combined were consuming 285 meg. After further analysis of the code in org.apache.struts.tiles.xmlDefinition.I18nFactorySet, I discovered that for each tile config file being processed by org.apache.struts.tiles.xmlDefinition.I18nFactorySet.parseXmlFile(ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions) was creating a new XmlParser() to parse the tiles config file and put into an XmlDefinitionsSet. The new XmlDefinitionsSet is ultimately used to construct org.apache.struts.tiles.xmlDefinition.DefinitionsFactory. After the last file is processed the XmlParser is kept in memory and no longer performs the necessary function after initializing Tiles is complete. The underlying SAXParser and other objects are still there consuming resources.
I removed the following code from org.apache.struts.tiles.xmlDefinition.I18nFactorySet.
/**
* XML parser used.
* Attribute is transient to allow serialization. In this implementaiton,
* xmlParser is created each time we need it ;-(.
*/
protected transient XmlParser xmlParser;
And changed the following in the method parseXmlFile( ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions)
I've included a patch file with changes also.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STR-3197) Memory leak detected in
org.apache.struts.tiles.xmlDefinition.I18nFactorySet
Posted by "David Abeita (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Abeita updated STR-3197:
------------------------------
Description:
During performance testing we discovered an Out of Memory exception. While looking into the heap dump produced, I detected two separate tiles objects (namely org.apache.struts.tiles.xmlDefinition.XmlParser and org.apache.struts.tiles.xmlDefinition.DefinitionsFactory) which combined were consuming 285 meg (we have a lot of tiles definitions). After further analysis of the code in org.apache.struts.tiles.xmlDefinition.I18nFactorySet, I discovered that for each tile config file being processed by org.apache.struts.tiles.xmlDefinition.I18nFactorySet.parseXmlFile(ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions) was creating a new XmlParser() to parse the tiles config file and put into an XmlDefinitionsSet. The new XmlDefinitionsSet is ultimately used to construct org.apache.struts.tiles.xmlDefinition.DefinitionsFactory. After the last file is processed the XmlParser is kept in memory and no longer performs the necessary function after initializing Tiles is complete. The underlying SAXParser and other objects are still there consuming resources.
I removed the following code from org.apache.struts.tiles.xmlDefinition.I18nFactorySet.
/**
* XML parser used.
* Attribute is transient to allow serialization. In this implementaiton,
* xmlParser is created each time we need it ;-(.
*/
protected transient XmlParser xmlParser;
And changed the following in the method parseXmlFile( ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions)
I've included a patch file with changes also.
was:
During performance testing we discovered an Out of Memory exception. While looking into the heap dump produced, I detected two separate tiles objects (namely org.apache.struts.tiles.xmlDefinition.XmlParser and org.apache.struts.tiles.xmlDefinition.DefinitionsFactory) which combined were consuming 285 meg. After further analysis of the code in org.apache.struts.tiles.xmlDefinition.I18nFactorySet, I discovered that for each tile config file being processed by org.apache.struts.tiles.xmlDefinition.I18nFactorySet.parseXmlFile(ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions) was creating a new XmlParser() to parse the tiles config file and put into an XmlDefinitionsSet. The new XmlDefinitionsSet is ultimately used to construct org.apache.struts.tiles.xmlDefinition.DefinitionsFactory. After the last file is processed the XmlParser is kept in memory and no longer performs the necessary function after initializing Tiles is complete. The underlying SAXParser and other objects are still there consuming resources.
I removed the following code from org.apache.struts.tiles.xmlDefinition.I18nFactorySet.
/**
* XML parser used.
* Attribute is transient to allow serialization. In this implementaiton,
* xmlParser is created each time we need it ;-(.
*/
protected transient XmlParser xmlParser;
And changed the following in the method parseXmlFile( ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions)
I've included a patch file with changes also.
> Memory leak detected in org.apache.struts.tiles.xmlDefinition.I18nFactorySet
> ----------------------------------------------------------------------------
>
> Key: STR-3197
> URL: https://issues.apache.org/struts/browse/STR-3197
> Project: Struts 1
> Issue Type: Bug
> Components: Tiles 1 Plugin
> Affects Versions: 1.1.1, 1.3.8
> Environment: AIX, Windows, WebSphere 6.1, DB2 9.5
> Reporter: David Abeita
> Attachments: patchfile.txt
>
>
> During performance testing we discovered an Out of Memory exception. While looking into the heap dump produced, I detected two separate tiles objects (namely org.apache.struts.tiles.xmlDefinition.XmlParser and org.apache.struts.tiles.xmlDefinition.DefinitionsFactory) which combined were consuming 285 meg (we have a lot of tiles definitions). After further analysis of the code in org.apache.struts.tiles.xmlDefinition.I18nFactorySet, I discovered that for each tile config file being processed by org.apache.struts.tiles.xmlDefinition.I18nFactorySet.parseXmlFile(ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions) was creating a new XmlParser() to parse the tiles config file and put into an XmlDefinitionsSet. The new XmlDefinitionsSet is ultimately used to construct org.apache.struts.tiles.xmlDefinition.DefinitionsFactory. After the last file is processed the XmlParser is kept in memory and no longer performs the necessary function after initializing Tiles is complete. The underlying SAXParser and other objects are still there consuming resources.
> I removed the following code from org.apache.struts.tiles.xmlDefinition.I18nFactorySet.
> /**
> * XML parser used.
> * Attribute is transient to allow serialization. In this implementaiton,
> * xmlParser is created each time we need it ;-(.
> */
> protected transient XmlParser xmlParser;
> And changed the following in the method parseXmlFile( ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions)
> I've included a patch file with changes also.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STR-3197) Memory leak detected in
org.apache.struts.tiles.xmlDefinition.I18nFactorySet
Posted by "David Abeita (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Abeita updated STR-3197:
------------------------------
Attachment: patchfile.txt
> Memory leak detected in org.apache.struts.tiles.xmlDefinition.I18nFactorySet
> ----------------------------------------------------------------------------
>
> Key: STR-3197
> URL: https://issues.apache.org/struts/browse/STR-3197
> Project: Struts 1
> Issue Type: Bug
> Components: Tiles 1 Plugin
> Affects Versions: 1.1.1, 1.3.8
> Environment: AIX, Windows, WebSphere 6.1, DB2 9.5
> Reporter: David Abeita
> Attachments: patchfile.txt
>
>
> During performance testing we discovered an Out of Memory exception. While looking into the heap dump produced, I detected two separate tiles objects (namely org.apache.struts.tiles.xmlDefinition.XmlParser and org.apache.struts.tiles.xmlDefinition.DefinitionsFactory) which combined were consuming 285 meg. After further analysis of the code in org.apache.struts.tiles.xmlDefinition.I18nFactorySet, I discovered that for each tile config file being processed by org.apache.struts.tiles.xmlDefinition.I18nFactorySet.parseXmlFile(ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions) was creating a new XmlParser() to parse the tiles config file and put into an XmlDefinitionsSet. The new XmlDefinitionsSet is ultimately used to construct org.apache.struts.tiles.xmlDefinition.DefinitionsFactory. After the last file is processed the XmlParser is kept in memory and no longer performs the necessary function after initializing Tiles is complete. The underlying SAXParser and other objects are still there consuming resources.
> I removed the following code from org.apache.struts.tiles.xmlDefinition.I18nFactorySet.
> /**
> * XML parser used.
> * Attribute is transient to allow serialization. In this implementaiton,
> * xmlParser is created each time we need it ;-(.
> */
> protected transient XmlParser xmlParser;
> And changed the following in the method parseXmlFile( ServletContext servletContext, String filename, XmlDefinitionsSet xmlDefinitions)
> I've included a patch file with changes also.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.