-
Bug
-
Resolution: Done
-
Blocker
-
None
-
image:
docker-registry.engineering.redhat.com/ochaloup/wildfly18-snapshot:190909-d4ddf04cc2-wfcore-10.0.0.Beta7-SNAPSHOT
operator:
docker-registry.engineering.redhat.com/jbossqe-eap/wildfly-operator:EAP7-1192-txn-recovery-issue70
operator built from https://github.com/ochaloup/wildfly-operator/tree/issue70-statefulset-headless-service, head 8925e7f64b6fc02b4694da63d93c0a8ce03a566d)
image: docker-registry.engineering.redhat.com/ochaloup/wildfly18-snapshot:190909-d4ddf04cc2-wfcore-10.0.0.Beta7-SNAPSHOT operator: docker-registry.engineering.redhat.com/jbossqe-eap/wildfly-operator:EAP7-1192-txn-recovery-issue70 operator built from https://github.com/ochaloup/wildfly-operator/tree/issue70-statefulset-headless-service , head 8925e7f64b6fc02b4694da63d93c0a8ce03a566d)
-
-
High
While testing tx recovery in OpenShift I see that recovery after JVM crash intermittently fails
Scenario:
ejb client (app tx-client, pod tx-client-0):
- EJB business method
- lookup remote EJB
- enlist XA resource 1 to transaction
- enlist XA resource 2 to transaction
- call remote EJB
ejb server (app tx-server, pod tx-server-0):
- EJB business method
- enlist XA resource 1 to transaction
- enlist XA resource 2 to transaction
ejb server XA resource 2 crashes JVM in commit method phase.
Test waits until crashed pod is restarted, then forces periodic recovery twice and then checks that transaction log store is empty. But it is not empty.
Attached are logs from client and server pods.
It seems that it can be partially mitigated by clearing openshift namespace before test (oc delete all --all). But it makes it just less frequent.