[JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris reassigned JBTM-2704:
-------------------------------------
Assignee: Gytis Trikleris
> Compensations framework cannot instantiate bean from ear archive
> ----------------------------------------------------------------
>
> Key: JBTM-2704
> URL: https://issues.jboss.org/browse/JBTM-2704
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Compensations
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.next
>
>
> BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed.
> Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager.
> It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Tom Jenkinson created pull request #1035 in GitHub
--------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
> Key: JBTM-2701
> URL: https://issues.jboss.org/browse/JBTM-2701
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Transaction Core
> Affects Versions: 4.17.33
> Environment: JBoss EA P6.4.8
> Reporter: Tom Ross
> Assignee: Amos Feng
> Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2701:
-------------------------------------
I don't see why this: server.log.3:2016-06-28 12:18:33,041 WARN [com.arjuna.ats.jta] (EJB default - 62) ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/netconfresource >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/netconfresource com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e > happens and needs to replace the existing in memory version. Still debugging.
> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
> Key: JBTM-2701
> URL: https://issues.jboss.org/browse/JBTM-2701
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Transaction Core
> Affects Versions: 4.17.33
> Environment: JBoss EA P6.4.8
> Reporter: Tom Ross
> Assignee: Amos Feng
> Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson edited comment on JBTM-2701 at 7/22/16 10:12 AM:
---------------------------------------------------------------
Problem is observed in following scenario:
{code}
0. prepare SAA1
1. prepare XAR1
2. getNewXAResource
3. periodicFirstPass (scans XAR1) - move from IDLE to BETWEEN_PASSES
4. commit XAR1
5. prepare XAR2
6. commit XAR2
7. getNewXAResource
8. periodicFirstPass not called as not IDLE so no scan XAR2
{code}
We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass.
was (Author: tomjenkinson):
Problem is observed in following scenario:
{code}
1. prepare XAR1
2. commit XAR1
4. getNewXAResource
5. periodicFirstPass (scans XAR1) - move from IDLE to BETWEEN_PASSES
6. prepare XAR2
7. commit XAR2
8. getNewXAResource
9. periodicFirstPass not called as not IDLE so no scan XAR2
{code}
We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass.
> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
> Key: JBTM-2701
> URL: https://issues.jboss.org/browse/JBTM-2701
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Transaction Core
> Affects Versions: 4.17.33
> Environment: JBoss EA P6.4.8
> Reporter: Tom Ross
> Assignee: Amos Feng
> Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (JBTM-2678) @TxLogged annotation does not work
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2678?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-2678:
-------------------------------------
If I recall correctly:
The @TxLogged handler is used as a callback for when the TM has written the transaction log. It's a pretty low level callback and was used as a workaround in certain use-cases where a failure-window might occur. However, i think I concluded that the workaround never actually closes any failure windows, it just moves it around. The correct thing to do is to bridge each phase of the compensation transaction to a JTA transaction. The TM then ensures no failure windows exist.
If you need a better understanding I can go into more detail. Maybe with a whiteboard at hand.
> @TxLogged annotation does not work
> ----------------------------------
>
> Key: JBTM-2678
> URL: https://issues.jboss.org/browse/JBTM-2678
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Compensations
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.next
>
>
> @TxLogged annotation does not work in Compensations framework. All it's assertions were removed from the tests with this commit: https://github.com/jbosstm/narayana/commit/efd15eeb080c6b6338f3658c4aa581...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (JBTM-2103) ORB-less JTS
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2103?page=com.atlassian.jira.plugin.... ]
Michael Musgrove closed JBTM-2103.
----------------------------------
Resolution: Won't Fix
This topic came up during our latest F2F: we must continue to interoperate with legacy application servers so will be retaining JTS for that purpose. For vendors that decide not to implement RMI over IIOP we will not be proposing any alternative. We will, however, continue to investigate other options for interoperability (such as googles RPC framework, for example) in the linked JIRA (JBTM-2122).
> ORB-less JTS
> ------------
>
> Key: JBTM-2103
> URL: https://issues.jboss.org/browse/JBTM-2103
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JTS
> Affects Versions: 5.0.0
> Reporter: Mark Little
> Assignee: Michael Musgrove
> Fix For: 6.later
>
>
> At some point in the future there's a good chance that the ORB requirement will be removed from EE entirely. If that happens we need to be able to react and ensure that the JTS continues to work because it’s the most complete distributed transaction implementation that we possess. Now there are two ways to do that:
> (i) we ship our own ORB, either JacORB or something else, say.
> (ii) we remove the dependency on CORBA entirely.
> Whilst (i) is a good short term option, I think we need to look at (ii). An old in-house TM that JBoss had which Narayana replaced had a JTS implementation which supported CORBA and JBoss Remoting (I think it was Remoting). Ultimately what we need is a high performance distributed transactions implementation and JTS is it today but it has a dependency on CORBA that we need to try to remove and yet keep most of the non-ORB generated code/dependencies.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (JBTM-2703) When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2703?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Tom Jenkinson created pull request #1034 in GitHub
--------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2703
> URL: https://issues.jboss.org/browse/JBTM-2703
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> {code}
> INFO [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
> ERROR [stderr] java.io.IOException: java.lang.NullPointerException
> ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
> ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
> ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
> ERROR [stderr] at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
> ERROR [stderr] at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
> ERROR [stderr] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ERROR [stderr] at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ERROR [stderr] at java.lang.Thread.run(Thread.java:745)
> ERROR [stderr] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ERROR [stderr] Caused by: java.lang.NullPointerException
> ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
> ERROR [stderr] ... 10 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (JBTM-2703) When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2703?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2703:
--------------------------------
Description:
{code}
INFO [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
ERROR [stderr] java.io.IOException: java.lang.NullPointerException
ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
ERROR [stderr] at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
ERROR [stderr] at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
ERROR [stderr] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
ERROR [stderr] at java.util.concurrent.FutureTask.run(FutureTask.java:262)
ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
ERROR [stderr] at java.lang.Thread.run(Thread.java:745)
ERROR [stderr] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
ERROR [stderr] Caused by: java.lang.NullPointerException
ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
ERROR [stderr] ... 10 more
{code}
was:
INFO [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
ERROR [stderr] java.io.IOException: java.lang.NullPointerException
ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
ERROR [stderr] at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
ERROR [stderr] at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
ERROR [stderr] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
ERROR [stderr] at java.util.concurrent.FutureTask.run(FutureTask.java:262)
ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
ERROR [stderr] at java.lang.Thread.run(Thread.java:745)
ERROR [stderr] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
ERROR [stderr] Caused by: java.lang.NullPointerException
ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
ERROR [stderr] ... 10 more
> When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2703
> URL: https://issues.jboss.org/browse/JBTM-2703
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA
> Reporter: Tom Jenkinson
> Fix For: 5.next
>
>
> {code}
> INFO [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
> ERROR [stderr] java.io.IOException: java.lang.NullPointerException
> ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
> ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
> ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
> ERROR [stderr] at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
> ERROR [stderr] at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
> ERROR [stderr] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ERROR [stderr] at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ERROR [stderr] at java.lang.Thread.run(Thread.java:745)
> ERROR [stderr] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ERROR [stderr] Caused by: java.lang.NullPointerException
> ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
> ERROR [stderr] ... 10 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (JBTM-2703) When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2703?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned JBTM-2703:
-----------------------------------
Assignee: Tom Jenkinson
> When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2703
> URL: https://issues.jboss.org/browse/JBTM-2703
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> {code}
> INFO [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA<SNIP>: java.io.FileNotFoundException: <SNIP>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/<SNIP> (No such file or directory)
> ERROR [stderr] java.io.IOException: java.lang.NullPointerException
> ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732)
> ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:82)
> ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393)
> ERROR [stderr] at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178)
> ERROR [stderr] at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96)
> ERROR [stderr] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ERROR [stderr] at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ERROR [stderr] at java.lang.Thread.run(Thread.java:745)
> ERROR [stderr] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ERROR [stderr] Caused by: java.lang.NullPointerException
> ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697)
> ERROR [stderr] ... 10 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months