[JBoss JIRA] (JBTM-2832) Blacktie TestTPGetRely::test_tpgetrply_with_TPGETANY fail
by Amos Feng (JIRA)
Amos Feng created JBTM-2832:
-------------------------------
Summary: Blacktie TestTPGetRely::test_tpgetrply_with_TPGETANY fail
Key: JBTM-2832
URL: https://issues.jboss.org/browse/JBTM-2832
Project: JBoss Transaction Manager
Issue Type: Bug
Components: BlackTie
Reporter: Amos Feng
Assignee: Amos Feng
Priority: Minor
[exec] 1) test: TestTPGetRply::test_tpgetrply_with_TPGETANY (F) line: 272 C:\hudson\workspace\narayana-catelyn\blacktie\xatmi\src\test\cpp\TestTPGetRply.cxx
[exec] assertion failed
[exec] - Expression: _w12pq_u
[exec]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (JBTM-2825) JTA XAResourceRecord does not record the type of heuristic
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2825?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2825:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> JTA XAResourceRecord does not record the type of heuristic
> ----------------------------------------------------------
>
> Key: JBTM-2825
> URL: https://issues.jboss.org/browse/JBTM-2825
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA
> Affects Versions: 5.5.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> When a JTA XAResource receives a heuristic outcome during commit it does not record the type of heuristic. This information is required by the tooling in order to determine whether it is worthwhile reattempting the commit (for mixed and hazard heuristics it is worthwhile).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[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 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, 11 months
[JBoss JIRA] (JBTM-2830) Consider possible compensations framework architecture improvements
by Gytis Trikleris (JIRA)
Gytis Trikleris created JBTM-2830:
-------------------------------------
Summary: Consider possible compensations framework architecture improvements
Key: JBTM-2830
URL: https://issues.jboss.org/browse/JBTM-2830
Project: JBoss Transaction Manager
Issue Type: Task
Components: Compensations
Reporter: Gytis Trikleris
Assignee: Tom Jenkinson
I've created a document with a list of possible compensations framework improvements. I'm attaching a link to the google doc for you to review and schedule work once appropriate.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 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://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)
7 years, 11 months