-
Bug
-
Resolution: Done
-
Blocker
-
8.0 Update 8
-
None
-
False
-
-
False
-
-
-
-
-
-
-
It seems there is inconsistency in statuses between the operator and server during pod scale-down when there are HEURISTIC transactions. The pod is stuck in SCALING_DOWN_RECOVERY_PROCESSING and user never gets information the pod status is actually SCALING_DOWN_RECOVERY_HEURISTICS which need manual intervention.
While we wait until the pod gets into SCALING_DOWN_RECOVERY_HEURISTICS state there are warnings in the client pod log:
ARJUNA012035: Activate of object with id = 0:0:0:0:0 and type /StateManager/AbstractRecord/XAResourceRecord unexpectedly failed
We see this exception in the client pod log:
Caused by: jakarta.transaction.HeuristicMixedException at org.jboss.jts//com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1301) at org.jboss.jts//com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:128) at org.jboss.jts.integration@6.0.6.Final-redhat-00001//com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:95) at org.wildfly.transaction.client@3.0.5.Final-redhat-00001//org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:78) at org.wildfly.transaction.client@3.0.5.Final-redhat-00001//org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71) at org.jboss.as.ejb3@8.0.10.GA-redhat-00002//org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) ... 113 more Suppressed: javax.transaction.xa.XAException at deployment.tx-client.war//org.jboss.as.quickstarts.xa.resources.MockXAResource.commit(MockXAResource.java:129) at org.jboss.jts//com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) at org.jboss.jts//com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2906) at org.jboss.jts//com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2822) at org.jboss.jts//com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1878) at org.jboss.jts//com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1534) at org.jboss.jts//com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96) at org.jboss.jts//com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at org.jboss.jts//com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1295)
It is probably caused by https://issues.redhat.com/browse/JBEAP-28831.
For 8.1 it is fixed by upgrading the operator to an unreleased version. See https://issues.redhat.com/browse/EAPQE-3232 and MR https://gitlab.cee.redhat.com/jbossqe-eap/openshift-eap-tests/-/merge_requests/1291.
Here we can see failing job https://cp-80x-jenkins.eapqe.psi.redhat.com/job/eap-80x-openshift-4-operator-80-openjdk17/147/.
Logs com.redhat.xpaas.eap.xa.EjbTxnRemotingScaleDownTest.txt
, tx-server-0.log, tx-client-0.log, eap-operator-mdl82.log and eap-operator-58968fc666-tsrmx.log.
- clones
-
-
- Verified
-
- is caused by
-
JBEAP-29806 (8.0.z) Upgrade to Narayana from 6.0.4.Final-redhat-00001 to 6.0.6.Final-redhat-00001
-
- Closed
-
- is incorporated by
-
JBEAP-30343 Release EAP Operator 3.1.6
-
- Closed
-
- is related to
-
-
- Verified
-
