[JBoss JIRA] (JBTM-1036) NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1036?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1036:
--------------------------------
Description:
1.ArjunaJTA/jdbc
Possible null pointer dereference of conn in com.arjuna.ats.internal.jdbc.recovery.BasicXARecovery.getXAResource() Line 169
3.ArjunaCore/arjuna
com.arjuna.ats.internal.arjuna.objectstore.HashedStore Line 131
Possible null pointer dereference of aUid in com.arjuna.ats.internal.arjuna.objectstore.HashedStore.allObjUids(String, InputObjectState, int)
4.ArjunaJTS/jtax
com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction Line 108
Possible null pointer dereference of ServerTransaction._theXid in com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction.save_state(OutputObjectState, int)
5.ArjunaJTS/jts
com.arjuna.ats.internal.jts.context.ContextManager Line 553
Possible null pointer dereference of action in com.arjuna.ats.internal.jts.context.ContextManager.pushAction(ControlWrapper)
6.ArjunaJTS/jts
com.arjuna.ats.jts.extensions.AtomicTransaction Line 617
Possible null pointer dereference of AtomicTransaction._theAction in com.arjuna.ats.jts.extensions.AtomicTransaction.equals(Object)
was:
1.ArjunaJTA/jdbc
Possible null pointer dereference of conn in com.arjuna.ats.internal.jdbc.recovery.BasicXARecovery.getXAResource() Line 169
2.ArjunaCore/arjuna
com.arjuna.ats.arjuna.StateManager Line 1234
Possible null pointer dereference of action in com.arjuna.ats.arjuna.StateManager.forgetAction(BasicAction, boolean, int)
3.ArjunaCore/arjuna
com.arjuna.ats.internal.arjuna.objectstore.HashedStore Line 131
Possible null pointer dereference of aUid in com.arjuna.ats.internal.arjuna.objectstore.HashedStore.allObjUids(String, InputObjectState, int)
4.ArjunaJTS/jtax
com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction Line 108
Possible null pointer dereference of ServerTransaction._theXid in com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction.save_state(OutputObjectState, int)
5.ArjunaJTS/jts
com.arjuna.ats.internal.jts.context.ContextManager Line 553
Possible null pointer dereference of action in com.arjuna.ats.internal.jts.context.ContextManager.pushAction(ControlWrapper)
6.ArjunaJTS/jts
com.arjuna.ats.jts.extensions.AtomicTransaction Line 617
Possible null pointer dereference of AtomicTransaction._theAction in com.arjuna.ats.jts.extensions.AtomicTransaction.equals(Object)
> NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH)
> ------------------------------------------------------------
>
> Key: JBTM-1036
> URL: https://issues.jboss.org/browse/JBTM-1036
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Transaction Core
> Reporter: Amos Feng
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.0.0.M5
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> 1.ArjunaJTA/jdbc
> Possible null pointer dereference of conn in com.arjuna.ats.internal.jdbc.recovery.BasicXARecovery.getXAResource() Line 169
> 3.ArjunaCore/arjuna
> com.arjuna.ats.internal.arjuna.objectstore.HashedStore Line 131
> Possible null pointer dereference of aUid in com.arjuna.ats.internal.arjuna.objectstore.HashedStore.allObjUids(String, InputObjectState, int)
> 4.ArjunaJTS/jtax
> com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction Line 108
> Possible null pointer dereference of ServerTransaction._theXid in com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction.save_state(OutputObjectState, int)
> 5.ArjunaJTS/jts
> com.arjuna.ats.internal.jts.context.ContextManager Line 553
> Possible null pointer dereference of action in com.arjuna.ats.internal.jts.context.ContextManager.pushAction(ControlWrapper)
> 6.ArjunaJTS/jts
> com.arjuna.ats.jts.extensions.AtomicTransaction Line 617
> Possible null pointer dereference of AtomicTransaction._theAction in com.arjuna.ats.jts.extensions.AtomicTransaction.equals(Object)
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1036) NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1036?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1036:
-------------------------------------
Appears to have been resolved already:
2.ArjunaCore/arjuna
com.arjuna.ats.arjuna.StateManager Line 1234
Possible null pointer dereference of action in com.arjuna.ats.arjuna.StateManager.forgetAction(BasicAction, boolean, int)
> NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH)
> ------------------------------------------------------------
>
> Key: JBTM-1036
> URL: https://issues.jboss.org/browse/JBTM-1036
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Transaction Core
> Reporter: Amos Feng
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.0.0.M5
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> 1.ArjunaJTA/jdbc
> Possible null pointer dereference of conn in com.arjuna.ats.internal.jdbc.recovery.BasicXARecovery.getXAResource() Line 169
> 3.ArjunaCore/arjuna
> com.arjuna.ats.internal.arjuna.objectstore.HashedStore Line 131
> Possible null pointer dereference of aUid in com.arjuna.ats.internal.arjuna.objectstore.HashedStore.allObjUids(String, InputObjectState, int)
> 4.ArjunaJTS/jtax
> com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction Line 108
> Possible null pointer dereference of ServerTransaction._theXid in com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction.save_state(OutputObjectState, int)
> 5.ArjunaJTS/jts
> com.arjuna.ats.internal.jts.context.ContextManager Line 553
> Possible null pointer dereference of action in com.arjuna.ats.internal.jts.context.ContextManager.pushAction(ControlWrapper)
> 6.ArjunaJTS/jts
> com.arjuna.ats.jts.extensions.AtomicTransaction Line 617
> Possible null pointer dereference of AtomicTransaction._theAction in com.arjuna.ats.jts.extensions.AtomicTransaction.equals(Object)
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1934) BlackTie attempting to stop the messagelistener connection - invalid according to JMS
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1934?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1934:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/440
> BlackTie attempting to stop the messagelistener connection - invalid according to JMS
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1934
> URL: https://issues.jboss.org/browse/JBTM-1934
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.M5
>
>
> 12:06:42,851 ERROR [org.codehaus.stomp.jms.StompSubscription] (Thread-10 (HornetQ-client-global-threads-11543367)) Could not stop the connection: javax.jms.IllegalStateException: HQ129006: It is illegal to call this method from within a Message Listener: javax.jms.IllegalStateException: HQ129006: It is illegal to call this method from within a Message Listener
> at org.hornetq.jms.client.ThreadAwareContext.assertNotMessageListenerThread(ThreadAwareContext.java:137)
> at org.hornetq.jms.client.HornetQConnection.stop(HornetQConnection.java:311)
> at org.codehaus.stomp.jms.StompSession.stop(StompSession.java:373) [wildfly-blacktie-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.codehaus.stomp.jms.StompSubscription.onMessage(StompSubscription.java:75) [wildfly-blacktie-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:104)
> at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1117)
> at org.hornetq.core.client.impl.ClientConsumerImpl.access$500(ClientConsumerImpl.java:57)
> at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1252)
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:106)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_03]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1482) If a naughty afterCompletion sync throws an exception, log the exception call stack
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1482?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-1482.
---------------------------------
Fix Version/s: 4.17.11
Resolution: Done
Sorry, I must have resolved this a while back, I am certainly not seeing it anymore. I will mark it as Out of Date, let me know if its not fixed.
I checked it by running a version of ArjunaJTA/jta/tests/../JTATest.java to throw a runtime in afterCompletion and get this:
Sep 19, 2013 2:19:27 PM com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple afterCompletion
WARN: ARJUNA016029: SynchronizationImple.afterCompletion - failed for com.hp.mwtests.ts.jta.common.Synchronization@483ee0b7 with exception
java.lang.RuntimeException
at com.hp.mwtests.ts.jta.common.Synchronization.afterCompletion(Synchronization.java:72)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:532)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
at com.hp.mwtests.ts.jta.basic.JTATest.test(JTATest.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Sep 19, 2013 2:19:33 PM com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator afterCompletion
WARN: ARJUNA012127: TwoPhaseCoordinator.afterCompletion - returned failure for SynchronizationImple< 0:ffff7f000001:d16e:523af9d9:9, com.hp.mwtests.ts.jta.common.Synchronization@483ee0b7 >
Strangely looking at git blame I can't find anytime this would not have been the case for 16029 :(
> If a naughty afterCompletion sync throws an exception, log the exception call stack
> -----------------------------------------------------------------------------------
>
> Key: JBTM-1482
> URL: https://issues.jboss.org/browse/JBTM-1482
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Scott Marlow
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 4.17.11, 5.0.0.M5
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> Currently, when this happens with AS, I see:
> {quote}
> 2013-02-18 16:24:43,837|WARN |[com.arjuna.ats.jta]|(ThreadId: Transaction Reaper Worker 221)|ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.jboss.as.jpa.transaction.TransactionUtil$SessionSynchronization@634ef5a7 with exception: java.lang.NullPointerException
> {quote}
> From a related email conversation:
> {quote}
> Here's our Logger code:
> @Message(id = 16029, value = "SynchronizationImple.afterCompletion - failed for {0} with exception", format = MESSAGE_FORMAT)
> @LogMessage(level = WARN)
> public void warn_resources_arjunacore_SynchronizationImple(String arg0, @Cause() Throwable arg1);
> Here is where we call our logger:
> jtaLogger.i18NLogger.warn_resources_arjunacore_SynchronizationImple(_theSynch.toString(), e);
> Maybe the message should have the {1} in it, i.e. it change it like so:
> "SynchronizationImple.afterCompletion - failed for {0} with exception {1}"
> {quote}
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1935) Replace printStackTrace logging with the i18n logger in XARecoveryModule
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1935?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-1935.
---------------------------------
Fix Version/s: 4.17.11
5.0.0.M5
Resolution: Done
> Replace printStackTrace logging with the i18n logger in XARecoveryModule
> ------------------------------------------------------------------------
>
> Key: JBTM-1935
> URL: https://issues.jboss.org/browse/JBTM-1935
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.7, 4.17.10
> Reporter: Masafumi Miura
> Assignee: Tom Jenkinson
> Fix For: 4.17.11, 5.0.0.M5
>
>
> The following stderr loging is shown when XAException happened at rollback:
> {code}
> ERROR [stderr] (Periodic Recovery) javax.transaction.xa.XAException
> ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:1666)
> ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.DelegatingSession.rollback(DelegatingSession.java:494)
> ERROR [stderr] (Periodic Recovery) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.rollback(HornetQXAResourceWrapper.java:126)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.handleOrphan(XARecoveryModule.java:741)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:647)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:419)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:194)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
> {code}
> This is thrown inside XARecoveryModule#handleOrphan():
> {code:title=ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java|borderStyle=solid}
> private boolean handleOrphan(XAResource xares, Xid xid)
> {
> ...(snip)...
> try
> {
> if(votingOutcome == XAResourceOrphanFilter.Vote.ROLLBACK)
> {
> jtaLogger.i18NLogger.info_recovery_rollingback(XAHelper.xidToString(xid));
> xares.rollback(xid);
> }
> }
> catch (XAException e1)
> {
> e1.printStackTrace();
> ...(snip)...
> {code}
> I think {{e1.printStackTrace();}} should be should be replaced by using the i18n logger. For example:
> {code}
> jtaLogger.i18NLogger.warn_recovery_xarecovery1(_logName+".xaRecovery", XAHelper.printXAErrorCode(e1), e1);
> {code}
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1935) Replace printStackTrace logging with the i18n logger in XARecoveryModule
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1935?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBTM-1935:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1009892
> Replace printStackTrace logging with the i18n logger in XARecoveryModule
> ------------------------------------------------------------------------
>
> Key: JBTM-1935
> URL: https://issues.jboss.org/browse/JBTM-1935
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.7, 4.17.10
> Reporter: Masafumi Miura
> Assignee: Tom Jenkinson
>
> The following stderr loging is shown when XAException happened at rollback:
> {code}
> ERROR [stderr] (Periodic Recovery) javax.transaction.xa.XAException
> ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:1666)
> ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.DelegatingSession.rollback(DelegatingSession.java:494)
> ERROR [stderr] (Periodic Recovery) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.rollback(HornetQXAResourceWrapper.java:126)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.handleOrphan(XARecoveryModule.java:741)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:647)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:419)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:194)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
> {code}
> This is thrown inside XARecoveryModule#handleOrphan():
> {code:title=ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java|borderStyle=solid}
> private boolean handleOrphan(XAResource xares, Xid xid)
> {
> ...(snip)...
> try
> {
> if(votingOutcome == XAResourceOrphanFilter.Vote.ROLLBACK)
> {
> jtaLogger.i18NLogger.info_recovery_rollingback(XAHelper.xidToString(xid));
> xares.rollback(xid);
> }
> }
> catch (XAException e1)
> {
> e1.printStackTrace();
> ...(snip)...
> {code}
> I think {{e1.printStackTrace();}} should be should be replaced by using the i18n logger. For example:
> {code}
> jtaLogger.i18NLogger.warn_recovery_xarecovery1(_logName+".xaRecovery", XAHelper.printXAErrorCode(e1), e1);
> {code}
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1935) Replace printStackTrace logging with the i18n logger in XARecoveryModule
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1935?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1935:
-----------------------------------------------
Masafumi Miura <mmiura(a)redhat.com> made a comment on [bug 1009892|https://bugzilla.redhat.com/show_bug.cgi?id=1009892]
Backport https://issues.jboss.org/browse/JBTM-1935 to improve printStackTrace logging in XARecoveryModule
> Replace printStackTrace logging with the i18n logger in XARecoveryModule
> ------------------------------------------------------------------------
>
> Key: JBTM-1935
> URL: https://issues.jboss.org/browse/JBTM-1935
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.7, 4.17.10
> Reporter: Masafumi Miura
> Assignee: Tom Jenkinson
>
> The following stderr loging is shown when XAException happened at rollback:
> {code}
> ERROR [stderr] (Periodic Recovery) javax.transaction.xa.XAException
> ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:1666)
> ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.DelegatingSession.rollback(DelegatingSession.java:494)
> ERROR [stderr] (Periodic Recovery) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.rollback(HornetQXAResourceWrapper.java:126)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.handleOrphan(XARecoveryModule.java:741)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:647)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:419)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:194)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
> ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
> {code}
> This is thrown inside XARecoveryModule#handleOrphan():
> {code:title=ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java|borderStyle=solid}
> private boolean handleOrphan(XAResource xares, Xid xid)
> {
> ...(snip)...
> try
> {
> if(votingOutcome == XAResourceOrphanFilter.Vote.ROLLBACK)
> {
> jtaLogger.i18NLogger.info_recovery_rollingback(XAHelper.xidToString(xid));
> xares.rollback(xid);
> }
> }
> catch (XAException e1)
> {
> e1.printStackTrace();
> ...(snip)...
> {code}
> I think {{e1.printStackTrace();}} should be should be replaced by using the i18n logger. For example:
> {code}
> jtaLogger.i18NLogger.warn_recovery_xarecovery1(_logName+".xaRecovery", XAHelper.printXAErrorCode(e1), e1);
> {code}
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1935) Replace printStackTrace logging with the i18n logger in XARecoveryModule
by Masafumi Miura (JIRA)
Masafumi Miura created JBTM-1935:
------------------------------------
Summary: Replace printStackTrace logging with the i18n logger in XARecoveryModule
Key: JBTM-1935
URL: https://issues.jboss.org/browse/JBTM-1935
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Recovery
Affects Versions: 4.17.10, 4.17.7
Reporter: Masafumi Miura
Assignee: Tom Jenkinson
The following stderr loging is shown when XAException happened at rollback:
{code}
ERROR [stderr] (Periodic Recovery) javax.transaction.xa.XAException
ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:1666)
ERROR [stderr] (Periodic Recovery) at org.hornetq.core.client.impl.DelegatingSession.rollback(DelegatingSession.java:494)
ERROR [stderr] (Periodic Recovery) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.rollback(HornetQXAResourceWrapper.java:126)
ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.handleOrphan(XARecoveryModule.java:741)
ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:647)
ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:419)
ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:194)
ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
{code}
This is thrown inside XARecoveryModule#handleOrphan():
{code:title=ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java|borderStyle=solid}
private boolean handleOrphan(XAResource xares, Xid xid)
{
...(snip)...
try
{
if(votingOutcome == XAResourceOrphanFilter.Vote.ROLLBACK)
{
jtaLogger.i18NLogger.info_recovery_rollingback(XAHelper.xidToString(xid));
xares.rollback(xid);
}
}
catch (XAException e1)
{
e1.printStackTrace();
...(snip)...
{code}
I think {{e1.printStackTrace();}} should be should be replaced by using the i18n logger. For example:
{code}
jtaLogger.i18NLogger.warn_recovery_xarecovery1(_logName+".xaRecovery", XAHelper.printXAErrorCode(e1), e1);
{code}
--
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
11 years, 2 months