[JBoss JIRA] (JBTM-3074) No test cleanup for STM taxonomy tests
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3074?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Michael Musgrove created pull request #1389 in GitHub
-----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> No test cleanup for STM taxonomy tests
> ---------------------------------------
>
> Key: JBTM-3074
> URL: https://issues.jboss.org/browse/JBTM-3074
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: STM
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: stm.dump
>
>
> The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (JBTM-3083) Cannot get delegate of JMSContext during an beforeCompletion synch
by Jan-Willem Gmelig Meyling (Jira)
[ https://issues.jboss.org/browse/JBTM-3083?page=com.atlassian.jira.plugin.... ]
Jan-Willem Gmelig Meyling updated JBTM-3083:
--------------------------------------------
Description:
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction. (Because the synchronization cannot be placed)
*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
(Which refers to WildFly 8.0.0.CR1)
Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
See the attached log for a full stack trace.
was:
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.
*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
(Which refers to WildFly 8.0.0.CR1)
Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
See the attached log for a full stack trace.
> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
> Key: JBTM-3083
> URL: https://issues.jboss.org/browse/JBTM-3083
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
> Reporter: Jan-Willem Gmelig Meyling
> Priority: Minor
> Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction. (Because the synchronization cannot be placed)
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (JBTM-3083) Cannot get delegate of JMSContext during an beforeCompletion synch
by Jan-Willem Gmelig Meyling (Jira)
[ https://issues.jboss.org/browse/JBTM-3083?page=com.atlassian.jira.plugin.... ]
Jan-Willem Gmelig Meyling updated JBTM-3083:
--------------------------------------------
Summary: Cannot get delegate of JMSContext during an beforeCompletion synch (was: Cannot get delegate of JMSContext during an beforeCompletion invocation)
> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
> Key: JBTM-3083
> URL: https://issues.jboss.org/browse/JBTM-3083
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
> Reporter: Jan-Willem Gmelig Meyling
> Priority: Minor
> Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the pre-commit synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (JBTM-3083) Cannot get delegate of JMSContext during an beforeCompletion synch
by Jan-Willem Gmelig Meyling (Jira)
[ https://issues.jboss.org/browse/JBTM-3083?page=com.atlassian.jira.plugin.... ]
Jan-Willem Gmelig Meyling updated JBTM-3083:
--------------------------------------------
Description:
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.
*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
(Which refers to WildFly 8.0.0.CR1)
Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
See the attached log for a full stack trace.
was:
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.
*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the pre-commit synchronization.
The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
(Which refers to WildFly 8.0.0.CR1)
Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
See the attached log for a full stack trace.
> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
> Key: JBTM-3083
> URL: https://issues.jboss.org/browse/JBTM-3083
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
> Reporter: Jan-Willem Gmelig Meyling
> Priority: Minor
> Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (JBTM-3083) Cannot get delegate of JMSContext during an beforeCompletion invocation
by Jan-Willem Gmelig Meyling (Jira)
Jan-Willem Gmelig Meyling created JBTM-3083:
-----------------------------------------------
Summary: Cannot get delegate of JMSContext during an beforeCompletion invocation
Key: JBTM-3083
URL: https://issues.jboss.org/browse/JBTM-3083
Project: JBoss Transaction Manager
Issue Type: Bug
Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
WildFly 8.0.0.CR1
Reporter: Jan-Willem Gmelig Meyling
Attachments: ARJUNA016082.log
The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction.
*Use case*
I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
*Workaround*
Flush the {{EntityManager}} and don't leave the flushing up to the pre-commit synchronization.
The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
(Which refers to WildFly 8.0.0.CR1)
Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
See the attached log for a full stack trace.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (JBTM-3074) No test cleanup for STM taxonomy tests
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3074?page=com.atlassian.jira.plugin.... ]
Michael Musgrove reassigned JBTM-3074:
--------------------------------------
Assignee: Michael Musgrove
> No test cleanup for STM taxonomy tests
> ---------------------------------------
>
> Key: JBTM-3074
> URL: https://issues.jboss.org/browse/JBTM-3074
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: STM
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: stm.dump
>
>
> The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (JBTM-3074) No test cleanup for STM taxonomy tests
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/JBTM-3074?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-3074:
-----------------------------------
Component/s: STM
> No test cleanup for STM taxonomy tests
> ---------------------------------------
>
> Key: JBTM-3074
> URL: https://issues.jboss.org/browse/JBTM-3074
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: STM
> Reporter: Michael Musgrove
> Priority: Major
> Attachments: stm.dump
>
>
> The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (JBTM-3079) InboundBridge recovery aborts live transactions
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Ondra Chaloupka created pull request #1387 in GitHub
----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Coding In Progress)
> InboundBridge recovery aborts live transactions
> -----------------------------------------------
>
> Key: JBTM-3079
> URL: https://issues.jboss.org/browse/JBTM-3079
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: TxBridge
> Affects Versions: 5.5.32.Final, 5.9.0.Final
> Environment: EAP 7.1.5 / 5.5.32.Final
> Reporter: Jonathan Halliday
> Assignee: Tom Jenkinson
> Priority: Critical
> Attachments: jbtm3079.patch
>
>
> During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.
> TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >)
> TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... >
> ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException
> It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (JBTM-3081) InboundBridge recovery aborts live transactions
by Tom Jenkinson (Jira)
Tom Jenkinson created JBTM-3081:
-----------------------------------
Summary: InboundBridge recovery aborts live transactions
Key: JBTM-3081
URL: https://issues.jboss.org/browse/JBTM-3081
Project: JBoss Transaction Manager
Issue Type: Bug
Components: TxBridge
Affects Versions: 5.5.32.Final, 5.9.0.Final
Environment: EAP 7.1.5 / 5.5.32.Final
Reporter: Jonathan Halliday
Assignee: Tom Jenkinson
Attachments: jbtm3079.patch
During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes.
TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >)
TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... >
ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException
It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years