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