May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5313) Upgrading Drools Version from 6.2.0.Final to 7.31.0.Final

by Anuj Khare (Jira)

Anuj Khare created DROOLS-5313: ---------------------------------- Summary: Upgrading Drools Version from 6.2.0.Final to 7.31.0.Final Key: DROOLS-5313 URL: https://issues.redhat.com/browse/DROOLS-5313 Project: Drools Issue Type: Quality Risk Components: build Reporter: Anuj Khare Assignee: Ant Stephenson I am trying to upgrade below jars from 6.2.0.Final to 7.31.0.Final. Below are the issues am facing: 1. With 6.2.0.Final it takes 8 mins to compile all the rules, where as with 7.31.0.Final it takes nearly 40 mins 2. Some of the rules give wrong results when compiled with 7.31.0.Final Can some one help if and what needs to be taken care while upgrading drools jars. Jars am trying to upgrade are: org.drools.drools-compiler org.kie.kie-api org.jbpm.jbpm-flow org.jbpm.jbmpm-bpmn2 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11130) javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated (New Java EE 8 Security)

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFLY-11130?page=com.atlassian.jira.plugi... ] Moulali Shikalwadi edited comment on WFLY-11130 at 5/11/20 6:21 AM: -------------------------------------------------------------------- [~lukaskuzmiak], Could you please confirm is this issue still persists? > javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated (New Java EE 8 Security) > ------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-11130 > URL: https://issues.redhat.com/browse/WFLY-11130 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 14.0.1.Final > Reporter: Instantiation Exception > Assignee: Moulali Shikalwadi > Priority: Major > > I tried to use new Java EE 8 Security API and noticed that javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated. But according to JavaDoc it should return false in this situation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5312) Investigate performance of Optaplanner's GroupBy

by Mario Fusco (Jira)

Mario Fusco created DROOLS-5312: ----------------------------------- Summary: Investigate performance of Optaplanner's GroupBy Key: DROOLS-5312 URL: https://issues.redhat.com/browse/DROOLS-5312 Project: Drools Issue Type: Task Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread

by Srinivas ev (Jira)

[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ] Srinivas ev commented on WFLY-13444: ------------------------------------ Hi [~pferraro], After some time, observed one more new default I/O thread is kicked in. This is also consuming high CPU of almost 50%. Is there any reason for these threads to be kicked in. !default IO thread 73.PNG|thumbnail! > Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread > ------------------------------------------------------------------- > > Key: WFLY-13444 > URL: https://issues.redhat.com/browse/WFLY-13444 > Project: WildFly > Issue Type: Bug > Components: Clustering, IO > Affects Versions: 10.1.0.Final > Reporter: Srinivas ev > Assignee: Paul Ferraro > Priority: Blocker > Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, top command output.PNG > > > Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming. > Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously. > Wildfly 10.1.0 Final > Java - > openjdk version "1.8.0_232" > OpenJDK Runtime Environment (build 1.8.0_232-b09) > OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode > --------------------------------------------------------------------------------------------------- > at java.lang.Throwable.fillInStackTrace(Native Method) > at java.lang.Throwable.fillInStackTrace(Throwable.java:784) > at java.lang.Throwable.<init>(Throwable.java:251) > at java.lang.Exception.<init>(Exception.java:54) > at java.io.IOException.<init>(IOException.java:47) > at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52) > at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022) > at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65) > at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393) > at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547) > at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > ------------------------------------------------------------------------------------------- > at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method) > at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:515) > ----------------------------------------------------------------------------------- -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread

by Srinivas ev (Jira)

[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ] Srinivas ev updated WFLY-13444: ------------------------------- Attachment: default IO thread 73.PNG > Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread > ------------------------------------------------------------------- > > Key: WFLY-13444 > URL: https://issues.redhat.com/browse/WFLY-13444 > Project: WildFly > Issue Type: Bug > Components: Clustering, IO > Affects Versions: 10.1.0.Final > Reporter: Srinivas ev > Assignee: Paul Ferraro > Priority: Blocker > Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, top command output.PNG > > > Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming. > Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously. > Wildfly 10.1.0 Final > Java - > openjdk version "1.8.0_232" > OpenJDK Runtime Environment (build 1.8.0_232-b09) > OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode > --------------------------------------------------------------------------------------------------- > at java.lang.Throwable.fillInStackTrace(Native Method) > at java.lang.Throwable.fillInStackTrace(Throwable.java:784) > at java.lang.Throwable.<init>(Throwable.java:251) > at java.lang.Exception.<init>(Exception.java:54) > at java.io.IOException.<init>(IOException.java:47) > at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52) > at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022) > at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65) > at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393) > at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547) > at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > ------------------------------------------------------------------------------------------- > at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method) > at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:515) > ----------------------------------------------------------------------------------- -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5309) ServiceResponse is not properly serialized when ExecutionResultImpl

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5309?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5309: -------------------------------- Sprint: 2020 Week 19-21 (from May 4) > ServiceResponse is not properly serialized when ExecutionResultImpl > ------------------------------------------------------------------- > > Key: DROOLS-5309 > URL: https://issues.redhat.com/browse/DROOLS-5309 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.29.0.Final, 7.33.0.Final > Reporter: Steve Davidson > Assignee: Mario Fusco > Priority: Major > Labels: drools, kie > Attachments: KieIssueDemo.tbz > > > When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON wraps the ServiceResponse. The resulting message looks like: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "ExecutionResultImpl" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} > A good response doesn't wrap the ServiceResponse: > {code:json} > { > "type" : "SUCCESS", > "msg" : "List of created containers", > "result" : { > "kie-containers" : { > "kie-container" : [ { > "container-id" : "Kie Demo: kie-server", > "release-id" : { > "group-id" : "com.j2eeguys.demo", > "artifact-id" : "KieIssueDemo", > "version" : "0.1.0-SNAPSHOT" > }, > "resolved-release-id" : { > "group-id" : "com.j2eeguys.demo", > "artifact-id" : "KieIssueDemo", > "version" : "0.1.0-SNAPSHOT" > }, > "status" : "STARTED", > "scanner" : { > "status" : "DISPOSED", > "poll-interval" : null > }, > "config-items" : [ ], > "messages" : [ { > "severity" : "INFO", > "timestamp" : { > "java.util.Date" : 1588885337926 > }, > "content" : [ "Container Kie Demo: kie-server successfully created with module com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT." ] > } ], > "container-alias" : null > } ] > } > } > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4367) Tests in drools coverage are not really using the executable model

