[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Tom Jenkinson created pull request #1059 in GitHub
--------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> EIS can't recover transaction when heuristic outcome happens
> ------------------------------------------------------------
>
> Key: JBTM-2734
> URL: https://issues.jboss.org/browse/JBTM-2734
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.next
>
>
> For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way
> # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB.
> # transaction is marked to have heuristic result and manual intervention is necessary
> # user calls {{recover}} for participant at such state and its state is changed to _prepared_
> # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store
> This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be
> # EIS propagates EIS TX to Narayana
> # enlisting XAR in Narayana subordinate TX
> # committing EIS TX
> ## It commits Narayana subordinate TX
> # XAR in Narayana TX returns RMERR
> # Narayana returns XA_HEURMIX
> # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared
> # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet
> # EIS should call Narayana via XATerminator::recover()
> ## getting back an Xid that matches to Narayana subordinate TX
> # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid)
> (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_)
> The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2741) No error message on concurrent processing of the same inflow transaction
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2741:
----------------------------------
Summary: No error message on concurrent processing of the same inflow transaction (was: Losing message during inflow transaction processing)
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBTM-2741
> URL: https://issues.jboss.org/browse/JBTM-2741
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA, JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2734:
-------------------------------------
You are not calling XATerminator::recover() - this will reinitialize the Subordinate Transactions. However - I do believe there is still a bug in Narayana in that we should be removing the reference to the transaction when we see the Heuristic.
i.e above:
https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
add:
https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
If you can change your test to call XATerminator::recover() before retrying the commits I will test my patch here.
Many thanks!
> EIS can't recover transaction when heuristic outcome happens
> ------------------------------------------------------------
>
> Key: JBTM-2734
> URL: https://issues.jboss.org/browse/JBTM-2734
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.next
>
>
> For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way
> # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB.
> # transaction is marked to have heuristic result and manual intervention is necessary
> # user calls {{recover}} for participant at such state and its state is changed to _prepared_
> # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store
> This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be
> # EIS propagates EIS TX to Narayana
> # enlisting XAR in Narayana subordinate TX
> # committing EIS TX
> ## It commits Narayana subordinate TX
> # XAR in Narayana TX returns RMERR
> # Narayana returns XA_HEURMIX
> # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared
> # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet
> # EIS should call Narayana via XATerminator::recover()
> ## getting back an Xid that matches to Narayana subordinate TX
> # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid)
> (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_)
> The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski updated JBTM-2725:
---------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.next
Resolution: Done
> 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.next
>
>
> 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
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2742) XTS and HA-Cluster compatibility
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/JBTM-2742?page=com.atlassian.jira.plugin.... ]
Johnathon Lee updated JBTM-2742:
--------------------------------
Summary: XTS and HA-Cluster compatibility (was: XTS and HA-Cluster combatibility)
> XTS and HA-Cluster compatibility
> --------------------------------
>
> Key: JBTM-2742
> URL: https://issues.jboss.org/browse/JBTM-2742
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: XTS
> Reporter: Johnathon Lee
>
> The request here would be to enable compatibility between the XTS subsystem and a clustered EAP deployment.
> Currently, the XTS subsystem is not compatible in a clustered EAP deployment.
> For this configuration to work, the clustered environment cluster traffic routing layer would need to be transactionally aware, such that routing could be based upon a transaction id (txid) rather than session information. Alternatively, the XTS subsystem would need to be adapted to preserve the transport (http) layer's session cookie information and the session cookie information be passed or persisted whenever the coordinator/participant url is used (which has potential specification level issues).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2742) XTS and HA-Cluster combatibility
by Jonathan Halliday (JIRA)
[ https://issues.jboss.org/browse/JBTM-2742?page=com.atlassian.jira.plugin.... ]
Jonathan Halliday updated JBTM-2742:
------------------------------------
Component/s: XTS
(was: JTA)
(was: JTS)
> XTS and HA-Cluster combatibility
> --------------------------------
>
> Key: JBTM-2742
> URL: https://issues.jboss.org/browse/JBTM-2742
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: XTS
> Reporter: Johnathon Lee
>
> The request here would be to enable compatibility between the XTS subsystem and a clustered EAP deployment.
> Currently, the XTS subsystem is not compatible in a clustered EAP deployment.
> For this configuration to work, the clustered environment cluster traffic routing layer would need to be transactionally aware, such that routing could be based upon a transaction id (txid) rather than session information. Alternatively, the XTS subsystem would need to be adapted to preserve the transport (http) layer's session cookie information and the session cookie information be passed or persisted whenever the coordinator/participant url is used (which has potential specification level issues).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2742) XTS and HA-Cluster combatibility
by Johnathon Lee (JIRA)
Johnathon Lee created JBTM-2742:
-----------------------------------
Summary: XTS and HA-Cluster combatibility
Key: JBTM-2742
URL: https://issues.jboss.org/browse/JBTM-2742
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: JTA, JTS
Reporter: Johnathon Lee
The request here would be to enable compatibility between the XTS subsystem and a clustered EAP deployment.
Currently, the XTS subsystem is not compatible in a clustered EAP deployment.
For this configuration to work, the clustered environment cluster traffic routing layer would need to be transactionally aware, such that routing could be based upon a transaction id (txid) rather than session information. Alternatively, the XTS subsystem would need to be adapted to preserve the transport (http) layer's session cookie information and the session cookie information be passed or persisted whenever the coordinator/participant url is used (which has potential specification level issues).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka edited comment on JBTM-2741 at 8/24/16 9:48 AM:
----------------------------------------------------------------
Log attached. My observation of this could be trouble at Narayana side came from comment here
https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
but I have to admit that I haven't tried to debug it to this level. Give me some time to check how jca logging output looks. I'll be back soon (I hope :) )
was (Author: ochaloup):
Log attached. My observation of this could be trouble at Narayana side came from comment here
https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
but I have to admit that I haven't tried to debug it to this level. Give me some time to check how jca logging output looks. I'll be back soon (I hope :)
> Losing message during inflow transaction processing
> ---------------------------------------------------
>
> Key: JBTM-2741
> URL: https://issues.jboss.org/browse/JBTM-2741
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA, JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on JBTM-2741:
---------------------------------------
Log attached. My observation of this could be trouble at Narayana side came from comment here
https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
but I have to admit that I haven't tried to debug it to this level. Give me some time to check how jca logging output looks. I'll be back soon (I hope :)
> Losing message during inflow transaction processing
> ---------------------------------------------------
>
> Key: JBTM-2741
> URL: https://issues.jboss.org/browse/JBTM-2741
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA, JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2741:
----------------------------------
Attachment: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
> Losing message during inflow transaction processing
> ---------------------------------------------------
>
> Key: JBTM-2741
> URL: https://issues.jboss.org/browse/JBTM-2741
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JCA, JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months