[JBoss JIRA] (DROOLS-3879) Create Kogito version of Test Scenarios designer
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-3879?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-3879:
-------------------------------------
Description:
Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor.
>From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`.
Access to it has been "hided" behind a wrapper interface with three actual implementations:
* `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment
* `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment
* `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode).
As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place.
Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach.
Kogito-testing module is a standalone showcase that provides some minimum interaction to:
* load DMN files
* create DMN-related scesim assets, selecting one of the imported DMN.
Currently - RULE/data object model scesim is disabled.
Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset.
Some minimal tests may be done in the following way:
# full compilation (i.e. included GWT compilation) of the runtime module
# open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome
# inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will show the "New Scesim" popup, where user may choose to create a DMN or RULE scesim; of course, inside Chrome it is not possible to have a reference to other resources, so only "Rule" will work; at the same time, no Data model is available inside Chrome, so the right panel will be empty and the only expected result is an empty grid.
# edit the asset
# invoke window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().getContent() and store the returned xml
# invoke window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent method with the stored xml
Some tricks: to avoid CORS and other policy-related issues:
# set chrome://flags/#allow-insecure-localhost for invalid certificates error
# start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file.
/----/
The "run scenario" functionality won't be implemented by this PR.
All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode
was:
Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor.
>From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`.
Access to it has been "hided" behind a wrapper interface with three actual implementations:
* `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment
* `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment
* `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode).
As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place.
Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach.
Kogito-testing module is a standalone showcase that provides some minimum interaction to:
* load DMN files
* create DMN-related scesim assets, selecting one of the imported DMN.
Currently - RULE/data object model scesim is disabled.
Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset.
Some minimal tests may be done in the following way:
# full compilation (i.e. included GWT compilation) of the runtime module
# open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome
# inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will show the "New Scesim" popup, where user may choose to create a DMN or RULE scesim; of course, inside Chrome it is not possible to have a reference to other resources, so only "Rule" will work; at the same time, no Data model is available inside Chrome, so the right panel will be empty and the only expected result is an empty grid.
Some tricks: to avoid CORS and other policy-related issues:
# set chrome://flags/#allow-insecure-localhost for invalid certificates error
# start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file.
/----/
The "run scenario" functionality won't be implemented by this PR.
All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode
> Create Kogito version of Test Scenarios designer
> ------------------------------------------------
>
> Key: DROOLS-3879
> URL: https://issues.redhat.com/browse/DROOLS-3879
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
>
> Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor.
> From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`.
> Access to it has been "hided" behind a wrapper interface with three actual implementations:
> * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment
> * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment
> * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode).
> As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place.
> Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach.
> Kogito-testing module is a standalone showcase that provides some minimum interaction to:
> * load DMN files
> * create DMN-related scesim assets, selecting one of the imported DMN.
> Currently - RULE/data object model scesim is disabled.
> Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset.
> Some minimal tests may be done in the following way:
> # full compilation (i.e. included GWT compilation) of the runtime module
> # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome
> # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will show the "New Scesim" popup, where user may choose to create a DMN or RULE scesim; of course, inside Chrome it is not possible to have a reference to other resources, so only "Rule" will work; at the same time, no Data model is available inside Chrome, so the right panel will be empty and the only expected result is an empty grid.
> # edit the asset
> # invoke window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().getContent() and store the returned xml
> # invoke window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent method with the stored xml
> Some tricks: to avoid CORS and other policy-related issues:
> # set chrome://flags/#allow-insecure-localhost for invalid certificates error
> # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file.
> /----/
> The "run scenario" functionality won't be implemented by this PR.
> All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2435?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2435:
---------------------------
Fix Version/s: 5.0
4.2.0
[~dan.berindei] I assume this is te delta-view email thread?
> ClientGmsImpl ignores newer view during join
> --------------------------------------------
>
> Key: JGRP-2435
> URL: https://issues.redhat.com/browse/JGRP-2435
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed.
> The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out.
> I added some logs in TP and GMS for debugging, and this is what I see:
> {noformat}
> 10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC]
> 10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
> 1:
> #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
> 1:
> #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> ### GmsImpl.handleViewChange() {}
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD]
> 10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> ### The ack for the JOIN_RSP is only sent here
> 10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2
> {noformat}
> To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12899) Failing JMXPropertyEditorsTestCase in 18.0.0.Final
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-12899?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski edited comment on WFLY-12899 at 1/15/20 5:17 AM:
--------------------------------------------------------------------
Test is designed to check env variables expansion. So naturally one env var that is present in any OS( one way or another) has been chosen. Since different OS store it a bit differently test has to do some digging and store name of env variable in USER_SYS_PROP.
Problem with docker is that it does great job at isolating running process that is - unless you set explicitly some env variable it wont be there, even though it is present in OS/env. (Im assuming that jenkins triggers docker to test WFLY).
One solution would be to add -e switch to docker(or any kind of equivalent), second to ignore this part of test if no env value can be detected.
[~james-crowley-ibm] - can you please try -e ?
was (Author: baranowb):
Test is designed to check env variables expansion. So naturally one env var that is present in any OS( one way or another) has been chosen. Since different OS store it a bit differently test has to do some digging and stores name of env variable in USER_SYS_PROP.
Problem with docker is that it does great job at isolating running process that is - unless you set explicitly some env variable it wont be there, even though it is present in OS/env. (Im assuming that jenkins triggers docker to test WFLY).
One solution would be to add -e switch to docker(or any kind of equivalent), second to ignore this part of test if no env value can be detected.
[~james-crowley-ibm] - can you please try -e ?
> Failing JMXPropertyEditorsTestCase in 18.0.0.Final
> --------------------------------------------------
>
> Key: WFLY-12899
> URL: https://issues.redhat.com/browse/WFLY-12899
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 18.0.0.Final
> Reporter: James Crowley
> Assignee: Bartosz Baranowski
> Priority: Major
>
> When calling "./mvnw install -DallTests", it gets up to the JMXPropertyEditorsTestCase and fails with this error, "Caused by: java.lang.IllegalStateException: Failed to resolve expression: env.USER"}}}}".
> Looking at the source code for the test [here|https://github.com/wildfly/wildfly/blob/1bf993be72b570a0c780a58ba05c...], it looks like USER is suppose to be defined by USER_SYS_PROP.
> I am not sure what the problem is but I know it is failing somewhere in the above test.
> You can see the full log in the in Adopt's test [here|https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/1436/conso...].
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12899) Failing JMXPropertyEditorsTestCase in 18.0.0.Final
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-12899?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski commented on WFLY-12899:
-------------------------------------------
Test is designed to check env variables expansion. So naturally one env var that is present in any OS( one way or another) has been chosen. Since different OS store it a bit differently test has to do some digging and stores name of env variable in USER_SYS_PROP.
Problem with docker is that it does great job at isolating running process that is - unless you set explicitly some env variable it wont be there, even though it is present in OS/env. (Im assuming that jenkins triggers docker to test WFLY).
One solution would be to add -e switch to docker(or any kind of equivalent), second to ignore this part of test if no env value can be detected.
[~james-crowley-ibm] - can you please try -e ?
> Failing JMXPropertyEditorsTestCase in 18.0.0.Final
> --------------------------------------------------
>
> Key: WFLY-12899
> URL: https://issues.redhat.com/browse/WFLY-12899
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 18.0.0.Final
> Reporter: James Crowley
> Assignee: Bartosz Baranowski
> Priority: Major
>
> When calling "./mvnw install -DallTests", it gets up to the JMXPropertyEditorsTestCase and fails with this error, "Caused by: java.lang.IllegalStateException: Failed to resolve expression: env.USER"}}}}".
> Looking at the source code for the test [here|https://github.com/wildfly/wildfly/blob/1bf993be72b570a0c780a58ba05c...], it looks like USER is suppose to be defined by USER_SYS_PROP.
> I am not sure what the problem is but I know it is failing somewhere in the above test.
> You can see the full log in the in Adopt's test [here|https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/1436/conso...].
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join
by Dan Berindei (Jira)
Dan Berindei created JGRP-2435:
----------------------------------
Summary: ClientGmsImpl ignores newer view during join
Key: JGRP-2435
URL: https://issues.redhat.com/browse/JGRP-2435
Project: JGroups
Issue Type: Bug
Affects Versions: 4.1.9
Reporter: Dan Berindei
Assignee: Bela Ban
We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed.
The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out.
I added some logs in TP and GMS for debugging, and this is what I see:
{noformat}
10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC]
10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
1:
#1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
1:
#1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
### GmsImpl.handleViewChange() {}
10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD]
10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
### The ack for the JOIN_RSP is only sent here
10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2
{noformat}
To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4169) Can't compile large .drl files with security manager turned on in tomcat
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4169?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-4169.
---------------------------------
Resolution: Explained
> Can't compile large .drl files with security manager turned on in tomcat
> ------------------------------------------------------------------------
>
> Key: DROOLS-4169
> URL: https://issues.redhat.com/browse/DROOLS-4169
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.22.0.Final
> Environment: Java 11
> Tomcat 9
> Ubuntu 18.10/Amazon Linux AMI
> Reporter: Anthony Bruno
> Assignee: Mario Fusco
> Priority: Major
>
> Reproduction repository: https://github.com/AussieGuy0/drools-bug
> *Summary*
> When large rule (.drl) files are complied **with** the security manager turned
> on in a servlet container (e.g. Tomcat), it causes `AccessControlExceptions`, which causes `NoClassDefFoundErrors`.
> *Steps*
> Prereqs: Program is run in servlet context (e.g .war file in tomcat)
> 1. Turn on security manager
> 2. Provide policy files through the properties `java.security.policy` and `kie.security.policy`
> 3. Compile a `.drl` file that has more than `parallelRulesBuildThreshold` (default: 10) rules
> *Expected Result*
> Rules are compiled successfully
> *Actual Result*
> No class def error
> *Cause*
> In `KnowledgeBuilderImpl`, a `ForkJoinPool` is created and used for parallel building.
> A `ForkJoinPool` with no `ForkJoinWorkerThreadFactory` specified, it will use a default factory
> that provides it's own permissions. These permissions are not sufficient for compiling
> drl files in a servlet context.
> *Potential Fix*
> A potential fix is to allow the user to provide their own `ForkJoinWorkerThreadFactory` as a
> configuration option for drools.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4169) Can't compile large .drl files with security manager turned on in tomcat
by Tibor Zimanyi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4169?page=com.atlassian.jira.plug... ]
Tibor Zimanyi edited comment on DROOLS-4169 at 1/15/20 3:57 AM:
----------------------------------------------------------------
Hi [~anthony_bruno], sorry for late reply. I tried with Tomcat and if you specify security permissions in Tomcat's conf/catalina.policy file for your web application, it works. I added this to it (just for testing purposes, you can add more granular permissions):
{code:java}
grant codeBase "file:${catalina.base}/webapps/test/-" {
permission java.security.AllPermission;
};
{code}
Then I started the server with _./catalina.sh run -security_ and the big DRL worked. Please let me know if this answers your problem and if yes, I will close this JIRA.
was (Author: tzimanyi):
Hi [~anthony_bruno], sorry for late reply. I tried with Tomcat and if you specify security permissions in Tomcat's conf/catalina.policy file for your web application, it works. I added this to it (just for testing purposes, you can add more granular permissions):
grant codeBase "file:${catalina.base}/webapps/test/-" {
permission java.security.AllPermission;
};
Then I started the server with _./catalina.sh run -security_ and the big DRL worked. Please let me know if this answers your problem and if yes, I will close this JIRA.
> Can't compile large .drl files with security manager turned on in tomcat
> ------------------------------------------------------------------------
>
> Key: DROOLS-4169
> URL: https://issues.redhat.com/browse/DROOLS-4169
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.22.0.Final
> Environment: Java 11
> Tomcat 9
> Ubuntu 18.10/Amazon Linux AMI
> Reporter: Anthony Bruno
> Assignee: Mario Fusco
> Priority: Major
>
> Reproduction repository: https://github.com/AussieGuy0/drools-bug
> *Summary*
> When large rule (.drl) files are complied **with** the security manager turned
> on in a servlet container (e.g. Tomcat), it causes `AccessControlExceptions`, which causes `NoClassDefFoundErrors`.
> *Steps*
> Prereqs: Program is run in servlet context (e.g .war file in tomcat)
> 1. Turn on security manager
> 2. Provide policy files through the properties `java.security.policy` and `kie.security.policy`
> 3. Compile a `.drl` file that has more than `parallelRulesBuildThreshold` (default: 10) rules
> *Expected Result*
> Rules are compiled successfully
> *Actual Result*
> No class def error
> *Cause*
> In `KnowledgeBuilderImpl`, a `ForkJoinPool` is created and used for parallel building.
> A `ForkJoinPool` with no `ForkJoinWorkerThreadFactory` specified, it will use a default factory
> that provides it's own permissions. These permissions are not sufficient for compiling
> drl files in a servlet context.
> *Potential Fix*
> A potential fix is to allow the user to provide their own `ForkJoinWorkerThreadFactory` as a
> configuration option for drools.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4169) Can't compile large .drl files with security manager turned on in tomcat
by Tibor Zimanyi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4169?page=com.atlassian.jira.plug... ]
Tibor Zimanyi commented on DROOLS-4169:
---------------------------------------
Hi [~anthony_bruno], sorry for late reply. I tried with Tomcat and if you specify security permissions in Tomcat's conf/catalina.policy file for your web application, it works. I added this to it (just for testing purposes, you can add more granular permissions):
grant codeBase "file:${catalina.base}/webapps/test/-" {
permission java.security.AllPermission;
};
Then I started the server with _./catalina.sh run -security_ and the big DRL worked. Please let me know if this answers your problem and if yes, I will close this JIRA.
> Can't compile large .drl files with security manager turned on in tomcat
> ------------------------------------------------------------------------
>
> Key: DROOLS-4169
> URL: https://issues.redhat.com/browse/DROOLS-4169
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.22.0.Final
> Environment: Java 11
> Tomcat 9
> Ubuntu 18.10/Amazon Linux AMI
> Reporter: Anthony Bruno
> Assignee: Mario Fusco
> Priority: Major
>
> Reproduction repository: https://github.com/AussieGuy0/drools-bug
> *Summary*
> When large rule (.drl) files are complied **with** the security manager turned
> on in a servlet container (e.g. Tomcat), it causes `AccessControlExceptions`, which causes `NoClassDefFoundErrors`.
> *Steps*
> Prereqs: Program is run in servlet context (e.g .war file in tomcat)
> 1. Turn on security manager
> 2. Provide policy files through the properties `java.security.policy` and `kie.security.policy`
> 3. Compile a `.drl` file that has more than `parallelRulesBuildThreshold` (default: 10) rules
> *Expected Result*
> Rules are compiled successfully
> *Actual Result*
> No class def error
> *Cause*
> In `KnowledgeBuilderImpl`, a `ForkJoinPool` is created and used for parallel building.
> A `ForkJoinPool` with no `ForkJoinWorkerThreadFactory` specified, it will use a default factory
> that provides it's own permissions. These permissions are not sufficient for compiling
> drl files in a servlet context.
> *Potential Fix*
> A potential fix is to allow the user to provide their own `ForkJoinWorkerThreadFactory` as a
> configuration option for drools.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months