[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited
by Ondrej Chaloupka (Jira)
[ 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)
4 years, 4 months
[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka commented on WFWIP-218:
----------------------------------------
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)
4 years, 4 months
[JBoss JIRA] (WFCORE-4765) Remove licenses for artifacts that are not in the distribution
by Jeff Mesnil (Jira)
Jeff Mesnil created WFCORE-4765:
-----------------------------------
Summary: Remove licenses for artifacts that are not in the distribution
Key: WFCORE-4765
URL: https://issues.jboss.org/browse/WFCORE-4765
Project: WildFly Core
Issue Type: Bug
Components: Build System
Affects Versions: 11.0.0.Beta3
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
The following artifacts are not in the WildFly distribution and can be excluded from the wildfly-core feature-packs:
* org.wildfly.core:wildfly-core-model-test-framework
* Artifacts with group id org.wildfly.galleon-plugins
* org.wildfly.security:wildfly-elytron
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-4724:
-------------------------------------
[~manstis] [~tari_manga] hello, I created very simple DMN model [^m.dmn] where the context enrtry literal expression was added automatically after first close and reopen, however still getting validation error, is it expected?
!Screenshot from 2019-11-29 12-04-18.png|thumbnail!
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-11-29 12-04-18.png, error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, m.dmn, save-context.webm, screenshot-1.png, screenshot-2.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (?)
> - BKM node (?)
> - Cleared Function (?)
> - Context entry (?) [^error.log] [^save-context.webm]
> - Invocation (?)
> h3. Kogito
> - Decision node (?)
> - BKM node (?)
> - Cleared Function (?)
> - Context entry (?)
> - Invocation (?)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4724:
--------------------------------
Attachment: m.dmn
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-11-29 12-04-18.png, error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, m.dmn, save-context.webm, screenshot-1.png, screenshot-2.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (?)
> - BKM node (?)
> - Cleared Function (?)
> - Context entry (?) [^error.log] [^save-context.webm]
> - Invocation (?)
> h3. Kogito
> - Decision node (?)
> - BKM node (?)
> - Cleared Function (?)
> - Context entry (?)
> - Invocation (?)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4724:
--------------------------------
Attachment: Screenshot from 2019-11-29 12-04-18.png
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-11-29 12-04-18.png, error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, m.dmn, save-context.webm, screenshot-1.png, screenshot-2.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (?)
> - BKM node (?)
> - Cleared Function (?)
> - Context entry (?) [^error.log] [^save-context.webm]
> - Invocation (?)
> h3. Kogito
> - Decision node (?)
> - BKM node (?)
> - Cleared Function (?)
> - Context entry (?)
> - Invocation (?)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months