-
15. Re: XTS inbound bridge fails to commit during crash recovery
tomjenkinson I shared the diagram resource with you (google drive, draw.io)
The reason for putting the resource to heuristics at CLIENT is that WFTC returns XAException.XAER_RMFAIL on IOException (wildfly-transaction-client/TransactionClientChannel.java at 1.1 · wildfly/wildfly-transaction-client · GitHub ) which is transformed to heuristics (narayana/XAResourceRecord.java at 00fe8614eebb63da80119e8513a612e711a666a7 · jbosstm/narayana · GitHub ). The behaviour is documented here [JBTM-2443] Raise a JTA HeuristicMixed if a one phase commit XAResource raises RMFAIL - JBoss Issue Tracker
I consider the behaviour with the heuristics correct. It does not harm consistency. It requires an action to be done from administrator. But with 1PC I don't know if there is some other chance. You never know what happens during commit failure. It could be the XAResource was committed and then error happens or in opposite it was not committed and then the error happens.
What I consider as an issue is behaviour when JVM is not crashed and but error (XAER_RMFAIL) happens. I need to investigate a bit for being able to explain the behaviour.
-
16. Re: XTS inbound bridge fails to commit during crash recovery
ochaloup wrote:
Thanks Tom, I have two findings from my investigation.
Let's summarize the scenario I work with. It's basically the same either for JTA-ejb-remoting or WS-txbridge. There is a client which makes a remote call to the second server. The transaction context is propagated along the call. The second server runs the subordinate transaction where two XAResources are in use. As the client knows only one resource it goes with 1PC. The second server runs the 2PC as there is two XAResources available. A failure happens during commit is called on one of the XAResources at the second server.
I assume that this is a bug in the ejb remoting layer since the narayana JTS implementation does not make this optimisation when enlisting subordinates.
I didn't look in detail but is the test SimpleIsolatedServers#testOnePhaseSubordinateOrphan at all related to this issue?
-
17. Re: XTS inbound bridge fails to commit during crash recovery
mmusgrov wrote:
ochaloup wrote:
Thanks Tom, I have two findings from my investigation.
Let's summarize the scenario I work with. It's basically the same either for JTA-ejb-remoting or WS-txbridge. There is a client which makes a remote call to the second server. The transaction context is propagated along the call. The second server runs the subordinate transaction where two XAResources are in use. As the client knows only one resource it goes with 1PC. The second server runs the 2PC as there is two XAResources available. A failure happens during commit is called on one of the XAResources at the second server.
I assume that this is a bug in the ejb remoting layer since the narayana JTS implementation does not make this optimisation when enlisting subordinates.
I didn't look in detail but is the test SimpleIsolatedServers#testOnePhaseSubordinateOrphan at all related to this issue?
IIRC these EJB remoting resources look like raw XAResources to Narayana, perhaps EJB should be registering a (new) interface rather than XAResource so we can differentiate it - e.g. something like 2PCOnlyXAResource extends XAResource - and as such Narayana could prevent the 1PC?
-
18. Re: XTS inbound bridge fails to commit during crash recovery
mmusgrov thanks for pointing this about JTS. I need to check the behaviour in details.
For EJB remoting it's as tomjenkinson said. The EJB remote resource is understood as standard XAResource. I had two approaches for solving the EJB remoting 1PC issue in my mind.
* not permitting the 1PC for transaction which contains only the EJB remote resource. It's what I was thinking for XTS at [JBTM-3138] XTS txbridge does not run commit during recovery when 1PC is used by ochaloup · Pull Request #1391 · jbosstm… . Using the marker interface 2PCOnlyXAResource is a good point how to obtain information to if 1PC is possible for XAResourceRecord.
* consider the existence of 1PC beneficial and using the heuristic outcome in case of a failure. It's the current behaviour when JVM crashes (that's the behaviour I depicted on diagram at ). Then there is an issue in case of a XAResource failure and not a JVM crash. The correct error code would need to be passed back to the client server.
Up to now I considered the 1PC as beneficial for EJB remoting transactions and I thought that heuristic outcome is a price (in way of a trade-off) to enable it. I started to experiment with it and started to work on a fix for the issue mentioned (correct the error code returned to the client server).
tomjenkinson mmusgrov do you think the remote EJB transactions should not provide 1PC at all? Or could be the heuristic outcome considered as a correct processing for the 1PC capability?
-
19. Re: XTS inbound bridge fails to commit during crash recovery
There were reported two issues on Narayana which are based on the discussion in this thread