by Daniel Rosa (Jira)

[ https://issues.redhat.com/browse/DROOLS-4367?page=com.atlassian.jira.plug... ] Daniel Rosa updated DROOLS-4367: -------------------------------- Sprint: 2019 Week 47-49 (from Nov 18), 2019 Week 50-52 (from Dec 9), 2020 Week 13-15 (from Mar 23) (was: 2019 Week 47-49 (from Nov 18), 2019 Week 50-52 (from Dec 9), 2020 Week 13-15 (from Mar 23), 2020 Week 19-21 (from May 4)) > Tests in drools coverage are not really using the executable model > ------------------------------------------------------------------ > > Key: DROOLS-4367 > URL: https://issues.redhat.com/browse/DROOLS-4367 > Project: Drools > Issue Type: Bug > Reporter: Luca Molteni > Assignee: Daniel Rosa > Priority: Minor > > Such as > https://github.com/kiegroup/drools/blob/ba9c79c4bfaf9cfc1ec2363bee3865c3d... > Even if the test itself is parametrized, in the body it calls directly buildAll therefore discarding the executable model -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1144) Add openstack client jenkins slave

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1144: ------------------------------------ Summary: Add openstack client jenkins slave Key: SWSQE-1144 URL: https://issues.redhat.com/browse/SWSQE-1144 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta We need jenkins slave with openstack client installed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13420) Enable Elytron mixed domain test suites

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13420?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-13420: ---------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13253, https://github.com/wildfly/wildfly/pull/13257 (was: https://github.com/wildfly/wildfly/pull/13253) > Enable Elytron mixed domain test suites > --------------------------------------- > > Key: WFLY-13420 > URL: https://issues.redhat.com/browse/WFLY-13420 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Yeray Borges Santana > Assignee: Yeray Borges Santana > Priority: Major > > Elytron mixed domain test suites were ignored by WFLY-8926 until WFCORE-2882 is integrated. > Those test suites can be unignored now. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13447) Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13447?page=com.atlassian.jira.plugi... ] Masafumi Miura updated WFLY-13447: ---------------------------------- Steps to Reproduce: 1. Execute the attached "generate-cli.sh" to generate JBoss CLI script (test.cli) which configures many filter-ref definistion. 2. Execute the generated "test.cli" {code} ./bin/jboss-cli.sh --file=/path/to/test.cli {code} 3. Start JBoss EAP 7 with the configuration {code} ./bin/standalone.sh -c standalone-test.xml {code} 4. Send a request {code} curl -v http://localhost:8080/ {code} The request fails with "500 Internal Server Error" because of "IllegalArgumentException: Comparison method violates its general contract!" Workaround Description: If you really need to define many filter-ref definition, you can work around this issue by adding the following to JAVA_OPTS in standalone.conf: {code} JAVA_OPTS="$JAVA_OPTS -Djava.util.Arrays.useLegacyMergeSort=true" {code} > Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13447 > URL: https://issues.redhat.com/browse/WFLY-13447 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 19.1.0.Final > Reporter: Masafumi Miura > Assignee: Flavia Rainone > Priority: Major > Attachments: generate-cli.sh, test.cli > > > When many filter-ref are defined (theoretically more than 32 filter-ref are defined), Undertow has a possibility fail to process a request with the following ERROR: > {code} > ERROR [io.undertow.request] (default I/O-12) UT005071: Undertow request failed HttpServerExchange{ GET /}: java.lang.IllegalArgumentException: Comparison method violates its general contract! > at java.util.TimSort.mergeLo(TimSort.java:777) > at java.util.TimSort.mergeAt(TimSort.java:514) > at java.util.TimSort.mergeCollapse(TimSort.java:441) > at java.util.TimSort.sort(TimSort.java:245) > at java.util.Arrays.sort(Arrays.java:1512) > at java.util.ArrayList.sort(ArrayList.java:1462) > at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:93) > at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:174) > at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:263) > at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:430) > at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54) > at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78) > at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49) > at org.wildfly.extension.undertow.Server$DefaultHostHandler.handleRequest(Server.java:190) > at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211) > at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:102) > at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:370) > at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255) > at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178) > at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) > {code} > The IllegalArgumentException happens when Java's TimSort algorithm happens to detect inconsistency in the comparison. This happens because [the comparator implementation for sorting filter-ref|https://github.com/wildfly/wildfly/blob/19.1.0.Final/undertow/...] does not follow the contract for comparison. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020