[jboss-jira] [JBoss JIRA] (AS7-4975) XA datasources memory leak
Marcel Å ebek (JIRA)
jira-events at lists.jboss.org
Mon Jun 11 07:40:04 EDT 2012
Marcel Å ebek created AS7-4975:
----------------------------------
Summary: XA datasources memory leak
Key: AS7-4975
URL: https://issues.jboss.org/browse/AS7-4975
Project: Application Server 7
Issue Type: Bug
Components: Transactions
Affects Versions: 7.1.1.Final
Environment: Debian stable
Postgres version: 8.4.11
jdbc driver version: 9.1-902.jdbc4
database is assumed to contain a schema named test.
datasource definition:
<xa-datasource jndi-name="java:/jdbc/test" pool-name="test" enabled="true" use-ccm="false">
<xa-datasource-property name="PortNumber">
5432
</xa-datasource-property>
<xa-datasource-property name="DatabaseName">
${db.name}
</xa-datasource-property>
<xa-datasource-property name="ServerName">
127.0.0.1
</xa-datasource-property>
<xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
<driver>postgresql-9.1-902.jdbc4.jar</driver>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<xa-pool>
<is-same-rm-override>false</is-same-rm-override>
<interleaving>false</interleaving>
<pad-xid>false</pad-xid>
<wrap-xa-resource>false</wrap-xa-resource>
</xa-pool>
<security>
<user-name>${db.name}_test</user-name>
<password>${db.name}_test</password>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
</validation>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</xa-datasource>
Reporter: Marcel Å ebek
Assignee: Jason Greene
I'm experiencing problems with XA datasources on jboss 7 and postgres database. The test application periodically (each 5 seconds) performs several JPA queries. I use @Schedule facility on @Singleton @Startup bean. However, after a few days, the server runs out of memory. Switching to local tx datasources seems to fix the problem. Analysis of heap dump using visualvm gives the following:
Heap is quite full (~490 MB from 512MB), most space is taken by byte[] (40%, 200MB) and HashMap.Entry (16%, 80MB) objects, so that gives no much information. Computing retained sizes shows that most space (but just ~16MB) is taken by com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule#1. Further analysis shows that XARecoveryModule._xidScans contains ~8000 entries. The size continuously grows. When the dump is taken before the OOM conditions starts, eg. when the heap is 50% full, the size of this hashmap is ~4000, so it looks like it grows continuously.
I will attach my example test case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list