[
https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin....
]
Ondrej Chaloupka edited comment on WFWIP-218 at 11/29/19 10:12 AM:
-------------------------------------------------------------------
Just mentioning that I started to investigate on this. I agree with [~tomekadamski] that
the WFTC-75 seems to be fixing the WFTC-77 as well.
I created the reproducer
https://gitlab.mw.lab.eng.bos.redhat.com/ochaloup/tests-transactions/comm...
that does the same (or I assume it does the same) as the test in the eap qe openshift
testsuite. On debugging and testing all works fine.
But! The strange thing is that this issue WFWIP-218 is reproducible with the test
{{EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondCommitThrowRmFail}} and the scale
down does clean the WFTC folder - the commit happens during the recovery, the Narayana
object store is clean but the WFTC folder is not empty.
I will be running more investigation on this.
For sake of completeness I run this
{code}
mvn clean test -Pcd
-Dtest=EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondCommitThrowRmFail
-Dconsole-log-level=DEBUG -Poperator
{code}
on local CRC instance (
http://pastebin.test.redhat.com/815593) with {{test.properties}}
{code}
xtf.openshift.namespace=ochaloup-namespace
xtf.bm.namespace=ochaloup-builds-namespace
# this is the url of CRC, try `crc ip`
xtf.openshift.url=https://192.168.130.11:6443
xtf.eap.properties.location=/opt/eap
xtf.openshift.binary.path=/home/ochaloup/.crc/bin/oc
# operator built by Jeff and published
xtf.operator.wildfly.image=docker-registry.engineering.redhat.com/jbossqe...
# for the latest EAP image to take
xtf.eap.cd.image=registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-...
xtf.eap.cd.properties.eap.runtime.image=registry-proxy.engineering.redhat...
xtf.waiting.timeout=600000
test.script.debug=true
# needed for yaml not being downloaded from quay repo or what
xtf.operator.eap.resources.context=
{code}
was (Author: ochaloup):
Just mentioning that I started to investigate on this. I agree with [~tomekadamski] that
the WFTC-75 seems to be fixing the WFTC-77 as well.
I created the reproducer
https://gitlab.mw.lab.eng.bos.redhat.com/ochaloup/tests-transactions/comm...
that does the same (or I assume it does the same) as the test in the eap qe openshift
testsuite. On debugging and testing all works fine.
But! The strange thing is that this issue WFWIP-218 is reproducible with the test
`EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondCommitThrowRmFail` and the scale
down does clean the WFTC folder - the commit happens during the recovery, the Narayana
object store is clean but the WFTC folder is not empty.
I will be running more investigation on this.
For sake of completeness I run this
{code}
mvn clean test -Pcd
-Dtest=EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondCommitThrowRmFail
-Dconsole-log-level=DEBUG -Poperator
{code}
on local CRC instance (
http://pastebin.test.redhat.com/815593) with {{test.properties}}
{code}
xtf.openshift.namespace=ochaloup-namespace
xtf.bm.namespace=ochaloup-builds-namespace
# this is the url of CRC, try `crc ip`
xtf.openshift.url=https://192.168.130.11:6443
xtf.eap.properties.location=/opt/eap
xtf.openshift.binary.path=/home/ochaloup/.crc/bin/oc
# operator built by Jeff and published
xtf.operator.wildfly.image=docker-registry.engineering.redhat.com/jbossqe...
# for the latest EAP image to take
xtf.eap.cd.image=registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-...
xtf.eap.cd.properties.eap.runtime.image=registry-proxy.engineering.redhat...
xtf.waiting.timeout=600000
test.script.debug=true
# needed for yaml not being downloaded from quay repo or what
xtf.operator.eap.resources.context=
{code}
server scale down keeps data in client's data/ejb-xa-recovery and
transactions on client aren't commited
--------------------------------------------------------------------------------------------------------
Key: WFWIP-218
URL:
https://issues.jboss.org/browse/WFWIP-218
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Martin Simka
Assignee: Ondrej Chaloupka
Priority: Major
this follows up on WFWIP-206
While testing tx recovery in OpenShift I see that scale down of pod that has transaction
in-doubt on it isn't successful
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
*testTxStatelessServerSecondCommitThrowRmFail*
ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}}
Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down
completes but sometimes there some records left in
{{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on
client aren't commited.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)