[JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration
by Gytis Trikleris (JIRA)
Gytis Trikleris created JBTM-2831:
-------------------------------------
Summary: 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: Gytis Trikleris
Fix For: 5.next
Inbound bridge participant …
[View More]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)
[View Less]
8 years, 9 months
[JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2725:
-----------------------------------
Did anyone bother checking the history of the code to determine why we threw the rollback exception? It wasn't always the case and changing it without understanding the reasons is risky.
> Race condition in ControlWrapper
> --------------------------------
>
> Key: JBTM-2725
> URL: https://…
[View More]issues.jboss.org/browse/JBTM-2725
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.3.3.Final
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Fix For: 5.3.5.Final
>
>
> I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
8 years, 9 months