March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4470) DMN DT Analysis check allowedValues from imported ItemDef

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4470?page=com.atlassian.jira.plug... ] Toshiya Kobayashi commented on DROOLS-4470: ------------------------------------------- Done by https://github.com/kiegroup/drools/commit/d84f19eb3bb0787d7f821c43cb9cafa... > DMN DT Analysis check allowedValues from imported ItemDef > --------------------------------------------------------- > > Key: DROOLS-4470 > URL: https://issues.redhat.com/browse/DROOLS-4470 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Toshiya Kobayashi > Priority: Minor > Labels: good-first-issue > Fix For: 7.35.0.Final > > > The domain analysis restricts the domain in case of allowedValues defined in the ItemDef. To be checked the domain restriction is properly working when the DT column domain is actually defined coming from an imported itemdef. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4874) Improve the WFLYSRV0002 error message

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4874?page=com.atlassian.jira.plug... ] Brian Stansberry reassigned WFCORE-4874: ---------------------------------------- Component/s: Server Assignee: Yeray Borges Santana (was: Brian Stansberry) Agreed re it being a WARN. I don't think we want a stack trace here (at least not above DEBUG) but including the e.toString() seems reasonable. > Improve the WFLYSRV0002 error message > ------------------------------------- > > Key: WFCORE-4874 > URL: https://issues.redhat.com/browse/WFCORE-4874 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Carlo de Wolf > Assignee: Yeray Borges Santana > Priority: Minor > > Currently WFLYSRV0002 is reported as an error and the associated exception is swallowed. > {noformat} > WFLYSRV0002: Could not read provided index > {noformat} > It should really be a warning with details of the exception. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13177) ManagedExecutorService: Wrong activeRequestCount at RequestController on RejectedExecutionException

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13177?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13177: --------------------------------------- Component/s: Concurrency Utilities (was: EE) (was: Server) Fix Version/s: 20.0.0.Beta1 Priority: Critical (was: Major) Assignee: Eduardo Martins (was: Brian Stansberry) > ManagedExecutorService: Wrong activeRequestCount at RequestController on RejectedExecutionException > --------------------------------------------------------------------------------------------------- > > Key: WFLY-13177 > URL: https://issues.redhat.com/browse/WFLY-13177 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 13.0.0.Final, 16.0.0.Final > Reporter: Guido Jäkel > Assignee: Eduardo Martins > Priority: Critical > Fix For: 20.0.0.Beta1 > > > On WF-13 and WF-16 we observe a serious bug of the RequestCount of the RequestController while using ManagedExecutorService.submit() or ...execute() in the edge case of a full queue. In this case, the caller gets a RejectedExecutionException, but in the RequestController, the number of active requests is erroneously incremented. > This will lead to a false and monotonously increasing number of active requests. And in case of a limitation configured by the maxRequestCount feature, which is best practice for production environments, over the time this will lead to deadlock of the RequestController and herewith the complete activity of the Wildfly at all. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13166) https connector / idletimeout / keep-alive settings

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13166?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13166: --------------------------------------- Component/s: Web (Undertow) Assignee: Flavia Rainone (was: Brian Stansberry) > https connector / idletimeout / keep-alive settings > --------------------------------------------------- > > Key: WFLY-13166 > URL: https://issues.redhat.com/browse/WFLY-13166 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Abdul Islam > Assignee: Flavia Rainone > Priority: Major > > Hi, > We're using Wildlfy v15.0.1 and external traffic reaches Wildfly app servers via a load balancer, lately we are seeing 502 gateway timeout for certain calls. One of the recommendation from load balancer support team is to enable keep-alive settings at the app server level to match the load balancer, we have a 15 min idle time out set on load balancer. It would be great if anyone has any insights or recommendations on this topic. We basically wish to match idle time on Wildfly to whats configured in our load balancer. > I can across the link below, please confirm if its applicable to Wildfly v15.0.1 > https://access.redhat.com/solutions/456733 > Thanks for your help in advance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4874) Improve the WFLYSRV0002 error message

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4874?page=com.atlassian.jira.plug... ] Brian Stansberry moved WFLY-13174 to WFCORE-4874: ------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-4874 (was: WFLY-13174) > Improve the WFLYSRV0002 error message > ------------------------------------- > > Key: WFCORE-4874 > URL: https://issues.redhat.com/browse/WFCORE-4874 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Carlo de Wolf > Assignee: Brian Stansberry > Priority: Minor > > Currently WFLYSRV0002 is reported as an error and the associated exception is swallowed. > {noformat} > WFLYSRV0002: Could not read provided index > {noformat} > It should really be a warning with details of the exception. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13212) Boot messages related to activation of MP subsystems are inconsistent

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13212?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13212: ----------------------------------------- I vote for reducing all of them to DEBUG. I hate those kinds of messages. > Boot messages related to activation of MP subsystems are inconsistent > --------------------------------------------------------------------- > > Key: WFLY-13212 > URL: https://issues.redhat.com/browse/WFLY-13212 > Project: WildFly > Issue Type: Bug > Components: MP Config, MP Fault Tolerance, MP JWT, MP OpenTracing > Affects Versions: 19.0.0.Beta3 > Reporter: Rostislav Svoboda > Assignee: Jeff Mesnil > Priority: Major > > Boot messages related to activation of MP subsystems are inconsistent in package names and used wording. > - MP Config and MP JWT use {{_private}} package, the remaining do not. > - MP Config and MP JWT say {{Activating WildFly MicroProfile}}, the majority of specs says {{Activating Eclipse MicroProfile }} > - MP FT and MP OT say {{Activating MicroProfile}}, the majority of specs says {{Activating Eclipse MicroProfile }} > - MP FT "Activating ..." message ends {{subsystem.}} but should be in sync with others - {{Subsystem}} - no comma at the end, upper case for the first letter > Packages and "Activating ..." messages should sync. > {code} > 21:43:44,506 INFO [org.wildfly.extension.microprofile.config.smallrye._private] (ServerService Thread Pool -- 48) WFLYCONF0001: Activating WildFly MicroProfile Config Subsystem > 21:43:44,527 INFO [org.wildfly.extension.microprofile.jwt.smallrye._private] (ServerService Thread Pool -- 51) WFLYJWT0001: Activating WildFly MicroProfile JWT Subsystem > {code} > {code} > 21:43:44,523 INFO [org.wildfly.extension.microprofile.openapi.smallrye] (ServerService Thread Pool -- 53) WFLYMPOAI0001: Activating Eclipse MicroProfile OpenAPI Subsystem > 21:43:44,531 INFO [org.wildfly.extension.microprofile.health.smallrye] (ServerService Thread Pool -- 50) WFLYHEALTH0001: Activating Eclipse MicroProfile Health Subsystem > 21:43:44,533 INFO [org.wildfly.extension.microprofile.metrics.smallrye] (ServerService Thread Pool -- 52) WFLYMETRICS0001: Activating Eclipse MicroProfile Metrics Subsystem > 21:43:44,531 INFO [org.wildfly.extension.microprofile.faulttolerance] (ServerService Thread Pool -- 49) WFLYMPFTEXT0001: Activating MicroProfile Fault Tolerance subsystem. > {code} > CC [~brian.stansberry] / [~maeste] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13213) Authentication required on admin console with Chrome

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13213?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13213: --------------------------------------- Component/s: Web Console (was: Management) Assignee: Harald Pehl (was: Jeff Mesnil) > Authentication required on admin console with Chrome > ---------------------------------------------------- > > Key: WFLY-13213 > URL: https://issues.redhat.com/browse/WFLY-13213 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 10.0.0.Final, 17.0.1.Final > Reporter: jean-philippe muller > Assignee: Harald Pehl > Priority: Major > > When I try to access the Administration Console on a Wildfly 10 ou 17 (in standalone mode) via the Chrome browser or the "Edge Chromium" browser, I get a warning message which says "Authentication required". But no popup to enter credentials. > The messages are a bit different with WF10 and 17. > WF10, it says "The management console could not be loaded" and "Authentication required" > WF17, "Bootstrap error", "Authentication required" and "management console could not be loaded..." > See discussion: https://groups.google.com/forum/#!topic/wildfly/PT-Wl_62bgE -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13188) Exception while exporting metrics during WildFly initialization

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13188?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13188: ----------------------------------------- [~moghaddam] Is this easy to reproduce for you? It's not for me. AFAICT there should be a very small window where this can happen. Do all the log WARNINGs include the deployment part of a resource address? For example: ("deployment" => "application.ear"), Does your server have a multiple deployments, some of which take a long time to deploy? I ask because that is one situation where the window where this happens might be longer. > Exception while exporting metrics during WildFly initialization > --------------------------------------------------------------- > > Key: WFLY-13188 > URL: https://issues.redhat.com/browse/WFLY-13188 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Affects Versions: 18.0.1.Final, 19.0.0.Beta2 > Reporter: Ehsan Zaery Moghaddam > Assignee: Jeff Mesnil > Priority: Major > Labels: Microprofile > > When the open tracing system is enabled and some metrics are exposed, if when the WildFly is in the startup process, the Prometheus server calls the /metrics endpoint, WildFly prints a stacktrace for each metrics that is has detected (i.e. more than thousands) with the following message: > *WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available > * > In some cases the error persists, even after the server startup is done and we need to restart the WildFly; but we couldn't find the exact scenario for that. > Here is an example for wildfly_jpa_second_level_cache_size_in_memory metric: > {code} > 2020-03-02 09:38:06,739 WARN [management I/O-2] [metrics] Unable to export metric wildfly_jpa_second_level_cache_size_in_memory: java.lang.IllegalStateException: WFLYMETRICS0003: Unable to read attribute second-level-cache-size-in-memory on [ > ("deployment" => "application.ear"), > ("subdeployment" => "application-persistence.jar"), > ("subsystem" => "jpa"), > ("hibernate-persistence-unit" => "application.ear/application-persistence.jar#app"), > ("entity-cache" => "com.app.persistence.entity.Country") > ]: "WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available". > at org.wildfly.extension.microprofile.metrics.MetricCollector.readAttributeValue(MetricCollector.java:303) > at org.wildfly.extension.microprofile.metrics.MetricCollector.access$200(MetricCollector.java:70) > at org.wildfly.extension.microprofile.metrics.MetricCollector$2.getValue(MetricCollector.java:174) > at org.wildfly.extension.microprofile.metrics.MetricCollector$2.getValue(MetricCollector.java:171) > at io.smallrye.metrics.exporters.OpenMetricsExporter.createSimpleValueLine(OpenMetricsExporter.java:445) > at io.smallrye.metrics.exporters.OpenMetricsExporter.exposeEntries(OpenMetricsExporter.java:178) > at io.smallrye.metrics.exporters.OpenMetricsExporter.getEntriesForScope(OpenMetricsExporter.java:150) > at io.smallrye.metrics.exporters.OpenMetricsExporter.exportAllScopes(OpenMetricsExporter.java:101) > at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:116) > at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:73) > at org.wildfly.extension.microprofile.metrics.MetricsContextService$1.handleRequest(MetricsContextService.java:81) > at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51) > at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35) > at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91) > at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211) > at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92) > at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78) > at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49) > at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57) > at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75) > at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:666) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376) > 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.HttpReadListener.handleEvent(HttpReadListener.java:59) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5164) Automate with ansible HACep deploy

