Below are some known issues and solutions.
For ActiveMQ client 5.10.1, we've received reports of connection attempts hanging (and blocking the application as a result). This can be fixed (it seems) by setting the following ActiveMQ config:
failover:(tcp://localhost:61616)?timeout=1000&startupMaxReconnectAttempts=5
When compiling the sources with JDK 1.6, you will get a compilation error as reported below - use JDK 1.4 instead.
-compile-without-hibernate: [javac] Compiling 90 source files to /home/ramon/tmp/AtomikosTransactionsEss entials-3.1.7/tmp [javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/DataSourceBean.java:61: com.atomikos.jdbc.DataSourceBean is not abstr act and does not override abstract method isWrapperFor(java.lang.Class<?>) in ja va.sql.Wrapper [javac] public class DataSourceBean implements HeuristicDataSource, Serializable, [javac] ^ [javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/JtaDataSourceImp.java:63: com.atomikos.jdbc.JtaDataSourceImp is not a bstract and does not override abstract method isWrapperFor(java.lang.Class<?>) i n java.sql.Wrapper [javac] public class JtaDataSourceImp implements HeuristicDataSource, [javac] ^ [javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/ExternalXAPooledConnectionImp.java:56: com.atomikos.jdbc.ExternalXAPo oledConnectionImp is not abstract and does not override abstract method removeSt atementEventListener(javax.sql.StatementEventListener) in javax.sql.PooledConnec tion [javac] public class ExternalXAPooledConnectionImp implements DTPPooledConne ction, [javac] ^ [javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/SimpleDataSourceBean.java:73: com.atomikos.jdbc.SimpleDataSourceBean is not abstract and does not override abstract method isWrapperFor(java.lang.Cla ss<?>) in java.sql.Wrapper [javac] public class SimpleDataSourceBean implements HeuristicDataSource, [javac] ^ [javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/nonxa/NonXADataSourceImp.java:69: com.atomikos.jdbc.nonxa.NonXADataSo urceImp is not abstract and does not override abstract method isWrapperFor(java. lang.Class<?>) in java.sql.Wrapper [javac] public class NonXADataSourceImp implements HeuristicDataSource, [javac] ^ [javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/nonxa/DriverManagerDataSource.java:53: com.atomikos.jdbc.nonxa.Driver ManagerDataSource is not abstract and does not override abstract method isWrappe rFor(java.lang.Class<?>) in java.sql.Wrapper [javac] public class DriverManagerDataSource implements DataSource, Serializ able [javac] ^ [javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/nonxa/NonXADataSourceBean.java:59: com.atomikos.jdbc.nonxa.NonXADataS ourceBean is not abstract and does not override abstract method isWrapperFor(jav a.lang.Class<?>) in java.sql.Wrapper [javac] public class NonXADataSourceBean implements HeuristicDataSource, Ref erenceable, [javac] ^ [javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/nonxa/NonXAPooledConnectionImp.java:51: com.atomikos.jdbc.nonxa.NonXA PooledConnectionImp is not abstract and does not override abstract method remove StatementEventListener(javax.sql.StatementEventListener) in javax.sql.PooledConn ection [javac] class NonXAPooledConnectionImp implements XPooledConnection [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 8 errors BUILD FAILEDCheck out Hibernate Integration for information on how to prevent this.
On database restart I want to get connection recovery for the pools. How can we do this?
Answer: configure a testQuery on the datasoure.
See http://fogbugz.atomikos.com/default.asp?community.6.904.2 for this tip - thanks to Adriaan Wisse!NOTE: this known issue should have been solved by release 3.5.6 or later of TransactionsEssentials.
If you use Hibernate 3.3 and get an OutOfMemoryError then this is probably because you have the wrong config.
In particular, make sure to have the following:
hibernate.transaction.factory_class=
com.atomikos.icatch.jta.hibernate3.AtomikosJTATransactionFactory
org.hibernate.ejb.transaction.JoinableCMTTransactionFactory as the factory instead.
JmsTemplate utility class
QueueSenderSession (or TopicSenderSession for topics)
Otherwise, the transaction manager will lose the connection it commits on. This will lead to heuristic errors, and it will appear as if the sending blocks.
Note: improved JMS connection management was part of release 3.4.
This happens if you accidentally instantiate two connectors with the same value for uniqueResourceName. A common example is if you include spring config files multiple times within the same VM: Spring will then create all the beans more than once - and this is problematic for recovery. An example of this problem is here: javax.naming.NamingException: Another resource already exists…
After a crash or improper VM shutdown, you may see an error like this upon startup:
ERROR: the specified log seems to be in use already. Make sure that no other instance is running, and then delete the file tmlog.lck java.lang.RuntimeException: Log already in use?
The lock file in question is created to protect the transaction logs against accidental duplicate startups. Otherwise, the logs could get corrupted when two instances of the same transaction manager are recovering on the same data. Normally, it suffices to follow the hints and then delete the lock file manually if needed.
Note: as of release 3.3, there are no more pending lock files after processes are terminated (not even in case of a VM crash or kill).
Log rollover will fail if you append a slash to the output directory on Windows. In other words, the following is wrong:
com.atomikos.icatch.output_dir = c:\output/
It should be:
com.atomikos.icatch.output_dir = c:\output
Otherwise, the JDK logging will get confused in its rollover functionality, leading to inconsistent rollover at the wrong file sizes.
If you see very many messages saying "Timeout/setRollbackOnly of ACTIVE coordinator": this is a race condition bug that was fixed in the commercial edition.
Maven will (by default) initialize several tests in parallel. If your setUp methods are instantiating the transaction manager and/or datasource instances then you will get errors like:
Another resource already exists with name AtomikosDataSourceJDBCOracle.ASR_WS - pick a different nameTo avoid this, run your maven tests as described in Maven Integration Tests
Exception stack is:
1. Error in rollback: null (com.atomikos.icatch.jta.ExtendedSystemException)
com.atomikos.icatch.jta.TransactionImp:-1 (null)
2. Transaction rollback failed (org.mule.transaction.TransactionRollbackException)
org.mule.transaction.XaTransaction:107 (http://mule.mulesource.org/docs/apidocs/org/mule/transaction/TransactionRollbackException.html)
********************************************************************************
Root Exception stack trace:
com.atomikos.icatch.jta.ExtendedSystemException: Error in rollback: null
at com.atomikos.icatch.jta.TransactionImp.rollback(Unknown Source)
at org.mule.transaction.XaTransaction.doRollback(XaTransaction.java:102)
at org.mule.transaction.AbstractTransaction.rollback(AbstractTransaction.java:120)
at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:98)
at org.mule.providers.TransactedPollingMessageReceiver.poll(TransactedPollingMessageReceiver.java:131)
at org.mule.providers.jms.XaTransactedJmsMessageReceiver.poll(XaTransactedJmsMessageReceiver.java:171)
at org.mule.providers.PollingReceiverWorker.run(PollingReceiverWorker.java:47)
at org.mule.impl.work.WorkerContext.run(WorkerContext.java:310)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
?
This seems to be Mule-specific: the XA transacted receiver polls queue for new messages in transaction. When you shutdown the server those polling threads give you this message. Note that the message can be considered harmless.
More information can be found here: http://www.nabble.com/Mule-shudown-with-jms-and-xa-tf4562317.htmlThe transaction manager keeps a dedicated file (with suffix .epoch) for generating unique XIDs across restarts. This file must never be deleted.
If you accidentally delete the .epoch file then you will generate duplicate XIDs upon restart. On MQSeries, this will generate an error like this:
com.atomikos.datasource.ResourceException: resume for XID pnc_logs0000400001pnc_logs4 raised -8: the supplied XID already exists in this XA resource at com.atomikos.datasource.xa.XAResourceTransaction.resume(Unknown Source) at com.atomikos.jms.DefaultJtaMessageConsumer.enlist(Unknown Source) at com.atomikos.jms.DefaultJtaMessageConsumer.receive(Unknown Source) at com.atomikos.jms.DefaultJtaMessageConsumer.receive(Unknown Source) at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:375) at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:300) at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:234) at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:871) at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:811) at java.lang.Thread.run(Thread.java:595)
To avoid this, never delete the .epoch file.
). This problem only happens if you access the same MySQL database more than once in the same transaction. A workaround can be setting the following property in jta.properties:
com.atomikos.icatch.serial_jta_transactions=false
Also, make sure to set the following property on the MySQL datasource:
pinGlobalTxToPhysicalConnection="true"
MariaDB's java driver also supports this workaround since v.1.1.8
com.atomikos.datasource.ResourceException: resume for XID 192.168.162.50.tm0000100012192.168.162.50.tm1 raised -5: invalid arguments were given for the XA operation at com.atomikos.datasource.xa.XAResourceTransaction.resume(Unknown Source) at com.atomikos.jdbc.ConnectionProxy.invoke(Unknown Source) at $Proxy8.prepareStatement(Unknown Source) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:505) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:94) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2224) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2660) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:56) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:343) at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:135) [...]A possible workaround might be to try and start TransactionsEssentials with the parameter com.atomikos.icatch.serial_jta_transactions set to false.
Also, make sure to set the following property on the MySQL datasource:
pinGlobalTxToPhysicalConnection="true"
This error happens if you try to reuse a non-xa connection in the following way:
This error is common when a common parent transaction is imported twice in a row via RMI, and the RMI runtime accidentally reuses the same thread for related sub-transactions.
Note that this happens if two incoming calls have the same transaction context. In such cases, non-xa connections can give problems. But since non-xa use is not recommended anyhow, this should not be a problem in production environments.
If Oracle JMS/AQ is not properly configured then you will see errors like this (in the tm.out file):
rollback for XID 192.168.226.1.tm0000300002someUniqueName3 raised -3: the XA resource detected an internal error [thread: Thread-17] on: 07-09-25 10:55:01,734 javax.transaction.xa.XAException [thread: Thread-17] on: 07-09-25 10:55:01,734 at: com.my.impl.jms.XAResourceManager.rollback(XAResourceManager.java:200) [thread: Thread-17] on: 07-09-25 10:55:01,735 at: com.my.impl.jms.XAResourceImpl.rollback(XAResourceImpl.java:133) [thread: Thread-17] on: 07-09-25 10:55:01,735 at: com.atomikos.datasource.xa.XAResourceTransaction.rollback(Unknown Source) [thread: Thread-17] on: 07-09-25 10:55:01,735 at: com.atomikos.icatch.imp.RollbackMessage.send(Unknown Source) [thread: Thread-17] on: 07-09-25 10:55:01,735 at: com.atomikos.icatch.imp.PropagationMessage.submit(Unknown Source) [thread: Thread-17] on: 07-09-25 10:55:01,735 at: com.atomikos.icatch.imp.Propagator.run(Unknown Source) [thread: Thread-17] on: 07-09-25 10:55:01,735 at: java.lang.Thread.run(Thread.java:613) [thread: Thread-17] on: 07-09-25 10:55:01,735 rollback for XID 192.168.226.1.tm0000400002someUniqueName4 raised -3: the XA resource detected an internal error [thread: Thread-22] on: 07-09-25 10:55:01,780 javax.transaction.xa.XAException [thread: Thread-22] on: 07-09-25 10:55:01,780 at: com.my.impl.jms.XAResourceManager.rollback(XAResourceManager.java:200) [thread: Thread-22] on: 07-09-25 10:55:01,780 at: com.my.impl.jms.XAResourceImpl.rollback(XAResourceImpl.java:133) [thread: Thread-22] on: 07-09-25 10:55:01,780 at: com.atomikos.datasource.xa.XAResourceTransaction.rollback(Unknown Source) [thread: Thread-22] on: 07-09-25 10:55:01,780 at: com.atomikos.icatch.imp.RollbackMessage.send(Unknown Source) [thread: Thread-22] on: 07-09-25 10:55:01,780 at: com.atomikos.icatch.imp.PropagationMessage.submit(Unknown Source) [thread: Thread-22] on: 07-09-25 10:55:01,780 at: com.atomikos.icatch.imp.Propagator.run(Unknown Source) [thread: Thread-22] on: 07-09-25 10:55:01,780 at: java.lang.Thread.run(Thread.java:613) [thread: Thread-22] on: 07-09-25 10:55:01,780Solution: configure the Oracle JMS as explained here: Configuring Oracle Advanced Queueing
Another error you might see with Oracle JMS is the following:
ERROR IN RECOVERY [thread: Thread-2] on: 06-11-10 14:58:24,486 Error in getting XA resource [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.datasource.xa.jms.JmsTransactionalResource.refreshXAConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.datasource.xa.XATransactionalResource.getXAResource(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.MessageConsumerSession$ReceiverThread.refresh(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.MessageConsumerSession$ReceiverThread.run(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: oracle.jms.AQjmsDBConnMgr.checkForSecurityException(AQjmsDBConnMgr.java:873) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: oracle.jms.AQjmsDBConnMgr.getConnection(AQjmsDBConnMgr.java:580) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: oracle.jms.AQjmsDBConnMgr.<init>(AQjmsDBConnMgr.java:158) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: oracle.jms.AQjmsXAConnection.<init>(AQjmsXAConnection.java:62) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: oracle.jms.AQjmsXAQueueConnectionFactory.createAllXAConnection(AQjmsXAQueueConnectionFactory.java:331) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: oracle.jms.AQjmsXAQueueConnectionFactory.createXAConnection(AQjmsXAQueueConnectionFactory.java:249) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.datasource.xa.jms.JmsTransactionalResource.refreshXAConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.datasource.xa.XATransactionalResource.getXAResource(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.MessageConsumerSession$ReceiverThread.refresh(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486 at: com.atomikos.jms.MessageConsumerSession$ReceiverThread.run(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486This probably means you didn't create the XAConnectionFactory as explained in Configuring Oracle Advanced Queueing.
Another problem that you might see with Oracle AQ is the following:
Atomikos:3 [Fri Apr 10 12:50:00 CEST 2009] AQjmsXAResource.commit: enter: xid=HORA_WS_POC_ATOMIKOS0000200162HORA_WS_POC_ATOMIKOS2 onePhase=true
Atomikos:3 [Fri Apr 10 12:50:00 CEST 2009] AQjmsXAResource.commit: Exception: oracle.jdbc.xa.OracleXAException
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1337)
at oracle.jdbc.xa.client.OracleXAResource.commit(OracleXAResource.java:676)
at oracle.jms.AQjmsXAResource.commit(AQjmsXAResource.java:69)
at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:957)
at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:94)
at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:86)
at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:62)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
WARN [atomikos] XA resource 'XA_ORACLE_QUEUE': commit for XID '484F52415F57535F504F435F41544F4D494B4F5330303030323030313632:484F52415F57535F504F435F41544F4D494B4F5332' raised -7: the XA resource has become unavailable
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1337)
at oracle.jdbc.xa.client.OracleXAResource.commit(OracleXAResource.java:676)
at oracle.jms.AQjmsXAResource.commit(AQjmsXAResource.java:69)
at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:957)
at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:94)
at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:86)
at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:62)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
WARN [atomikos] Unexpected error in commit
com.atomikos.icatch.SysException: XA resource 'XA_ORACLE_QUEUE': commit for XID '484F52415F57535F504F435F41544F4D494B4F5330303030323030313632:484F52415F57535F504F435F41544F4D494B4F5332' raised -7: the XA resource has become unavailable
at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:998)
at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:94)
at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:86)
at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:62)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Solution: make sure that you have set sessionTransacted=true for the JMS session.
This problem (and its solution) was reported here: http://fogbugz.atomikos.com/default.asp?community.6.574.6
When Oracle is not properly configured for XA then the following error may show up in the Atomikos console file:
Error in recovery [thread: main] on: 07-10-02 12:49:59,111 null [thread: main] on: 07-10-02 12:49:59,116 at: oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:526) [thread: main] on: 07-10-02 12:49:59,117 at: com.atomikos.datasource.xa.XATransactionalResource.recover(XATransactionalResource.java:574) [thread: main] on: 07-10-02 12:49:59,118 at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(XATransactionalResource.java:659) [thread: main] on: 07-10-02 12:49:59,118 at: com.atomikos.icatch.imp.TransactionServiceImp.recover(TransactionServiceImp.java:630) [thread: main] on: 07-10-02 12:49:59,118 at: com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(XATransactionalResource.java:506) [thread: main] on: 07-10-02 12:49:59,118 at: com.atomikos.icatch.system.Configuration.addResource(Configuration.java:331) [thread: main] on: 07-10-02 12:49:59,119Solution: make sure that Oracle is configured for XA - as in Configuring Oracle, and that the userid for which XA is required has access rights on the XA catalog tables (explained in Configuring Oracle as well).
When your system runs out of memory, the JMS message delivery threads may terminate with an error log similar to the following:
08-10-17 10:35:22,389 [Thread-11] Failed to invoke 1.5 concurrent thread pool
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.
invoke(DelegatingMethodAccessorI
mpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.atomikos.icatch.imp.thread.Java15ExecutorFactory$Executor.
execute(Unk
nown Source)
at com.atomikos.icatch.imp.thread.TaskManager.executeTask(Unknown
Source)
at com.atomikos.icatch.imp.Propagator.submitPropagationMessage(Unknown
Sourc
e)
at com.atomikos.icatch.imp.CoordinatorStateHandler.commit(Unknown
Source)
at com.atomikos.icatch.imp.IndoubtStateHandler.commit(Unknown Source)
at com.atomikos.icatch.imp.CoordinatorImp.commit(Unknown Source)
at com.atomikos.icatch.imp.CoordinatorImp.terminate(Unknown Source)
at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(Unknown Source)
at com.atomikos.icatch.jta.TransactionImp.commit(Unknown Source)
at com.atomikos.icatch.jta.TransactionManagerImp.commit(Unknown Source)
at com.atomikos.icatch.jta.UserTransactionManager.commit(Unknown Source)
at com.atomikos.jms.MessageConsumerSession$ReceiverThread.run(Unknown
Source
)
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:574)
at java.util.concurrent.ThreadPoolExecutor.
addIfUnderMaximumPoolSize(ThreadP
oolExecutor.java:455)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.
java:8
63)
... 15 more
Solution: make sure to provide enough memory to your application's virtual machine. Use the java -Xmx… -Xms... parameter options to do so.
On PostgreSQL make sure to set the max_prepared_transactions at least as high as the max_connections, or you get heuristic problems.
See this post for the original report.You can get this error in Posgresql under certain conditions, like so:
The last step might fail with a "Transaction interleaving not implemented" warning in the logs. Other use cases may lead to the same error. Customers can avoid this by setting supportsTmJoin = false on the Postgresql datasource. Note that this property is not currently available in the open source TransactionsEssentials.
RMI export of the transaction context will fail if you don't use the proper export parameter in the jta.properties file. In that case, you will see an error similar like the stack trace below:
Mar 26, 2008 4:45:06 PM com.sun.corba.se.impl.util.Utility throwNotSerializableForCorba WARNING: "IOP00100006: (BAD_PARAM) Class com.atomikos.diagnostics.RotatingFileConsole is not Serializable" org.omg.CORBA.BAD_PARAM: vmcid: OMG minor code: 6 completed: Maybe at com.sun.corba.se.impl.logging.OMGSystemException.notSerializable(OMGSystemException.java:990) at com.sun.corba.se.impl.logging.OMGSystemException.notSerializable(OMGSystemException.java:1005) at com.sun.corba.se.impl.util.Utility.throwNotSerializableForCorba(Utility.java:890) at com.sun.corba.se.impl.io.IIOPOutputStream.writeObjectField(IIOPOutputStream.java:734) at com.sun.corba.se.impl.io.IIOPOutputStream.outputClassFields(IIOPOutputStream.java:790) ...
The solution is to configure the jta.properties with the following parameters:
You should add the following for native RMI:
com.atomikos.icatch.rmi_export_class=UnicastRemoteObject
You must add the following line for IIOP:
com.atomikos.icatch.rmi_export_class=PortableRemoteObject
com.atomikos.icatch.jta.J2eeUserTransaction class instead of com.atomikos.icatch.jta.UserTransactionImp. Also, set the parameter com.atomikos.icatch.force_shutdown_on_vm_exit to false in your transactions.properties file (this parameter is supported as from release 3.3).