[JBoss JIRA] (JGRP-2317) Discovery: send multiple discovery requests
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2317?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2317:
---------------------------
Description:
Define a {{num_requests}} (default: 1) attribute (we used to have this!) that governs how many times a discovery is executed until the timeout is reached, or a coord is found.
This may be useful when multiple members are started at the same time and/or the discovery does not return the correct members the first time around. Especially needed for DNS_PING.
The number of requests should be spaced out evenly across a range [0 .. timeout-(timeout/num_requests)]
Example: timeout=12000, num_requests=3;
* Range: [0 .. 8000] (12-4)
* First req sent at time 0
* Second: time 4000
* Third: 8000
Interval: {{timeout - (timeout/num_reqs) / num_reqs-1}}
was:
Define a {{num_requests}} (default: 1) attribute (we used to have this!) that governs how many times a discovery is executed until the timeout is reached, or a coord is found.
This may be useful when multiple members are started at the same time and/or the discovery does not return the correct members the first time around. Especially needed for DNS_PING.
The number of requests should be spaced out evenly across a range [0 .. timeout-(timeout/num_requests)]
Example: timeout=12000, num_requests=3;
* Range: [0 .. 8000] (12-4)
* First req sent at time 0
* Second: time 4000
* Third: 8000
Interval: {{timeout - (timeout/num_reqs) / num_reqs-1 }}
> Discovery: send multiple discovery requests
> -------------------------------------------
>
> Key: JGRP-2317
> URL: https://issues.redhat.com/browse/JGRP-2317
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> Define a {{num_requests}} (default: 1) attribute (we used to have this!) that governs how many times a discovery is executed until the timeout is reached, or a coord is found.
> This may be useful when multiple members are started at the same time and/or the discovery does not return the correct members the first time around. Especially needed for DNS_PING.
> The number of requests should be spaced out evenly across a range [0 .. timeout-(timeout/num_requests)]
> Example: timeout=12000, num_requests=3;
> * Range: [0 .. 8000] (12-4)
> * First req sent at time 0
> * Second: time 4000
> * Third: 8000
> Interval: {{timeout - (timeout/num_reqs) / num_reqs-1}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5093) CLI accept invalid values for -Xms and -Xmx while adding
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFCORE-5093?page=com.atlassian.jira.plug... ]
Ranabir Chakraborty updated WFCORE-5093:
----------------------------------------
Description:
The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
~~~
[domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
{code:java}
{ "outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" =>
{ "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" }
}} }}}} }
{code}
However, the server failed to start but it should not accept invalid values likes garbage STRING while addition.
The domain controller is what would validate the value but what it, or even the Host Controllers, would be running is not necessarily what the servers would be running.
was:
The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
~~~
[domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
{code:java}
{ "outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" =>
{ "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" }
}} }}}} }
{code}
However, the server failed to start but it should not accept invalid values likes STRING while addition.
> CLI accept invalid values for -Xms and -Xmx while adding
> --------------------------------------------------------
>
> Key: WFCORE-5093
> URL: https://issues.redhat.com/browse/WFCORE-5093
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Affects Versions: 13.0.0.Beta4
> Reporter: Ranabir Chakraborty
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
> I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
> ~~~
> [domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
> {code:java}
> { "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" =>
> { "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" }
> }} }}}} }
> {code}
> However, the server failed to start but it should not accept invalid values likes garbage STRING while addition.
> The domain controller is what would validate the value but what it, or even the Host Controllers, would be running is not necessarily what the servers would be running.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5093) CLI accept invalid values for -Xms and -Xmx while adding
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFCORE-5093?page=com.atlassian.jira.plug... ]
Ranabir Chakraborty updated WFCORE-5093:
----------------------------------------
Description:
The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
~~~
[domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
{code:java}
{ "outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" =>
{ "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" }
}} }}}} }
{code}
However, the server failed to start but it should not accept invalid values likes STRING while addition.
was:
The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
~~~
[domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
```{ "outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" =>
{ "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => \{"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" }
}} }}}} }```
However, the server failed to start but it should not accept invalid values likes STRING while addition.
> CLI accept invalid values for -Xms and -Xmx while adding
> --------------------------------------------------------
>
> Key: WFCORE-5093
> URL: https://issues.redhat.com/browse/WFCORE-5093
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Affects Versions: 13.0.0.Beta4
> Reporter: Ranabir Chakraborty
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
>
> I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
> ~~~
> [domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
> {code:java}
> { "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" =>
> { "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" }
> }} }}}} }
> {code}
> However, the server failed to start but it should not accept invalid values likes STRING while addition.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5093) CLI accept invalid values for -Xms and -Xmx while adding
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFCORE-5093?page=com.atlassian.jira.plug... ]
Ranabir Chakraborty updated WFCORE-5093:
----------------------------------------
Description:
The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
~~~
[domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
```{ "outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" =>
{ "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => \{"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" }
}} }}}} }```
However, the server failed to start but it should not accept invalid values likes STRING while addition.
was:
The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
~~~
[domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
{ "outcome" => "success",
"result" => undefined,
"server-groups" => \{"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => \{"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }} }}}} }
~~~
However, the server failed to start but it should not accept invalid values likes STRING while addition.
> CLI accept invalid values for -Xms and -Xmx while adding
> --------------------------------------------------------
>
> Key: WFCORE-5093
> URL: https://issues.redhat.com/browse/WFCORE-5093
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Affects Versions: 13.0.0.Beta4
> Reporter: Ranabir Chakraborty
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
>
> I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
> ~~~
> [domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
> ```{ "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" =>
> { "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => \{"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" }
> }} }}}} }```
>
> However, the server failed to start but it should not accept invalid values likes STRING while addition.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5093) CLI accept invalid values for -Xms and -Xmx while adding
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFCORE-5093?page=com.atlassian.jira.plug... ]
Ranabir Chakraborty updated WFCORE-5093:
----------------------------------------
Summary: CLI accept invalid values for -Xms and -Xmx while adding (was: [GSS](7.3.z) CLI accept invalid values for -Xms and -Xmx while adding)
> CLI accept invalid values for -Xms and -Xmx while adding
> --------------------------------------------------------
>
> Key: WFCORE-5093
> URL: https://issues.redhat.com/browse/WFCORE-5093
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Affects Versions: 13.0.0.Beta4
> Reporter: Ranabir Chakraborty
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
>
> I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
> ~~~
> [domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
> { "outcome" => "success",
> "result" => undefined,
> "server-groups" => \{"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => \{"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }} }}}} }
> ~~~
>
> However, the server failed to start but it should not accept invalid values likes STRING while addition.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5093) [GSS](7.3.z) CLI accept invalid values for -Xms and -Xmx while adding
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFCORE-5093?page=com.atlassian.jira.plug... ]
Ranabir Chakraborty moved JBEAP-20100 to WFCORE-5093:
-----------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-5093 (was: JBEAP-20100)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Management
(was: Management)
Affects Version/s: 13.0.0.Beta4
(was: 7.2.8.GA)
> [GSS](7.3.z) CLI accept invalid values for -Xms and -Xmx while adding
> ---------------------------------------------------------------------
>
> Key: WFCORE-5093
> URL: https://issues.redhat.com/browse/WFCORE-5093
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Affects Versions: 13.0.0.Beta4
> Reporter: Ranabir Chakraborty
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> The customer has opened one case where they are saying, CLI is not throwing an error while adding invalid values of -Xmx and -Xms.
>
> I tried to replicate the same in EAP 7.2.8 and I observe the same behavior.
> ~~~
> [domain@localhost:9990 /] /server-group=main-server-group/jvm=default:write-attribute(name=heap-size,value=toto)
> { "outcome" => "success",
> "result" => undefined,
> "server-groups" => \{"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }}, "server-two" => \{"response" => { "outcome" => "success", "response-headers" => { "operation-requires-restart" => true, "process-state" => "restart-required" } }} }}}} }
> ~~~
>
> However, the server failed to start but it should not accept invalid values likes STRING while addition.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5092) Windows Service cannot be stopped when using custom JAVA_HOME path
by Lukas Vydra (Jira)
[ https://issues.redhat.com/browse/WFCORE-5092?page=com.atlassian.jira.plug... ]
Lukas Vydra moved WFLY-13537 to WFCORE-5092:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-5092 (was: WFLY-13537)
Component/s: Scripts
(was: Scripts)
Affects Version/s: 11.0.0.Final
(was: 11.0.0.Final)
> Windows Service cannot be stopped when using custom JAVA_HOME path
> ------------------------------------------------------------------
>
> Key: WFCORE-5092
> URL: https://issues.redhat.com/browse/WFCORE-5092
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 11.0.0.Final
> Reporter: Walter Raaflaub
> Assignee: Lukas Vydra
> Priority: Major
>
> I am running keycloak in a Wildfly container as a Windows service on Windows Server 2019. The service starts up and works correctly; but it hangs when I try to stop it.
> There is no global JAVA_HOME environment variable defined on the server; I'm using a custom JAVA_HOME path that I have configured in standalone.conf.bat.
> While stopping, the service issues the following warning in stdout.log:
> {noformat}
> JAVA_HOME is not set. Unexpected results may occur.
> Set JAVA_HOME to the directory of your local JDK to avoid this message.
> Drcken Sie eine beliebige Taste . . .
> {noformat}
> (Drücken Sie eine beliebige Taste . . . = German vor "Press any key ...")
> It seems that when stopping the service, the JAVA_HOME setting is not correctly passed to the jboss-cli.bat script. The script seems to be waiting for user input, which is akward in a Windows service. That means that also the NOPAUSE setting is not passed correctly to the jboss-cli.bat script.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5584) Retrieving the DMNModel has failed.
by Daniele Zonca (Jira)
[ https://issues.redhat.com/browse/DROOLS-5584?page=com.atlassian.jira.plug... ]
Daniele Zonca commented on DROOLS-5584:
---------------------------------------
Yes it is already doing it but it is not forcing a clean build if there is already one available and when we had similar problem in the past it was related to broken incremental build or similar.
[~Rikkola]
Do you know if your last fix on the way to retrieve KieContainer could be related to this ^ ?
> Retrieving the DMNModel has failed.
> -----------------------------------
>
> Key: DROOLS-5584
> URL: https://issues.redhat.com/browse/DROOLS-5584
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Matteo Mortari
> Assignee: Yeser Amer
> Priority: Major
>
> following the Traffic Violation tutorial I got the error. I worked around the issue by closing all , Build the project, and try it again.
> {code:java}
> 10:35:57,461 ERROR [org.guvnor.common.services.backend.exceptions.ExceptionUtilities] (default task-7) Exception thrown: Retrieving the DMNModel has failed. Make sure the used DMN asset does not produce any compilation errors and that the project does not contain multiple DMN assets with the same name and namespace. In addition, check if the reference to the DMN file is correct in the Settings panel. After addressing the issues, build the project again.: org.drools.scenariosimulation.backend.util.ImpossibleToFindDMNException: Retrieving the DMNModel has failed. Make sure the used DMN asset does not produce any compilation errors and that the project does not contain multiple DMN assets with the same name and namespace. In addition, check if the reference to the DMN file is correct in the Settings panel. After addressing the issues, build the project again.
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.findDMNModel(DMNSimulationUtils.java:56)
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.extractDMNModel(DMNSimulationUtils.java:39)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl.getDMNModel(DMNTypeServiceImpl.java:98)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl.retrieveFactModelTuple(DMNTypeServiceImpl.java:62)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl$Proxy$_$$_WeldClientProxy.retrieveFactModelTuple(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy.getFactModelTuple(DMNSimulationSettingsCreationStrategy.java:145)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy.createSimulation(DMNSimulationSettingsCreationStrategy.java:58)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy$Proxy$_$$_WeldClientProxy.createSimulation(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.ScenarioSimulationBuilder.createSimulation(ScenarioSimulationBuilder.java:41)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.ScenarioSimulationBuilder$Proxy$_$$_WeldClientProxy.createSimulation(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioSimulationServiceImpl.create(ScenarioSimulationServiceImpl.java:176)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioSimulationServiceImpl$Proxy$_$$_WeldClientProxy.create(Unknown Source)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.AbstractRPCMethodCallback.invokeMethodFromMessage(AbstractRPCMethodCallback.java:65)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.ValueReplyRPCEndpointCallback.callback(ValueReplyRPCEndpointCallback.java:40)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.RemoteServiceCallback.callback(RemoteServiceCallback.java:54)
> at deployment.business-central.war//org.jboss.errai.cdi.server.CDIExtensionPoints$2.callback(CDIExtensionPoints.java:448)
> at deployment.business-central.war//org.jboss.errai.bus.server.DeliveryPlan.deliver(DeliveryPlan.java:47)
> at deployment.business-central.war//org.jboss.errai.bus.server.ServerMessageBusImpl.sendGlobal(ServerMessageBusImpl.java:297)
> at deployment.business-central.war//org.jboss.errai.bus.server.SimpleDispatcher.dispatchGlobal(SimpleDispatcher.java:46)
> at deployment.business-central.war//org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:96)
> at deployment.business-central.war//org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:113)
> at deployment.business-central.war//org.jboss.errai.bus.server.servlet.DefaultBlockingServlet.doPost(DefaultBlockingServlet.java:144)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:523)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.undertow.websocket@2.1.0.Final//io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:173)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at deployment.business-central.war//org.uberfire.ext.security.server.SecureHeadersFilter.doFilter(SecureHeadersFilter.java:110)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at deployment.business-central.war//org.uberfire.ext.security.server.SecurityIntegrationFilter.doFilter(SecurityIntegrationFilter.java:70)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.core@2.1.0.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
> at io.undertow.core@2.1.0.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 10:36:12,521 ERROR [org.guvnor.common.services.backend.exceptions.ExceptionUtilities] (default task-7) Exception thrown: Retrieving the DMNModel has failed. Make sure the used DMN asset does not produce any compilation errors and that the project does not contain multiple DMN assets with the same name and namespace. In addition, check if the reference to the DMN file is correct in the Settings panel. After addressing the issues, build the project again.: org.drools.scenariosimulation.backend.util.ImpossibleToFindDMNException: Retrieving the DMNModel has failed. Make sure the used DMN asset does not produce any compilation errors and that the project does not contain multiple DMN assets with the same name and namespace. In addition, check if the reference to the DMN file is correct in the Settings panel. After addressing the issues, build the project again.
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.findDMNModel(DMNSimulationUtils.java:56)
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.extractDMNModel(DMNSimulationUtils.java:39)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl.getDMNModel(DMNTypeServiceImpl.java:98)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl.retrieveFactModelTuple(DMNTypeServiceImpl.java:62)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl$Proxy$_$$_WeldClientProxy.retrieveFactModelTuple(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy.getFactModelTuple(DMNSimulationSettingsCreationStrategy.java:145)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy.createSimulation(DMNSimulationSettingsCreationStrategy.java:58)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy$Proxy$_$$_WeldClientProxy.createSimulation(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.ScenarioSimulationBuilder.createSimulation(ScenarioSimulationBuilder.java:41)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.ScenarioSimulationBuilder$Proxy$_$$_WeldClientProxy.createSimulation(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioSimulationServiceImpl.create(ScenarioSimulationServiceImpl.java:176)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioSimulationServiceImpl$Proxy$_$$_WeldClientProxy.create(Unknown Source)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.AbstractRPCMethodCallback.invokeMethodFromMessage(AbstractRPCMethodCallback.java:65)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.ValueReplyRPCEndpointCallback.callback(ValueReplyRPCEndpointCallback.java:40)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.RemoteServiceCallback.callback(RemoteServiceCallback.java:54)
> at deployment.business-central.war//org.jboss.errai.cdi.server.CDIExtensionPoints$2.callback(CDIExtensionPoints.java:448)
> at deployment.business-central.war//org.jboss.errai.bus.server.DeliveryPlan.deliver(DeliveryPlan.java:47)
> at deployment.business-central.war//org.jboss.errai.bus.server.ServerMessageBusImpl.sendGlobal(ServerMessageBusImpl.java:297)
> at deployment.business-central.war//org.jboss.errai.bus.server.SimpleDispatcher.dispatchGlobal(SimpleDispatcher.java:46)
> at deployment.business-central.war//org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:96)
> at deployment.business-central.war//org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:113)
> at deployment.business-central.war//org.jboss.errai.bus.server.servlet.DefaultBlockingServlet.doPost(DefaultBlockingServlet.java:144)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:523)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.undertow.websocket@2.1.0.Final//io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:173)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at deployment.business-central.war//org.uberfire.ext.security.server.SecureHeadersFilter.doFilter(SecureHeadersFilter.java:110)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at deployment.business-central.war//org.uberfire.ext.security.server.SecurityIntegrationFilter.doFilter(SecurityIntegrationFilter.java:70)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.core@2.1.0.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
> at io.undertow.core@2.1.0.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months