[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)
4 years, 9 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)
4 years, 9 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)
4 years, 9 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)
4 years, 9 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)
4 years, 9 months
[JBoss JIRA] (DROOLS-4589) Refactor of Scorecards
by Lance Leverich (Jira)
[ https://issues.jboss.org/browse/DROOLS-4589?page=com.atlassian.jira.plugi... ]
Lance Leverich updated DROOLS-4589:
-----------------------------------
Sprint: 2019 Week 38-40 (from Sep 16)
> Refactor of Scorecards
> ----------------------
>
> Key: DROOLS-4589
> URL: https://issues.jboss.org/browse/DROOLS-4589
> Project: Drools
> Issue Type: Task
> Components: PMML
> Reporter: Lance Leverich
> Assignee: Lance Leverich
> Priority: Major
> Labels: CustomerFocusTeam
>
> Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be...
> * Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data
> * Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete.
> * Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format
> * Scorecard models are applied via a service interface
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (DROOLS-4589) Refactor of Scorecards
by Lance Leverich (Jira)
[ https://issues.jboss.org/browse/DROOLS-4589?page=com.atlassian.jira.plugi... ]
Lance Leverich updated DROOLS-4589:
-----------------------------------
Sprint: (was: 2019 Week 38-40 (from Sep 16))
> Refactor of Scorecards
> ----------------------
>
> Key: DROOLS-4589
> URL: https://issues.jboss.org/browse/DROOLS-4589
> Project: Drools
> Issue Type: Task
> Components: PMML
> Reporter: Lance Leverich
> Assignee: Lance Leverich
> Priority: Major
> Labels: CustomerFocusTeam
>
> Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be...
> * Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data
> * Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete.
> * Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format
> * Scorecard models are applied via a service interface
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (DROOLS-4594) PMML Scorecard Pipeline - Model Applier
by Lance Leverich (Jira)
Lance Leverich created DROOLS-4594:
--------------------------------------
Summary: PMML Scorecard Pipeline - Model Applier
Key: DROOLS-4594
URL: https://issues.jboss.org/browse/DROOLS-4594
Project: Drools
Issue Type: Sub-task
Components: PMML
Reporter: Lance Leverich
Assignee: Lance Leverich
Create the class that is the actual "pipeline" for applying a Scorecard model. This class will, at a minimum, do the following:
* Create and call the initializer object
* Create and/or transform input objects into the necessary domain objects
* Create and call the resolver object
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months