[JBoss JIRA] (JBTM-1854) Hornetq failures in CI test suite
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-1854:
----------------------------------------
I have dropped the priority to minor since this issue is only effecting JTS running with JDK orb. Running with JacOrb passes (eg http://172.17.131.2/job/narayana-hqstore/11/).
I have updated CI so that we test hornetq store with the two orbs separately. If we start seeing intermittent failures on the job that uses JacOrb then we can tackle those as and when the arise.
> Hornetq failures in CI test suite
> ---------------------------------
>
> Key: JBTM-1854
> URL: https://issues.jboss.org/browse/JBTM-1854
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 5.0.0.M3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.0.0.M5
>
> Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz
>
>
> The first CI job link includes:
> CurrentTests01_Test036
> jtsremote JTSRemote_ImplicitPropagationTest
> crashrecovery02_2 CrashRecovery02_2 - all of them
> crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10
> crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them)
> The second CI job link includes:
> JTSRemote_ImplicitPropagationTest failure
> CrashRecovery02_2_Test46 hang
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1854) Hornetq failures in CI test suite
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-1854:
-----------------------------------
Priority: Minor (was: Major)
> Hornetq failures in CI test suite
> ---------------------------------
>
> Key: JBTM-1854
> URL: https://issues.jboss.org/browse/JBTM-1854
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 5.0.0.M3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.0.0.M5
>
> Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz
>
>
> The first CI job link includes:
> CurrentTests01_Test036
> jtsremote JTSRemote_ImplicitPropagationTest
> crashrecovery02_2 CrashRecovery02_2 - all of them
> crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10
> crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them)
> The second CI job link includes:
> JTSRemote_ImplicitPropagationTest failure
> CrashRecovery02_2_Test46 hang
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1879) JdbcObjectStore is not closing connection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1879?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1879:
--------------------------------
Fix Version/s: 4.17.8
5.0.0.M5
> JdbcObjectStore is not closing connection
> -----------------------------------------
>
> Key: JBTM-1879
> URL: https://issues.jboss.org/browse/JBTM-1879
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 4.17.8, 5.0.0.M5
>
>
> maeste: it looks like a bug on our side, can you raise a Jira for us please (maybe with your stack trace)?
> <tomjenkinson> maeste: thanks for fixing WFLY-1460 :)
> <jbossbot> jira [WFLY-1460] WildFly server fails to start with transactions configured to be run with JDBCObject store [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/WFLY-1460
> <tomjenkinson> maeste: it looks like the same thread is not used more than once?
> <tomjenkinson> maeste: the connection was being held on the thread you see
> <tomjenkinson> maeste: I assume that new threads are created constantly and not recycled now in WildFly?
> <maeste> tomjenkinson: yup should be
> <tomjenkinson> maeste: if there was a thread pool you would not have seen this
> <maeste> tomjenkinson: hmmm is on shotdown
> <maeste> tomjenkinson: on thread pool removing so
> <maeste> tomjenkinson: BTW I've just configure jdbcstore No operation executed, and so I suppose no write on DB, and I get this stacktrace when I shutdown WildFly
> <tomjenkinson> maeste: we can close the connections more timely it is ok, I don't know what the performance impact of connection.close with each object store update though
> <tomjenkinson> maeste: when you say "this stacktrace" you mean the gist you pasted before?
> <maeste> tomjenkinson: can't you close connection on shutdown? Well I'm fine to call a new convenient method on service shutdown if it's doable
> <maeste> tomjenkinson: yup
> <tomjenkinson> maeste: we are allocating one connection per thread
> * clebert (~clebert@redhat/jboss/clebert) has joined #jbossts
> <tomjenkinson> maeste: would shutdown be called on the transaction manager before LeakConnectionDetecter is triggered?
> <tomjenkinson> maeste: if so that sounds like the best idea
> <maeste> tomjenkinson: yup
> * Jaikiran (~jaikiran@redhat/jboss/Jaikiran) has joined #jbossts
> <tomjenkinson> maeste: ok, so we can do that, we can store the references that each thread creates in a global map too, then in shutdown close them all
> <tomjenkinson> maeste: then hook that into the transaction subsystem
> Stack trace
> 16:40:23,273 ERROR [org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool] (MSC service thread 1-2) IJ000616: Leak detected in pool: ExampleDS: java.lang.Throwable: ALLOCATION LEAK
> at org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool.getConnection(LeakDumperManagedConnectionPool.java:90) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:452) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:420) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:379) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:352) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:513) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:142) [ironjacamar-jdbc-1.1.0.Final.jar:1.1.0.Final]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DataSourceJDBCAccess.getConnection(DataSourceJDBCAccess.java:50) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver$1.initialValue(JDBCImple_driver.java:632) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver$1.initialValue(JDBCImple_driver.java:627) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:160) [rt.jar:1.7.0_09-icedtea]
> at java.lang.ThreadLocal.get(ThreadLocal.java:150) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver.initialise(JDBCImple_driver.java:639) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.<init>(JDBCStore.java:267) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_09-icedtea]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:131) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:165) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.setupStore(StoreManager.java:136) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.getTxOJStore(StoreManager.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.txoj.recovery.TORecoveryModule.<init>(TORecoveryModule.java:73) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_09-icedtea]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Class.newInstance0(Class.java:374) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Class.newInstance(Class.java:327) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:194) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:444) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:861) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:121) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:113) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:460) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:130) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:110) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:113) [wildfly-transactions-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1879) JdbcObjectStore is not closing connection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1879?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1879:
--------------------------------
Priority: Critical (was: Major)
> JdbcObjectStore is not closing connection
> -----------------------------------------
>
> Key: JBTM-1879
> URL: https://issues.jboss.org/browse/JBTM-1879
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Tom Jenkinson
> Priority: Critical
>
> maeste: it looks like a bug on our side, can you raise a Jira for us please (maybe with your stack trace)?
> <tomjenkinson> maeste: thanks for fixing WFLY-1460 :)
> <jbossbot> jira [WFLY-1460] WildFly server fails to start with transactions configured to be run with JDBCObject store [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/WFLY-1460
> <tomjenkinson> maeste: it looks like the same thread is not used more than once?
> <tomjenkinson> maeste: the connection was being held on the thread you see
> <tomjenkinson> maeste: I assume that new threads are created constantly and not recycled now in WildFly?
> <maeste> tomjenkinson: yup should be
> <tomjenkinson> maeste: if there was a thread pool you would not have seen this
> <maeste> tomjenkinson: hmmm is on shotdown
> <maeste> tomjenkinson: on thread pool removing so
> <maeste> tomjenkinson: BTW I've just configure jdbcstore No operation executed, and so I suppose no write on DB, and I get this stacktrace when I shutdown WildFly
> <tomjenkinson> maeste: we can close the connections more timely it is ok, I don't know what the performance impact of connection.close with each object store update though
> <tomjenkinson> maeste: when you say "this stacktrace" you mean the gist you pasted before?
> <maeste> tomjenkinson: can't you close connection on shutdown? Well I'm fine to call a new convenient method on service shutdown if it's doable
> <maeste> tomjenkinson: yup
> <tomjenkinson> maeste: we are allocating one connection per thread
> * clebert (~clebert@redhat/jboss/clebert) has joined #jbossts
> <tomjenkinson> maeste: would shutdown be called on the transaction manager before LeakConnectionDetecter is triggered?
> <tomjenkinson> maeste: if so that sounds like the best idea
> <maeste> tomjenkinson: yup
> * Jaikiran (~jaikiran@redhat/jboss/Jaikiran) has joined #jbossts
> <tomjenkinson> maeste: ok, so we can do that, we can store the references that each thread creates in a global map too, then in shutdown close them all
> <tomjenkinson> maeste: then hook that into the transaction subsystem
> Stack trace
> 16:40:23,273 ERROR [org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool] (MSC service thread 1-2) IJ000616: Leak detected in pool: ExampleDS: java.lang.Throwable: ALLOCATION LEAK
> at org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool.getConnection(LeakDumperManagedConnectionPool.java:90) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:452) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:420) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:379) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:352) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:513) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:142) [ironjacamar-jdbc-1.1.0.Final.jar:1.1.0.Final]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DataSourceJDBCAccess.getConnection(DataSourceJDBCAccess.java:50) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver$1.initialValue(JDBCImple_driver.java:632) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver$1.initialValue(JDBCImple_driver.java:627) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:160) [rt.jar:1.7.0_09-icedtea]
> at java.lang.ThreadLocal.get(ThreadLocal.java:150) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver.initialise(JDBCImple_driver.java:639) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.<init>(JDBCStore.java:267) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_09-icedtea]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:131) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:165) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.setupStore(StoreManager.java:136) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.getTxOJStore(StoreManager.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.txoj.recovery.TORecoveryModule.<init>(TORecoveryModule.java:73) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_09-icedtea]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Class.newInstance0(Class.java:374) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Class.newInstance(Class.java:327) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:194) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:444) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:861) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:121) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:113) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:460) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:130) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:110) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:113) [wildfly-transactions-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1880) opname: shouldMerge cannot process request, because object doesn't exist
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1880?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-1880.
---------------------------------
Resolution: Migrated to another ITS
Tom, please can you add a link to an upstream JacORB issue here when you have it?
> opname: shouldMerge cannot process request, because object doesn't exist
> ------------------------------------------------------------------------
>
> Key: JBTM-1880
> URL: https://issues.jboss.org/browse/JBTM-1880
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA
> Reporter: Tom Ross
> Assignee: Tom Jenkinson
>
> When dealing with some situations we choose to ignore certain exceptions [1]
> {noformat}
> if (rec != null)
> {
> try
> {
> result = resHandle.shouldMerge(rec);
> }
> catch (OBJECT_NOT_EXIST ex)
> {
> // This is expected to happen whenever a resource has gone away, for example during a crash or if it has exited the 2PC process early by returning XA_RDONLY out of prepare
> }
> catch (Exception e) {
> _endpointFailed = true;
> jtsLogger.i18NLogger.warn_resources_errgenerr("ExtendedResourceRecord.shouldMerge", e);
> }
> rec = null;
> }
> {noformat}
> Unfortunately jacorb does log it and the result is a log file full warnings:
>
> {noformat}
> [jacorb.poa.controller] (RequestController-1) rid: 42 opname: shouldMerge cannot process request, because object doesn't exist
> {noformat}
> If we have decided to ignore this warning then JACORB should the same and not log it at WARN level.
> [1] https://github.com/tomjenkinson/narayana/blob/4.17/ArjunaJTS/jts/classes/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1880) opname: shouldMerge cannot process request, because object doesn't exist
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1880?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1880:
-------------------------------------
Hi Tom,
I was suggesting for you to log a JacORB issue, sorry if I wasn't clear.
Thanks,
Tom
> opname: shouldMerge cannot process request, because object doesn't exist
> ------------------------------------------------------------------------
>
> Key: JBTM-1880
> URL: https://issues.jboss.org/browse/JBTM-1880
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA
> Reporter: Tom Ross
> Assignee: Tom Jenkinson
>
> When dealing with some situations we choose to ignore certain exceptions [1]
> {noformat}
> if (rec != null)
> {
> try
> {
> result = resHandle.shouldMerge(rec);
> }
> catch (OBJECT_NOT_EXIST ex)
> {
> // This is expected to happen whenever a resource has gone away, for example during a crash or if it has exited the 2PC process early by returning XA_RDONLY out of prepare
> }
> catch (Exception e) {
> _endpointFailed = true;
> jtsLogger.i18NLogger.warn_resources_errgenerr("ExtendedResourceRecord.shouldMerge", e);
> }
> rec = null;
> }
> {noformat}
> Unfortunately jacorb does log it and the result is a log file full warnings:
>
> {noformat}
> [jacorb.poa.controller] (RequestController-1) rid: 42 opname: shouldMerge cannot process request, because object doesn't exist
> {noformat}
> If we have decided to ignore this warning then JACORB should the same and not log it at WARN level.
> [1] https://github.com/tomjenkinson/narayana/blob/4.17/ArjunaJTS/jts/classes/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months