by Massimiliano Dessi (Jira)

Massimiliano Dessi created DROOLS-5164: ------------------------------------------ Summary: Automate with ansible HACep deploy Key: DROOLS-5164 URL: https://issues.redhat.com/browse/DROOLS-5164 Project: Drools Issue Type: Task Reporter: Massimiliano Dessi Assignee: Massimiliano Dessi Automate with Ansible the setup from scratch and for every new End user test on CRC -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2130) Log: cache result of log.isTraceEnabled()

by Francisco De Melo Junior (Jira)

[ https://issues.redhat.com/browse/JGRP-2130?page=com.atlassian.jira.plugin... ] Francisco De Melo Junior commented on JGRP-2130: ------------------------------------------------ I believe this affects UDP, TCP besides NAKACK2 and UNICAST3 > Log: cache result of log.isTraceEnabled() > ----------------------------------------- > > Key: JGRP-2130 > URL: https://issues.redhat.com/browse/JGRP-2130 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Labels: CR1 > Fix For: 4.0 > > > e.g. > {noformat} > boolean trace=log.isTraceEnabled(); > loop { > if(trace) ... > } > {noformat} > Unfortunately, {{isTraceEnabled()}} is not free in most scenarios, so the cost of invoking this method should be amortized over multiple calls. > I don't want to cache this at a global level, or else we wouldn't be able to change the log level at runtime... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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 March 2020