[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13897:
---------------------------------------
There seem to be couple of problems at play here:
1. The graceful shutdown doesn't work because the client doesn't authenticate, because there is no such configuration - Jira TBA.
2. When graceful shutdown doesn't success, PID is not obtained on JDK8 – also caused by ISPN-12366.
3. When PID is obtained on JDK11, the kill command is incorrect.
4. If that is fixed - the kill command only kills the parent process and not the child process.
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13897:
---------------------------------------
There are other processes leaking as well, I see after running the suite:
{noformat}
51983 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
52246 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
52953 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
53280 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
53924 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
54540 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
54937 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
55246 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
55874 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
73893 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
74090 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
74345 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
77211 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
77571 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
78067 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
78473 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
83664 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
84044 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
84562 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
85278 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
86133 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
87041 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
96331 s002 S 0:00.00 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
96494 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
96731 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
96924 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
97239 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
97656 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
97932 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
98136 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
98458 s002 S 0:00.01 tail -f /Users/rhusar/git/wildfly/testsuite/integration/clustering/target/infinispan-server-11.0.3.Final/server/log/server.log
{noformat}
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5682) Forall with empty list constraint combined with or does not fire as expected
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5682?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5682:
--------------------------------
Sprint: 2020 Week 40-42 (from Sep 28)
> Forall with empty list constraint combined with or does not fire as expected
> ----------------------------------------------------------------------------
>
> Key: DROOLS-5682
> URL: https://issues.redhat.com/browse/DROOLS-5682
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.32.0.Final, 7.33.0.Final, 7.34.0.Final, 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final, 7.41.0.Final, 7.42.0.Final, 7.43.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: forall-with-empty-list-constraint-combined-with-or.zip
>
>
> As of Drools {{7.32.0.Final}}, {{forall}} patterns with "empty list" constraints combined with other constraints through {{||}} will fail to match as expected.
> For example the following rule:
> {noformat}
> rule "forall with not equal"
> when forall($p : Pojo(y == 1)
> Pojo(x.empty || x contains 2, z == 3, this == $p))
> then
> end
> {noformat}
> will not fire against following facts:
> {noformat}
> Pojo{x=[2], y=0, z=0}
> Pojo{x=[], y=1, z=3}
> Pojo{x=[3], y=0, z=3}
> Pojo{x=[2], y=1, z=3}
> {noformat}
> We suspect a problem with the rewriting of the {{forall}} clause. It appears the clause is rewritten as:
> {{not Pojo(y == 1, (x.empty && !(x contains 2)) || !(z == 3))}}
> instead of the expected:
> {{not Pojo(y == 1, (!(x.empty) && !(x contains 2)) || !(z == 3))}}
> This is working fine when using Drools {{<= 7.31.0.Final}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5681) ByteArrayResource bytes attribute read/write twice
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5681?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5681:
--------------------------------
Sprint: 2020 Week 40-42 (from Sep 28)
> ByteArrayResource bytes attribute read/write twice
> --------------------------------------------------
>
> Key: DROOLS-5681
> URL: https://issues.redhat.com/browse/DROOLS-5681
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Sylvain Lemoine
> Assignee: Mario Fusco
> Priority: Major
>
> When using Java standard serialization mechanism, we can see that ByteArrayResource is now written twice
> in ByteArrayResource
> {code:java}
> @Override
> public void writeExternal(ObjectOutput out) throws IOException {
> super.writeExternal( out );
> out.writeObject( bytes );
> out.writeObject(this.encoding);
> }{code}
> And super class writeExternal:
> {code:java}
> public void writeExternal(ObjectOutput out) throws IOException {
> //...
> out.writeObject( bytes );
> }{code}
> It works as it also read twice in ByteArrayResource#readExternal and ByteArrayResource#readExternal.
> Anyway, moving the bytes attribute from child class to super class in [bb5e421df|https://github.com/kiegroup/drools/commit/bb5e421df8950cb23... broke our project serialization as we rely on java serialization for our KieBase resources. Seems ok as we'll address it by some tweaking on serialVersionUID, but fixing this issue (read/write once instead of twice) will also break deserialization for projects which rely on it from 7.34.0.Final.
> Don't know if it's ok to fix it in the next version. I can make a PR for this case.
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFLY-13915) JAXRS Client Quickstart arquilian tests missing commons-logging
by Eduardo Martins (Jira)
Eduardo Martins created WFLY-13915:
--------------------------------------
Summary: JAXRS Client Quickstart arquilian tests missing commons-logging
Key: WFLY-13915
URL: https://issues.redhat.com/browse/WFLY-13915
Project: WildFly
Issue Type: Bug
Components: Quickstarts
Affects Versions: 20.0.1.Final
Reporter: Eduardo Martins
Assignee: Eduardo Martins
There are errors when running arquillian tests in JAXRS Client quickstart, due to missing dependency on Apache Commons Logging:
{code}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 1.853 s <<< FAILURE! - in org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT
[ERROR] requestResponseFiltersTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.186 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.requestResponseFiltersTest(ContactsRestClientIT.java:218)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.requestResponseFiltersTest(ContactsRestClientIT.java:218)
[ERROR] delayedInvocationTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.014 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.delayedInvocationTest(ContactsRestClientIT.java:183)
[ERROR] asyncCrudTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.014 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.asyncCrudTest(ContactsRestClientIT.java:118)
[ERROR] invocationCallBackTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.015 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.invocationCallBackTest(ContactsRestClientIT.java:151)
[ERROR] cruedTest(org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT) Time elapsed: 0.013 s <<< ERROR!
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.jboss.as.quickstarts.jaxrsclient.test.ContactsRestClientIT.cruedTest(ContactsRestClientIT.java:79)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5682) Forall with empty list constraint combined with or does not fire as expected
by Matteo Casalino (Jira)
[ https://issues.redhat.com/browse/DROOLS-5682?page=com.atlassian.jira.plug... ]
Matteo Casalino updated DROOLS-5682:
------------------------------------
Description:
As of Drools {{7.32.0.Final}}, {{forall}} patterns with "empty list" constraints combined with other constraints through {{||}} will fail to match as expected.
For example the following rule:
{noformat}
rule "forall with not equal"
when forall($p : Pojo(y == 1)
Pojo(x.empty || x contains 2, z == 3, this == $p))
then
end
{noformat}
will not fire against following facts:
{noformat}
Pojo{x=[2], y=0, z=0}
Pojo{x=[], y=1, z=3}
Pojo{x=[3], y=0, z=3}
Pojo{x=[2], y=1, z=3}
{noformat}
We suspect a problem with the rewriting of the {{forall}} clause. It appears the clause is rewritten as:
{{not Pojo(y == 1, (x.empty && !(x contains 2)) || !(z == 3))}}
instead of the expected:
{{not Pojo(y == 1, (!(x.empty) && !(x contains 2)) || !(z == 3))}}
This is working fine when using Drools {{<= 7.31.0.Final}}.
was:
As of Drools 7.32.0.Final, {{forall}} patterns with "empty list" constraints combined with other constraints through {{or}} will fail to match as expected.
For example the following rule:
{noformat}
rule "forall with not equal"
when forall($p : Pojo(y == 1)
Pojo(x.empty || x contains 2, z == 3, this == $p))
then
end
{noformat}
will not fire against following facts:
{noformat}
Pojo{x=[2], y=0, z=0}
Pojo{x=[], y=1, z=3}
Pojo{x=[3], y=0, z=3}
Pojo{x=[2], y=1, z=3}
{noformat}
We suspect a problem with the rewriting of the {{forall}} clause. It appears the clause is rewritten as:
{{not Pojo(y == 1, (x.empty && !(x contains 2)) || !(z == 3))}}
instead of the expected:
{{not Pojo(y == 1, (!(x.empty) && !(x contains 2)) || !(z == 3))}}
This is working fine when using Drools {{<= 7.31.0.Final}}.
> Forall with empty list constraint combined with or does not fire as expected
> ----------------------------------------------------------------------------
>
> Key: DROOLS-5682
> URL: https://issues.redhat.com/browse/DROOLS-5682
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.32.0.Final, 7.33.0.Final, 7.34.0.Final, 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final, 7.41.0.Final, 7.42.0.Final, 7.43.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: forall-with-empty-list-constraint-combined-with-or.zip
>
>
> As of Drools {{7.32.0.Final}}, {{forall}} patterns with "empty list" constraints combined with other constraints through {{||}} will fail to match as expected.
> For example the following rule:
> {noformat}
> rule "forall with not equal"
> when forall($p : Pojo(y == 1)
> Pojo(x.empty || x contains 2, z == 3, this == $p))
> then
> end
> {noformat}
> will not fire against following facts:
> {noformat}
> Pojo{x=[2], y=0, z=0}
> Pojo{x=[], y=1, z=3}
> Pojo{x=[3], y=0, z=3}
> Pojo{x=[2], y=1, z=3}
> {noformat}
> We suspect a problem with the rewriting of the {{forall}} clause. It appears the clause is rewritten as:
> {{not Pojo(y == 1, (x.empty && !(x contains 2)) || !(z == 3))}}
> instead of the expected:
> {{not Pojo(y == 1, (!(x.empty) && !(x contains 2)) || !(z == 3))}}
> This is working fine when using Drools {{<= 7.31.0.Final}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5682) Forall with empty list constraint combined with or does not fire as expected
by Matteo Casalino (Jira)
Matteo Casalino created DROOLS-5682:
---------------------------------------
Summary: Forall with empty list constraint combined with or does not fire as expected
Key: DROOLS-5682
URL: https://issues.redhat.com/browse/DROOLS-5682
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.43.0.Final, 7.42.0.Final, 7.41.0.Final, 7.40.0.Final, 7.39.0.Final, 7.38.0.Final, 7.37.0.Final, 7.36.0.Final, 7.35.0.Final, 7.34.0.Final, 7.33.0.Final, 7.32.0.Final
Reporter: Matteo Casalino
Assignee: Mario Fusco
Attachments: forall-with-empty-list-constraint-combined-with-or.zip
As of Drools 7.32.0.Final, {{forall}} patterns with "empty list" constraints combined with other constraints through {{or}} will fail to match as expected.
For example the following rule:
{noformat}
rule "forall with not equal"
when forall($p : Pojo(y == 1)
Pojo(x.empty || x contains 2, z == 3, this == $p))
then
end
{noformat}
will not fire against following facts:
{noformat}
Pojo{x=[2], y=0, z=0}
Pojo{x=[], y=1, z=3}
Pojo{x=[3], y=0, z=3}
Pojo{x=[2], y=1, z=3}
{noformat}
We suspect a problem with the rewriting of the {{forall}} clause. It appears the clause is rewritten as:
{{not Pojo(y == 1, (x.empty && !(x contains 2)) || !(z == 3))}}
instead of the expected:
{{not Pojo(y == 1, (!(x.empty) && !(x contains 2)) || !(z == 3))}}
This is working fine when using Drools {{<= 7.31.0.Final}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5095) [DMN Designer] Investigate performance switching between editor instances
by Michael Biarnes Kiefer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5095?page=com.atlassian.jira.plug... ]
Michael Biarnes Kiefer updated DROOLS-5095:
-------------------------------------------
Fix Version/s: 7.45.0.Final
(was: 7.44.0.Final)
> [DMN Designer] Investigate performance switching between editor instances
> -------------------------------------------------------------------------
>
> Key: DROOLS-5095
> URL: https://issues.redhat.com/browse/DROOLS-5095
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.45.0.Final
>
> Attachments: switch-dmn.webm
>
>
> This JIRA is to investigate the reported performance issue switching between different DMN Designer instances in Business Central.
> The issue was noticed by [~jomarko] when testing DROOLS-5058 (although the fix therein should have had *zero* affect on switching).
> For more details see the video [^switch-dmn.webm]
> h2. Manual acceptance test
> - Prepare 5 DMN models in project
> - Open all in parallel
> - Try to switch between them, keep all opened
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months