[JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2831:
--------------------------------
Fix Version/s: 5.next
(was: 5.6.0.Final)
> Fix RTS inbound bridge participant deserialiser registration
> ------------------------------------------------------------
>
> Key: JBTM-2831
> URL: https://issues.jboss.org/browse/JBTM-2831
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: REST
> Reporter: Gytis Trikleris
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource.
> In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method.
> However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot.
> Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module.
> I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule.
> [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/ma...
> [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (JBTM-2869) Deprecate SPI transaction event notifications
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2869?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2869.
-------------------------------
> Deprecate SPI transaction event notifications
> ---------------------------------------------
>
> Key: JBTM-2869
> URL: https://issues.jboss.org/browse/JBTM-2869
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: SPI
> Affects Versions: 5.5.5.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Optional
> Fix For: 5.6.0.Final
>
>
> The SPI API for monitoring thread to transaction association changes needs deprecating. It was introduced in JBTM-2343 (Interface for tracking thread/transaction association changes) and WFLY-4923.
> The ability to listen for such changes has been re implemented by WFTC (see WFLY commit 7ef53b800:- Updated EJB client integration: Fixes to start bringing Transactions, EJB, and Discovery together) so we should stop generating these events.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (JBTM-2865) Cache store can get an NPE as work is written to outside of _workList lock
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2865?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2865.
-------------------------------
> Cache store can get an NPE as work is written to outside of _workList lock
> --------------------------------------------------------------------------
>
> Key: JBTM-2865
> URL: https://issues.jboss.org/browse/JBTM-2865
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.6.0.Final
>
>
> {code}
> java.lang.NullPointerException
> at com.arjuna.ats.internal.arjuna.objectstore.AsyncStore.getState(CacheStore.java:579)
> at com.arjuna.ats.internal.arjuna.objectstore.CacheStore.read_state(CacheStore.java:130)
> at com.arjuna.ats.internal.arjuna.objectstore.FileSystemStore.read_state_internal(FileSystemStore.java:331)
> at com.arjuna.ats.internal.arjuna.objectstore.FileSystemStore.read_committed(FileSystemStore.java:103)
> at com.hp.mwtests.ts.arjuna.objectstore.ThreadWriter.run(CachedTest.java:69)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (JBTM-2885) Orphan detection may attempt to rollback orphan if resource fails to return values
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2885?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2885.
-------------------------------
> Orphan detection may attempt to rollback orphan if resource fails to return values
> ----------------------------------------------------------------------------------
>
> Key: JBTM-2885
> URL: https://issues.jboss.org/browse/JBTM-2885
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Priority: Optional
> Fix For: 5.6.0.Final
>
>
> If the XAR returns a Xid from recover(FIRST_PASS) to XARM but then goes offline for a cycle we may attempt to rollback the Xid thinking it is stale. If the XAR returns an XAE at that point we should clear the _xidScans so we pick it up next time.
> However, there is a filter that checks for transaction state (JTATransactionLogXAResourceOrphanFilter) which would detect a transaction log and ignore this Xid so adding this protection would only be considered belt-and-braces.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months