[JBoss JIRA] (WFWIP-206) scale down isn't successful when there are in-doubt transaction on pod
by Martin Simka (Jira)
[ https://issues.jboss.org/browse/WFWIP-206?page=com.atlassian.jira.plugin.... ]
Martin Simka edited comment on WFWIP-206 at 10/1/19 9:46 AM:
-------------------------------------------------------------
update:
* failure in {{testTxStatelessServerSecondCommitThrowRmFail}} -seems to be caused by old EAP image missing some fixes, I'll retest it with fresh image from EAP7-1216- with new image it fails with similar symptoms as {{testTxStatelessClientSecondCommitThrowRmFail}}, so WFWIP-218
* {{testTxStatelessClientSecondCommitThrowRmFail}} fails intermittently, I created WFWIP-218
* {{testTxStatelessServerSecondPrepareJvmHalt}} pending retest
* {{testTxStatelessClientSecondPrepareJvmHalt}} pending retest
was (Author: simkam):
update:
* failure in {{testTxStatelessServerSecondCommitThrowRmFail}} seems to be caused by old EAP image missing some fixes, I'll retest it with fresh image from EAP7-1216
* {{testTxStatelessClientSecondCommitThrowRmFail}} fails intermittently, I created WFWIP-218
* {{testTxStatelessServerSecondPrepareJvmHalt}} pending retest
* {{testTxStatelessClientSecondPrepareJvmHalt}} pending retest
> scale down isn't successful when there are in-doubt transaction on pod
> ----------------------------------------------------------------------
>
> Key: WFWIP-206
> URL: https://issues.jboss.org/browse/WFWIP-206
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: operator, built from [1984d98154f11a7473be065e4ae7f54b1812c9b0|https://github.com/wildfly/wildf...] :
> {noformat}
> docker-registry.engineering.redhat.com/jbossqe-eap/wildfly-operator:latest
> {noformat}
> EAP image:
> {noformat}
> docker-registry.engineering.redhat.com/ochaloup/wildfly18-snapshot:190909...
> {noformat}
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Blocker
> Labels: operator
>
> 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
> 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. But scale down never completes.
> Log from operator:
> {noformat}
> {"level":"info","ts":1568905676.6303623,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905676.7313502,"logger":"controller_wildflyserver","msg":"Enabling recovery listener for processing scaledown at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905679.4325309,"logger":"controller_wildflyserver","msg":"Query to find the transaction recovery port to force scan at pod tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905686.7914035,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"info","ts":1568905702.0583296,"logger":"controller_wildflyserver","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","Message":"Recovery scan to be invoked as the transaction log storage is not empty for pod scaling down pod tx-server-0, transaction list: map[0:ffffac11000a:991c183:5d8399a1:13:map[age-in-seconds:23 id:0:ffffac11000a:991c183:5d8399a1:13 jmx-name:<nil> participants:map[java:/MockXAResource:map[eis-product-name:MockXAResource Test eis-product-version:0.1.Mock jmx-name:<nil> jndi-name:java:/MockXAResource status:PREPARED type:/StateManager/AbstractRecord/XAResourceRecord]] type:StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA]]"}
> {"level":"info","ts":1568905711.1034026,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.103548,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.109706,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.2608829,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Error to get response for command SCAN sending to 172.17.0.10:4712, error: EOF]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.2609518,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2609615,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795022,"logger":"controller_wildflyserver","msg":"Updating StatefulSet to be up to date with the WildFlyServer Spec","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795491,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.2796504,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.2937052,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.294249,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.294342,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.294417,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"error","ts":1568905711.311673,"logger":"controller_wildflyserver","msg":"Failed to Update StatefulSet.","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"error","ts":1568905711.311745,"logger":"kubebuilder.controller","msg":"Reconciler error","controller":"wildflyserver-controller","request":"msimka-namespace/tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3137681,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905712.3139439,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905712.3253288,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905712.3255754,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3256311,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905712.3256419,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-218) server scale down sometimes keeps data in client's data/ejb-xa-recovery
by Martin Simka (Jira)
[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ]
Martin Simka updated WFWIP-218:
-------------------------------
Description:
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
*Scenario 1 - 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 aren't commited.
*Scenario 2 - EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondPrepareJvmHalt*
The tx-server in JVM crashes in XA resource 2 prepare phase. Openshift then restarts server pod but it is immediately scaled down. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client.
{noformat}
/opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{noformat}
was:
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
* Scenario 1 - 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 aren't commited
* Scenario 1 - testTxStatelessServerSecondCommitThrowRmFail*
{noformat}
/opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{noformat}
> server scale down sometimes keeps data in client's data/ejb-xa-recovery
> -----------------------------------------------------------------------
>
> 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: Blocker
>
> 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
> *Scenario 1 - 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 aren't commited.
> *Scenario 2 - EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondPrepareJvmHalt*
> The tx-server in JVM crashes in XA resource 2 prepare phase. Openshift then restarts server pod but it is immediately scaled down. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client.
> {noformat}
> /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-218) server scale down sometimes keeps data in client's data/ejb-xa-recovery
by Martin Simka (Jira)
[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ]
Martin Simka updated WFWIP-218:
-------------------------------
Description:
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
* Scenario 1 - 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 aren't commited
* Scenario 1 - testTxStatelessServerSecondCommitThrowRmFail*
{noformat}
/opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{noformat}
was:
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
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
{noformat}
/opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
{noformat}
> server scale down sometimes keeps data in client's data/ejb-xa-recovery
> -----------------------------------------------------------------------
>
> 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: Blocker
>
> 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
> * Scenario 1 - 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 aren't commited
> * Scenario 1 - testTxStatelessServerSecondCommitThrowRmFail*
> {noformat}
> /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-218) server scale down sometimes keeps data in client's data/ejb-xa-recovery
by Martin Simka (Jira)
[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ]
Martin Simka updated WFWIP-218:
-------------------------------
Steps to Reproduce:
it can be reproduced using test:
{code}
git clone git@gitlab.mw.lab.eng.bos.redhat.com:msimka/openshift-eap-tests.git
cd openshift-eap-tests.git
git checkout EAP7-1192_scaledown
# create file test.properties
mvn clean test -P72 -Dtest=EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondPrepareJvmHalt -Dconsole-log-level=DEBUG
#or
mvn clean test -P72 -Dtest=EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondCommitThrowRmFail -Dconsole-log-level=DEBUG
{code}
test.properties
{code}
xtf.openshift.url=https://master.all-in-one-msimka-002.dynamic.xpaas:8443
xtf.openshift.namespace=wip-namespace
xtf.bm.namespace=wip-builds-namespace
xtf.eap.72.image=docker-registry.upshift.redhat.com/kwills/eap-cd-openshi...
xtf.eap.72.properties.eap.imagestream.name=jboss-eap73-openshift
xtf.eap.72.version=7.2.0.GA
xtf.eap.properties.location=/opt/eap
xtf.eap.72.templates.repo=git://github.com/jboss-container-images/jboss-e...
xtf.eap.72.templates.branch=eap72,v7.3.0.GA
xtf.maven.proxy.url=http://maven.all-in-one-043.dynamic.xpaas/nexus/content/groups/public/
# this might be needed if oc login command fails, see test suite logs
#xtf.openshift.binary.path=/home/msimka/.minishift/cache/oc/v3.11.0/linux/oc
xtf.operator.image=quay.io/ochaloup/wildfly-operator:20190930
xtf.operator.resources.context=
# specify correct path oc binary
xtf.openshift.binary.path=<oc_binary_path>
{code}
was:
it can be reproduced using test:
{code}
git clone git@gitlab.mw.lab.eng.bos.redhat.com:msimka/openshift-eap-tests.git
cd openshift-eap-tests.git
git checkout EAP7-1192_scaledown
# create file test.properties
mvn clean test -P72 -Dtest=EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondPrepareJvmHalt -Dcheckstyle.skip -Dconsole-log-level=DEBUG
{code}
test.properties
{code}
xtf.openshift.url=https://master.all-in-one-msimka-002.dynamic.xpaas:8443
xtf.openshift.namespace=wip-namespace
xtf.bm.namespace=wip-builds-namespace
xtf.eap.72.image=docker-registry.upshift.redhat.com/kwills/eap-cd-openshi...
xtf.eap.72.properties.eap.imagestream.name=jboss-eap73-openshift
xtf.eap.72.version=7.2.0.GA
xtf.eap.properties.location=/opt/eap
xtf.eap.72.templates.repo=git://github.com/jboss-container-images/jboss-e...
xtf.eap.72.templates.branch=eap72,v7.3.0.GA
xtf.maven.proxy.url=http://maven.all-in-one-043.dynamic.xpaas/nexus/content/groups/public/
# this might be needed if oc login command fails, see test suite logs
#xtf.openshift.binary.path=/home/msimka/.minishift/cache/oc/v3.11.0/linux/oc
xtf.operator.image=quay.io/ochaloup/wildfly-operator:20190930
xtf.operator.resources.context=
# specify correct path oc binary
xtf.openshift.binary.path=<oc_binary_path>
{code}
> server scale down sometimes keeps data in client's data/ejb-xa-recovery
> -----------------------------------------------------------------------
>
> 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: Blocker
>
> 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
> 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
> {noformat}
> /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-218) server scale down sometimes keeps data in client's data/ejb-xa-recovery
by Martin Simka (Jira)
[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ]
Martin Simka updated WFWIP-218:
-------------------------------
Steps to Reproduce:
it can be reproduced using test:
{code}
git clone git@gitlab.mw.lab.eng.bos.redhat.com:msimka/openshift-eap-tests.git
cd openshift-eap-tests.git
git checkout EAP7-1192_scaledown
# create file test.properties
mvn clean test -P72 -Dtest=EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondPrepareJvmHalt -Dcheckstyle.skip -Dconsole-log-level=DEBUG
{code}
test.properties
{code}
xtf.openshift.url=https://master.all-in-one-msimka-002.dynamic.xpaas:8443
xtf.openshift.namespace=wip-namespace
xtf.bm.namespace=wip-builds-namespace
xtf.eap.72.image=docker-registry.upshift.redhat.com/kwills/eap-cd-openshi...
xtf.eap.72.properties.eap.imagestream.name=jboss-eap73-openshift
xtf.eap.72.version=7.2.0.GA
xtf.eap.properties.location=/opt/eap
xtf.eap.72.templates.repo=git://github.com/jboss-container-images/jboss-e...
xtf.eap.72.templates.branch=eap72,v7.3.0.GA
xtf.maven.proxy.url=http://maven.all-in-one-043.dynamic.xpaas/nexus/content/groups/public/
# this might be needed if oc login command fails, see test suite logs
#xtf.openshift.binary.path=/home/msimka/.minishift/cache/oc/v3.11.0/linux/oc
xtf.operator.image=quay.io/ochaloup/wildfly-operator:20190930
xtf.operator.resources.context=
# specify correct path oc binary
xtf.openshift.binary.path=<oc_binary_path>
{code}
was:
it can be reproduced using test:
{code}
git clone git@gitlab.mw.lab.eng.bos.redhat.com:msimka/openshift-eap-tests.git
cd openshift-eap-tests.git
git checkout EAP7-1192_scaledown
# create file test.properties
mvn clean test -P72 -Dtest=EjbTxnRemotingScaleDownTest#testTxStatelessServerSecondPrepareJvmHalt -Dcheckstyle.skip -Dconsole-log-level=DEBUG
{code}
test.properties
{code}
xtf.openshift.url=https://master.all-in-one-msimka-002.dynamic.xpaas:8443
xtf.openshift.namespace=wip-namespace
xtf.bm.namespace=wip-builds-namespace
xtf.eap.72.image=docker-registry.engineering.redhat.com/msimka/eap-cd-ope...
xtf.eap.72.properties.eap.imagestream.name=jboss-eap73-openshift
xtf.eap.72.version=7.2.0.GA
xtf.eap.properties.location=/opt/eap
xtf.eap.72.templates.repo=git://github.com/jboss-container-images/jboss-e...
xtf.eap.72.templates.branch=eap72,v7.3.0.GA
xtf.maven.proxy.url=http://maven.all-in-one-043.dynamic.xpaas/nexus/content/groups/public/
# this might be needed if oc login command fails, see test suite logs
#xtf.openshift.binary.path=/home/msimka/.minishift/cache/oc/v3.11.0/linux/oc
xtf.operator.image=quay.io/ochaloup/wildfly-operator:20190930
xtf.operator.resources.context=
# specify correct path oc binary
xtf.openshift.binary.path=<oc_binary_path>
{code}
> server scale down sometimes keeps data in client's data/ejb-xa-recovery
> -----------------------------------------------------------------------
>
> 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: Blocker
>
> 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
> 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
> {noformat}
> /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (DROOLS-4518) Implement UX styles for Test Coverage Report
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4518?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-4518:
-------------------------------------
Priority: Major (was: Minor)
> Implement UX styles for Test Coverage Report
> --------------------------------------------
>
> Key: DROOLS-4518
> URL: https://issues.jboss.org/browse/DROOLS-4518
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2019-09-10 at 9.35.23 AM.png, Screen Shot 2019-09-10 at 9.37.02 AM.png, Screenshot from 2019-09-10 17-52-00.png, Screenshot from 2019-09-20 12-30-01.png, Screenshot from 2019-09-20 16-05-04.png, Screenshot from 2019-09-20 16-10-22.png, screenshot-1.png
>
>
> The implemented styles for the Test Coverage Report panel do not align with the HTML/CSS provided in jira https://issues.jboss.org/browse/DROOLS-3741.
> The styles used in the current implementation might present usability concerns - the Decision/Scenario list type size is very small and could pose a readability issue. The layout and alignment of the test summary data is difficult to scan, due to the gutter alignment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (DROOLS-4518) Implement UX styles for Test Coverage Report
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4518?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-4518:
-------------------------------------
Sprint: (was: 2019 Week 38-40 (from Sep 16))
> Implement UX styles for Test Coverage Report
> --------------------------------------------
>
> Key: DROOLS-4518
> URL: https://issues.jboss.org/browse/DROOLS-4518
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Yeser Amer
> Priority: Minor
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2019-09-10 at 9.35.23 AM.png, Screen Shot 2019-09-10 at 9.37.02 AM.png, Screenshot from 2019-09-10 17-52-00.png, Screenshot from 2019-09-20 12-30-01.png, Screenshot from 2019-09-20 16-05-04.png, Screenshot from 2019-09-20 16-10-22.png, screenshot-1.png
>
>
> The implemented styles for the Test Coverage Report panel do not align with the HTML/CSS provided in jira https://issues.jboss.org/browse/DROOLS-3741.
> The styles used in the current implementation might present usability concerns - the Decision/Scenario list type size is very small and could pose a readability issue. The layout and alignment of the test summary data is difficult to scan, due to the gutter alignment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months