May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4969) Upgrade XNIO to 3.8.1.Final

by Flavia Rainone (Jira)

Flavia Rainone created WFCORE-4969: -------------------------------------- Summary: Upgrade XNIO to 3.8.1.Final Key: WFCORE-4969 URL: https://issues.redhat.com/browse/WFCORE-4969 Project: WildFly Core Issue Type: Component Upgrade Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 12.0.0.Beta3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5333) Allow to customize rule names in guided decision table editor

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5333?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-5333: --------------------------------- Description: Add a column into the GDST where you can set the rule name for the rule that is generated from that row. > Allow to customize rule names in guided decision table editor > ------------------------------------------------------------- > > Key: DROOLS-5333 > URL: https://issues.redhat.com/browse/DROOLS-5333 > Project: Drools > Issue Type: Feature Request > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > Add a column into the GDST where you can set the rule name for the rule that is generated from that row. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5333) Allow to customize rule names in guided decision table editor

by Toni Rikkola (Jira)

Toni Rikkola created DROOLS-5333: ------------------------------------ Summary: Allow to customize rule names in guided decision table editor Key: DROOLS-5333 URL: https://issues.redhat.com/browse/DROOLS-5333 Project: Drools Issue Type: Feature Request Reporter: Toni Rikkola Assignee: Toni Rikkola -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13473) Missing repositories in generated poms for MP QS in EAP

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/WFLY-13473?page=com.atlassian.jira.plugi... ] Martin Stefanko commented on WFLY-13473: ---------------------------------------- [~emmartins] microprofile-openapi doesn't contain the from-scratch instructions so it is not included in the PR. > Missing repositories in generated poms for MP QS in EAP > ------------------------------------------------------- > > Key: WFLY-13473 > URL: https://issues.redhat.com/browse/WFLY-13473 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Reporter: Eduardo Martins > Assignee: Martin Stefanko > Priority: Blocker > > The QS in EAP XP 1.0.0.GA-CR1 contain instructions that create project from scratch using mvn archetype. Such projects do not have repositories defined that are needed for QS and are defined in QS parent pom: > {code} > <repositories> > <repository> > <releases> > <enabled>true</enabled> > <updatePolicy>never</updatePolicy> > </releases> > <snapshots> > <enabled>true</enabled> > <updatePolicy>never</updatePolicy> > </snapshots> > <id>jboss-public-repository-group</id> > <name>JBoss Public Repository Group</name> > <url>${maven.repository.url}</url> > <layout>default</layout> > </repository> > <repository> > <releases> > <enabled>true</enabled> > <updatePolicy>never</updatePolicy> > </releases> > <snapshots> > <enabled>true</enabled> > <updatePolicy>never</updatePolicy> > </snapshots> > <id>jboss-enterprise-maven-repository</id> > <name>JBoss Enterprise Maven Repository</name> > <url>${maven.redhat.repository.url}</url> > <layout>default</layout> > </repository> > </repositories> > {code} > Without the repos defined, the BOMs and other dependencies that are not present in maven central won't be found. > Affected QS: > * microprofile-config > * microprofile-fault-tolerance > * microprofile-health > * microprofile-jwt > * microprofile-metrics > * microprofile-openapi > * microprofile-opentracing > * microprofile-rest-client -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13464) Change server startup documentation to reference local installation and standalone-microprofile.xml

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13464?page=com.atlassian.jira.plugi... ] Eduardo Martins updated WFLY-13464: ----------------------------------- Summary: Change server startup documentation to reference local installation and standalone-microprofile.xml (was: Usage of wildfly maven plugin in microprofile-openapi QS should reference JBOSS_HOME) > Change server startup documentation to reference local installation and standalone-microprofile.xml > --------------------------------------------------------------------------------------------------- > > Key: WFLY-13464 > URL: https://issues.redhat.com/browse/WFLY-13464 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 19.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > > The QS is included in EAP XP 1.0.0.GA-CR1 Quickstarts ZIP, but its instructions are WildFly specific. > (1) Use of WildFly instead of EAP on several places, e.g. title "Using MicroProfile OpenAPI in WildFly", introduction "This guide demonstrate how to use the MicroProfile OpenAPI functionality in WildFly" etc. > (2) Starting the server with unsupported method "mvn wildfly:run &". Please use standard section {{Start the JBoss EAP Standalone Server}} or use a similar steps to start the server. The same applies for {{mvn wildfly:execute-commands}}, {{mvn wildfly:shutdown -Dwildfly.reload=true}} and {{mvn wildfly:shutdown}} commands. > (3) When trying the WF commands with EAP XP1 server, they fail: > {code} > [nziakova@laptop microprofile-openapi]$ export JBOSS_HOME > [nziakova@laptop microprofile-openapi]$ mvn wildfly:run & > ... > [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:2.0.0.Final:run (default-cli) on project microprofile-openapi-quickstart: Execution default-cli of goal org.wildfly.plugins:wildfly-maven-plugin:2.0.0.Final:run failed: Failure to find org.wildfly:wildfly-dist:zip:7.3.1.GA-redhat-SNAPSHOT > {code} > (4) When trying standard server start, the QS works fine without the step {{Add support for MicroProfile OpenAPI by adding the requisite extension and subsystem.}} - is it needed for EAP? > {code} > EAP_HOME/bin/standalone.sh -c standalone-microprofile.xml > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4942) Upgrade Undertow to 2.1.1.Final fixes CVE-2020-10719

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFCORE-4942?page=com.atlassian.jira.plug... ] Flavia Rainone updated WFCORE-4942: ----------------------------------- Fix Version/s: 12.0.0.Beta3 > Upgrade Undertow to 2.1.1.Final fixes CVE-2020-10719 > ---------------------------------------------------- > > Key: WFCORE-4942 > URL: https://issues.redhat.com/browse/WFCORE-4942 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Lin Gao > Assignee: Flavia Rainone > Priority: Major > Fix For: 12.0.0.Beta3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4942) Upgrade Undertow to 2.1.1.Final fixes CVE-2020-10719

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFCORE-4942?page=com.atlassian.jira.plug... ] Flavia Rainone updated WFCORE-4942: ----------------------------------- Summary: Upgrade Undertow to 2.1.1.Final fixes CVE-2020-10719 (was: Upgrade Undertow to 2.1.1.Final) > Upgrade Undertow to 2.1.1.Final fixes CVE-2020-10719 > ---------------------------------------------------- > > Key: WFCORE-4942 > URL: https://issues.redhat.com/browse/WFCORE-4942 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Lin Gao > Assignee: Flavia Rainone > Priority: Major > Fix For: 12.0.0.Beta3 > > -- 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 edited comment on WFLY-13444 at 5/15/20 12:03 AM: -------------------------------------------------------------- Hi [~flavia.rainone], Attached new thread dump from my system. default I/O-77 and default I/O-35 are top consumers. !default io consuming snapshot.PNG|thumbnail! !default io consuming.PNG|thumbnail! [^threaddump-1589514505334.tdump] Can you please suggest any workaround for this. was (Author: ev.srinivas): Hi [~flavia.rainone], Attached new thread dump from my system. default I/O-77 and default I/O-35 are top consumers. !default io consuming snapshot.PNG|thumbnail! !default io consuming.PNG|thumbnail! [^threaddump-1589514505334.tdump] Can you please suggest any workaround for this. > 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: Remoting > Affects Versions: 10.1.0.Final > Reporter: Srinivas ev > Assignee: Flavia Rainone > Priority: Major > Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, default io consuming snapshot.PNG, default io consuming.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, threaddump-1589514505334.tdump, 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 commented on WFLY-13444: ------------------------------------ Hi [~flavia.rainone], Attached new thread dump from my system. default I/O-77 and default I/O-35 are top consumers. !default io consuming snapshot.PNG|thumbnail! !default io consuming.PNG|thumbnail! [^threaddump-1589514505334.tdump] Can you please suggest any workaround for this. > 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: Remoting > Affects Versions: 10.1.0.Final > Reporter: Srinivas ev > Assignee: Flavia Rainone > Priority: Major > Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, default io consuming snapshot.PNG, default io consuming.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, threaddump-1589514505334.tdump, 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 consuming snapshot.PNG default io consuming.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: Remoting > Affects Versions: 10.1.0.Final > Reporter: Srinivas ev > Assignee: Flavia Rainone > Priority: Major > Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, default io consuming snapshot.PNG, default io consuming.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, threaddump-1589514505334.tdump, 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

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