[JBoss JIRA] (DROOLS-2646) KieContainer#updateToVersion removing rules: logically inserted objects not removed correctly
by Olga Rodionova (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2646?page=com.atlassian.jira.plugi... ]
Olga Rodionova updated DROOLS-2646:
-----------------------------------
Steps to Reproduce:
Consider the rule file: SimpleRuleAB.drl
declare MyIntA
val : Integer @key
end
declare MyIntB
val : Integer @key
end
rule "Simple rule A"
when
String(this == "I'm active")
$i : Integer(intValue > 5)
then
insertLogical(new MyIntA($i))
end
rule "Simple rule B"
when
String(this == "I'm active")
$i : Integer(intValue <= 5)
then
insertLogical(new MyIntB($i))
end
The test which reproduces the bug:
@Test
public void ruleRemovalTest() {
/**
* Create the kie container based on a simple rule from SimpleRule.drl
*/
KieServices kieServices = KieServices.Factory.get();
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
kieFileSystem.write(ResourceFactory.newFileResource("src/test/java/rulesengine/SimpleRuleAB.drl"));
KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
KieModule kieModule = kieBuilder.getKieModule();
KieContainer kieContainer = kieServices.newKieContainer(kieModule.getReleaseId());
KieSession kieSession = kieContainer.newKieSession();
/**
* Insert three Integer objects: 3, 7, 9
*/
kieSession.insert("I'm active");
kieSession.insert(new Integer(3));
kieSession.insert(new Integer(7));
kieSession.insert(new Integer(9));
Assert.assertEquals(4, kieSession.getObjects().size());
/**
* Fire all rules, verify that two objects of type MyIntA and one object of type
* MyIntB are created
*/
kieSession.fireAllRules();
System.out.println("***************************************************");
System.out.println("Objects in the working memory after all rules fired");
for (Object o : kieSession.getObjects()) {
System.out.println(o);
}
System.out.println("***************************************************");
Assert.assertEquals(7, kieSession.getObjects().size());
/**
* Update the kie base using the kie module which no longer contains
* SimpleRule.drl
*/
kieFileSystem = kieServices.newKieFileSystem();
kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
kieModule = kieBuilder.getKieModule();
kieContainer.updateToVersion(kieModule.getReleaseId());
/**
* Fire all rules. Logically inserted objects of types MyIntA and MyIntB should be
* automatically removed from the working memory
*/
kieSession.fireAllRules();
System.out.println("***************************************************");
System.out.println("Objects in the working memory after the SimpleRule.drl is removed");
for (Object o : kieSession.getObjects()) {
System.out.println(o);
}
System.out.println("***************************************************");
Assert.assertEquals(4, kieSession.getObjects().size());
}
Display results:
***************************************************
Objects in the working memory after all rules fired
I'm active
7
3
9
MyIntA( val=7 )
MyIntA( val=9 )
MyIntB( val=3 )
***************************************************
***************************************************
Objects in the working memory after the SimpleRule.drl is removed
I'm active
7
3
9
MyIntB( val=3 )
***************************************************
was:
Consider the rule file: SimpleRuleAB.drl
declare MyIntA
val : Integer @key
end
declare MyIntB
val : Integer @key
end
rule "Simple rule A"
when
String(this == "I'm active")
$i : Integer(intValue > 5)
then
insertLogical(new MyIntA($i))
end
rule "Simple rule B"
when
String(this == "I'm active")
$i : Integer(intValue <= 5)
then
insertLogical(new MyIntB($i))
end
The test which reproduces the bug:
@Test
public void ruleRemovalTest() {
/**
* Create the kie container based on a simple rule from SimpleRule.drl
*/
KieServices kieServices = KieServices.Factory.get();
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
kieFileSystem.write(ResourceFactory.newFileResource("src/test/java/rulesengine/SimpleRuleAB.drl"));
KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
KieModule kieModule = kieBuilder.getKieModule();
KieContainer kieContainer = kieServices.newKieContainer(kieModule.getReleaseId());
KieSession kieSession = kieContainer.newKieSession();
/**
* Insert three Integer objects: 3, 7, 9
*/
kieSession.insert("I'm active");
kieSession.insert(new Integer(3));
kieSession.insert(new Integer(7));
kieSession.insert(new Integer(9));
Assert.assertEquals(4, kieSession.getObjects().size());
/**
* Fire all rules, verify that two objects of type MyIntA and one object of type
* MyIntB are created
*/
kieSession.fireAllRules();
System.out.println("***************************************************");
System.out.println("Objects in the working memory after all rules fired");
for (Object o : kieSession.getObjects()) {
System.out.println(o);
}
System.out.println("***************************************************");
Assert.assertEquals(7, kieSession.getObjects().size());
/**
* Update the kie base using the kie module which no longer contains
* SimpleRule.drl
*/
kieFileSystem = kieServices.newKieFileSystem();
kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
kieModule = kieBuilder.getKieModule();
kieContainer.updateToVersion(kieModule.getReleaseId());
/**
* Fire all rules. Logically inserted objects of types MyIntA and MyIntB should be
* automatically removed from the working memory
*/
kieSession.fireAllRules();
System.out.println("***************************************************");
System.out.println("Objects in the working memory after the SimpleRule.drl is removed");
for (Object o : kieSession.getObjects()) {
System.out.println(o);
}
System.out.println("***************************************************");
Assert.assertEquals(4, kieSession.getObjects().size());
}}}
Display results:
{{***************************************************
Objects in the working memory after all rules fired
I'm active
7
3
9
MyIntA( val=7 )
MyIntA( val=9 )
MyIntB( val=3 )
***************************************************
***************************************************
Objects in the working memory after the SimpleRule.drl is removed
I'm active
7
3
9
MyIntB( val=3 )
***************************************************}}
> KieContainer#updateToVersion removing rules: logically inserted objects not removed correctly
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-2646
> URL: https://issues.jboss.org/browse/DROOLS-2646
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Olga Rodionova
> Assignee: Mario Fusco
>
> Consider two rules which have one of the patterns in common, each of which logically inserts an object in the RHS. Build the KieModule from the KieFileSystem including these rules, create the KieContainer and the KieSession. Insert the facts. Everything works fine.
> Create a new KieModule excluding these rules from the KieFileSystem, update the KieContainer. Expect the logically inserted facts to be retracted, as the rules which trigged their creation is no longer present. Turns out that is true for the facts inserted by the first rule, but not for the second one: the facts remain in the working memory.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2646) KieContainer#updateToVersion removing rules: logically inserted objects not removed correctly
by Olga Rodionova (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2646?page=com.atlassian.jira.plugi... ]
Olga Rodionova updated DROOLS-2646:
-----------------------------------
Steps to Reproduce:
Consider the rule file: SimpleRuleAB.drl
declare MyIntA
val : Integer @key
end
declare MyIntB
val : Integer @key
end
rule "Simple rule A"
when
String(this == "I'm active")
$i : Integer(intValue > 5)
then
insertLogical(new MyIntA($i))
end
rule "Simple rule B"
when
String(this == "I'm active")
$i : Integer(intValue <= 5)
then
insertLogical(new MyIntB($i))
end
The test which reproduces the bug:
@Test
public void ruleRemovalTest() {
/**
* Create the kie container based on a simple rule from SimpleRule.drl
*/
KieServices kieServices = KieServices.Factory.get();
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
kieFileSystem.write(ResourceFactory.newFileResource("src/test/java/rulesengine/SimpleRuleAB.drl"));
KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
KieModule kieModule = kieBuilder.getKieModule();
KieContainer kieContainer = kieServices.newKieContainer(kieModule.getReleaseId());
KieSession kieSession = kieContainer.newKieSession();
/**
* Insert three Integer objects: 3, 7, 9
*/
kieSession.insert("I'm active");
kieSession.insert(new Integer(3));
kieSession.insert(new Integer(7));
kieSession.insert(new Integer(9));
Assert.assertEquals(4, kieSession.getObjects().size());
/**
* Fire all rules, verify that two objects of type MyIntA and one object of type
* MyIntB are created
*/
kieSession.fireAllRules();
System.out.println("***************************************************");
System.out.println("Objects in the working memory after all rules fired");
for (Object o : kieSession.getObjects()) {
System.out.println(o);
}
System.out.println("***************************************************");
Assert.assertEquals(7, kieSession.getObjects().size());
/**
* Update the kie base using the kie module which no longer contains
* SimpleRule.drl
*/
kieFileSystem = kieServices.newKieFileSystem();
kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
kieModule = kieBuilder.getKieModule();
kieContainer.updateToVersion(kieModule.getReleaseId());
/**
* Fire all rules. Logically inserted objects of types MyIntA and MyIntB should be
* automatically removed from the working memory
*/
kieSession.fireAllRules();
System.out.println("***************************************************");
System.out.println("Objects in the working memory after the SimpleRule.drl is removed");
for (Object o : kieSession.getObjects()) {
System.out.println(o);
}
System.out.println("***************************************************");
Assert.assertEquals(4, kieSession.getObjects().size());
}}}
Display results:
{{***************************************************
Objects in the working memory after all rules fired
I'm active
7
3
9
MyIntA( val=7 )
MyIntA( val=9 )
MyIntB( val=3 )
***************************************************
***************************************************
Objects in the working memory after the SimpleRule.drl is removed
I'm active
7
3
9
MyIntB( val=3 )
***************************************************}}
was:
Consider the rule file: SimpleRuleAB.drl
{{declare MyIntA
val : Integer @key
end
declare MyIntB
val : Integer @key
end
rule "Simple rule A"
when
String(this == "I'm active")
$i : Integer(intValue > 5)
then
insertLogical(new MyIntA($i))
end
rule "Simple rule B"
when
String(this == "I'm active")
$i : Integer(intValue <= 5)
then
insertLogical(new MyIntB($i))
end}}
The test which reproduces the bug:
{{ @Test
public void ruleRemovalTest() {
/**
* Create the kie container based on a simple rule from SimpleRule.drl
*/
KieServices kieServices = KieServices.Factory.get();
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
kieFileSystem.write(ResourceFactory.newFileResource("src/test/java/rulesengine/SimpleRuleAB.drl"));
KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
KieModule kieModule = kieBuilder.getKieModule();
KieContainer kieContainer = kieServices.newKieContainer(kieModule.getReleaseId());
KieSession kieSession = kieContainer.newKieSession();
/**
* Insert three Integer objects: 3, 7, 9
*/
kieSession.insert("I'm active");
kieSession.insert(new Integer(3));
kieSession.insert(new Integer(7));
kieSession.insert(new Integer(9));
Assert.assertEquals(4, kieSession.getObjects().size());
/**
* Fire all rules, verify that two objects of type MyIntA and one object of type
* MyIntB are created
*/
kieSession.fireAllRules();
System.out.println("***************************************************");
System.out.println("Objects in the working memory after all rules fired");
for (Object o : kieSession.getObjects()) {
System.out.println(o);
}
System.out.println("***************************************************");
Assert.assertEquals(7, kieSession.getObjects().size());
/**
* Update the kie base using the kie module which no longer contains
* SimpleRule.drl
*/
kieFileSystem = kieServices.newKieFileSystem();
kieBuilder = kieServices.newKieBuilder(kieFileSystem);
kieBuilder.buildAll();
kieModule = kieBuilder.getKieModule();
kieContainer.updateToVersion(kieModule.getReleaseId());
/**
* Fire all rules. Logically inserted objects of types MyIntA and MyIntB should be
* automatically removed from the working memory
*/
kieSession.fireAllRules();
System.out.println("***************************************************");
System.out.println("Objects in the working memory after the SimpleRule.drl is removed");
for (Object o : kieSession.getObjects()) {
System.out.println(o);
}
System.out.println("***************************************************");
Assert.assertEquals(4, kieSession.getObjects().size());
}}}
Display results:
{{***************************************************
Objects in the working memory after all rules fired
I'm active
7
3
9
MyIntA( val=7 )
MyIntA( val=9 )
MyIntB( val=3 )
***************************************************
***************************************************
Objects in the working memory after the SimpleRule.drl is removed
I'm active
7
3
9
MyIntB( val=3 )
***************************************************}}
> KieContainer#updateToVersion removing rules: logically inserted objects not removed correctly
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-2646
> URL: https://issues.jboss.org/browse/DROOLS-2646
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Olga Rodionova
> Assignee: Mario Fusco
>
> Consider two rules which have one of the patterns in common, each of which logically inserts an object in the RHS. Build the KieModule from the KieFileSystem including these rules, create the KieContainer and the KieSession. Insert the facts. Everything works fine.
> Create a new KieModule excluding these rules from the KieFileSystem, update the KieContainer. Expect the logically inserted facts to be retracted, as the rules which trigged their creation is no longer present. Turns out that is true for the facts inserted by the first rule, but not for the second one: the facts remain in the working memory.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2646) KieContainer#updateToVersion removing rules: logically inserted objects not removed correctly
by Olga Rodionova (JIRA)
Olga Rodionova created DROOLS-2646:
--------------------------------------
Summary: KieContainer#updateToVersion removing rules: logically inserted objects not removed correctly
Key: DROOLS-2646
URL: https://issues.jboss.org/browse/DROOLS-2646
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.7.0.Final
Reporter: Olga Rodionova
Assignee: Mario Fusco
Consider two rules which have one of the patterns in common, each of which logically inserts an object in the RHS. Build the KieModule from the KieFileSystem including these rules, create the KieContainer and the KieSession. Insert the facts. Everything works fine.
Create a new KieModule excluding these rules from the KieFileSystem, update the KieContainer. Expect the logically inserted facts to be retracted, as the rules which trigged their creation is no longer present. Turns out that is true for the facts inserted by the first rule, but not for the second one: the facts remain in the working memory.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-294) Investigate ElasticSearch memory requirements on B24 cluster
by Kevin Earls (JIRA)
[ https://issues.jboss.org/browse/SWSQE-294?page=com.atlassian.jira.plugin.... ]
Kevin Earls commented on SWSQE-294:
-----------------------------------
[~gbaufake] asked me to try this on gprfc032.sbu.lab.eng.bos.redhat.com (in the red hat scale lab?) and I saw the same behavior. The elasticsearch cluster would not start up if only given 512Mi of memory, and needed 2Gi for anything non trivial.
> Investigate ElasticSearch memory requirements on B24 cluster
> ------------------------------------------------------------
>
> Key: SWSQE-294
> URL: https://issues.jboss.org/browse/SWSQE-294
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Kevin Earls
> Assignee: Guilherme Baufaker Rêgo
> Priority: Minor
> Attachments: es1.log
>
>
> On minishift and the CNCF CI OpenShift cluster, we install ElasticSearch using the commands:
> curl https://raw.githubusercontent.com/RHsyseng/docker-rhel-elasticsearch/5.x/... --output es-cluster-deployment.yml
> oc create -f es-cluster-deployment.yml
> However, on B24 this fails. The first 2 elasticsearch pods will start up, but then elasticsearch-2 gets into the following failure loop like:
> elasticsearch-2 1/1 Running 3 1m
> elasticsearch-2 0/1 OOMKilled 3 1m
> elasticsearch-2 0/1 CrashLoopBackOff 3 2m
> If I increase memory in the es-cluster-deployment.yml to 1Gi it will at least start, but I've found I really need to increase it to 2Gi to do anything non trivial.
> We may need to track down the people who originally created this template for help on this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-10280:
-------------------------------------------
{quote}
What exactly do you find confusing?
{quote}
This suplier/capability provider, funcitonal service, some sort of composite dependency and factories makes it harder to follow. Instead of clear deps its a bit obfuscated picture that is being drawn in code. Not to mention capability org.wildfly.clustering.cache.registry-entry.ejb.client-mappings being reigstered in ejb=remote tree. I get it can be done like this, but as is I fail to see why, possibly Im missing something.
Ok [~pferraro] so what is the angle on this. Should remote stay as a required dep or can for instance clustering provide stub service that can run in place of remoting?( just got up, so I have no idea how it works )
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10280:
-------------------------------------
{quote}Well, the whole clustering service dependencies/suppliers/functional services are quite confusing.{quote}
What exactly do you find confusing?
{quote}What I fail to understand is why service deployed in /subsystem=ejb3/service=remote (EJBRemotingConnectorClientMappingsEntryProviderService) registers as service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings{quote}
The "org.wildfly.clustering.cache.registry-entry.ejb.client-mappings" is a dependency of the "org.wildfly.clustering.cache.registry.ejb.client-mappings" service. The org.wildfly.clustering.ejb.infinispan module already created the latter - but it needs the former in order to start, the configuration for which comes from the ejb remoting resource.
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-312) Test Bookinfo with High Load Traffic
by Guilherme Baufaker Rêgo (JIRA)
Guilherme Baufaker Rêgo created SWSQE-312:
---------------------------------------------
Summary: Test Bookinfo with High Load Traffic
Key: SWSQE-312
URL: https://issues.jboss.org/browse/SWSQE-312
Project: Kiali QE
Issue Type: Bug
Reporter: Guilherme Baufaker Rêgo
Assignee: Michael Foley
Test Bookinfo in order to see how kiali behaves when a mesh has high load traffic.
- This test will allow seeing if traffic animation will behave right
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years