July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13631) MicroProfile-Health: HealthChecks from WARs within EARs cannot be found

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13631?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13631: --------------------------------------- Component/s: MP Health Assignee: Jeff Mesnil (was: Brian Stansberry) > MicroProfile-Health: HealthChecks from WARs within EARs cannot be found > ----------------------------------------------------------------------- > > Key: WFLY-13631 > URL: https://issues.redhat.com/browse/WFLY-13631 > Project: WildFly > Issue Type: Bug > Components: MP Health > Affects Versions: 20.0.0.Final > Reporter: Jens Borrmann > Assignee: Jeff Mesnil > Priority: Major > > We want to make use of Microprofile Health in our applications. These are deployed as EARs (due to customers' demand). HealthChecks from WARs within EARs are not displayed when accessing the health endpoint ([http://localhost:9990/health]) > With a simple example (such as [https://www.adam-bien.com/roller/abien/entry/simplest_possible_microprofi...]) I have the following situation > * Deploying as a WAR: Everything works fine > * Deploying as an EAR (containing the WAR) the following information is displayed: > {"status":"UP","checks":[\{"name":"ready-deployment.myapp.ear.microprofile.war","status":"UP"}]} > Remarks: > * Using the new and not deprecated /health/ready does not change anything > * Using OpenLiberty everything works fine -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13632) If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13632?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFLY-13632 at 7/6/20 9:21 PM: ----------------------------------------------------------------- [~mmusgrov] [~tomjenkinson] There can be more than one /subsystem=transactions/commit-markable-resource=* resource and the CMResourceAdd handler will install an instance of CMResourceService for each. Those *install* calls will happen in series (e.g. during boot) from a single thread, and no other management op can come in and add another commit-markable-resource=* resource at the same time. But installing an MSC Service is not the same as starting the service – MSC invokes the start method on services concurrently using its thread pool. So you can definitely get concurrent calls to CMResourceService.start(StartContext). was (Author: brian.stansberry): [~mmusgrov] [~tomjenkinson] There can be more than one /subsystem=transactions/commit-markable-resource=* resource and the CMResourceAdd handler will install an instance of CMResourceService for each. Those *install* calls will happen in series (e.g. during boot) from a single thread, and no other management op can come in and add resource another commit-markable-resource=* resource at the same time. But installing an MSC Service is not the same as starting the service – MSC invokes the start method on services concurrently using its thread pool. So you can definitely get concurrent calls to CMResourceService.start(StartContext). > If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13632 > URL: https://issues.redhat.com/browse/WFLY-13632 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > Inspecting https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... we can see that it will overwrite the map in https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... because it first get's a copy of a map (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... -> https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060...) so the maps won't be equal. > This will result in WildFly overwriting the list of resources that Narayana will treat as CMR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13632) If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13632?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13632: ----------------------------------------- My impression is the basic issue here is that CMResourceService is not dealing with the JTAEnvironmentBean in a thread safe manner. If so it can just synchronize on the bean instance (which should be shared across all CMResourceService instances) or if that's not wanted it can synchronize on a static lock object. > If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13632 > URL: https://issues.redhat.com/browse/WFLY-13632 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > Inspecting https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... we can see that it will overwrite the map in https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... because it first get's a copy of a map (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... -> https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060...) so the maps won't be equal. > This will result in WildFly overwriting the list of resources that Narayana will treat as CMR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13632) If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13632?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13632: ----------------------------------------- Re: a change to the data occurring after boot, if that's not supposed to happen CMResourceAdd is not really preventing it. Either during or after boot it will install a CMResourceService. But then if it's post-boot it puts the server in reload-required state, which is odd because it just updated the runtime services. Normally you do one or the other, not both. > If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13632 > URL: https://issues.redhat.com/browse/WFLY-13632 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > Inspecting https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... we can see that it will overwrite the map in https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... because it first get's a copy of a map (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... -> https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060...) so the maps won't be equal. > This will result in WildFly overwriting the list of resources that Narayana will treat as CMR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13632) If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13632?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13632: ----------------------------------------- [~mmusgrov] [~tomjenkinson] There can be more than one /subsystem=transactions/commit-markable-resource=* resource and the CMResourceAdd handler will install an instance of CMResourceService for each. Those *install* calls will happen in series (e.g. during boot) from a single thread, and no other management op can come in and add resource another commit-markable-resource=* resource at the same time. But installing an MSC Service is not the same as starting the service – MSC invokes the start method on services concurrently using its thread pool. So you can definitely get concurrent calls to CMResourceService.start(StartContext). > If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13632 > URL: https://issues.redhat.com/browse/WFLY-13632 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > Inspecting https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... we can see that it will overwrite the map in https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... because it first get's a copy of a map (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... -> https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060...) so the maps won't be equal. > This will result in WildFly overwriting the list of resources that Narayana will treat as CMR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5015) Create 'core-specific' variants of Galleon feature groups and packages that are 'overridden' in full WildFly

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-5015?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-5015: ------------------------------------- Fix Version/s: 13.0.0.Beta2 > Create 'core-specific' variants of Galleon feature groups and packages that are 'overridden' in full WildFly > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-5015 > URL: https://issues.redhat.com/browse/WFCORE-5015 > Project: WildFly Core > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 13.0.0.Beta2 > > > See [https://lists.jboss.org/pipermail/wildfly-dev/2020-June/007342.html... background. > For the wildfly-core galleon pack feature groups and packages that are 'overridden' in full WildFly, create a differently named variant in the galleon-common module that can be referenced in full WF. This eliminates the 'overriding/subclassing' and in a GAL-319 type future setup will allow the 'core' source item to be directly incorporated in the target FP in full without conflicting with an item with the same name in that target FP. > > Feature groups: > > domain-host-excludes > domain-interfaces > domain-profile > host-master > host-slave > host > standalone-profile > > Packages: > bin.common > bin.vaulttools > docs.licenses.merge > misc.common > misc.domain > misc.standalone > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5036) Improve support for conditionally-defined capabilities

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFCORE-5036?page=com.atlassian.jira.plug... ] Richard Achmatowicz updated WFCORE-5036: ---------------------------------------- Description: Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request. Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally registered, we can use OperationContext.hasOptionalCapability() to check if it is actually registered. So consuming is easy but setting up is hard. Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration. Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK. This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier. FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate. was: Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request. Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally defined, we can use OperationContext.hasOptionalCapability() to check if it is defined. So consuming is easy but setting up is hard. Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration. Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK. This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier. FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate. > Improve support for conditionally-defined capabilities > ------------------------------------------------------ > > Key: WFCORE-5036 > URL: https://issues.redhat.com/browse/WFCORE-5036 > Project: WildFly Core > Issue Type: Feature Request > Components: Management > Reporter: Richard Achmatowicz > Assignee: Jeff Mesnil > Priority: Major > > Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request. > Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally registered, we can use OperationContext.hasOptionalCapability() to check if it is actually registered. So consuming is easy but setting up is hard. > Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration. > Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK. > This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier. > FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate. > > > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5036) Improve support for conditionally-defined capabilities

by Richard Achmatowicz (Jira)

Richard Achmatowicz created WFCORE-5036: ------------------------------------------- Summary: Improve support for conditionally-defined capabilities Key: WFCORE-5036 URL: https://issues.redhat.com/browse/WFCORE-5036 Project: WildFly Core Issue Type: Feature Request Components: Management Reporter: Richard Achmatowicz Assignee: Jeff Mesnil Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request. Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally defined, we can use OperationContext.hasOptionalCapability() to check if it is defined. So consuming is easy but setting up is hard. Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration. Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK. This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier. FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13646) [GSS](7.3.z) Exception while exporting metrics during WildFly initialization

by Brad Maxwell (Jira)

Brad Maxwell created WFLY-13646: ----------------------------------- Summary: [GSS](7.3.z) Exception while exporting metrics during WildFly initialization Key: WFLY-13646 URL: https://issues.redhat.com/browse/WFLY-13646 Project: WildFly Issue Type: Bug Components: MP Metrics Affects Versions: 18.0.1.Final, 19.0.0.Beta2 Reporter: Brad Maxwell Assignee: Brian Stansberry 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

1
0
0 / 0

[JBoss JIRA] (JGRP-2315) ASYM_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/JGRP-2315?page=com.atlassian.jira.plugin... ] Paul Ferraro updated JGRP-2315: ------------------------------- Summary: ASYM_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures (was: ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures) > ASYM_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures > ---------------------------------------------------------------------------------------- > > Key: JGRP-2315 > URL: https://issues.redhat.com/browse/JGRP-2315 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 4.0.16 > > > If a message is received that needs to be decrypted, or if a message need to be encrypted, a cipher is taken from the queue. However, if a new coordinator concurrently sends a new secret key, it will clear and recreate the cipher queues. If the previous operation then puts its cipher back on the queue, the queue will now contain a cipher with the old secret key. This will result in random message decryption failures when a message encryption/decryption pulls the outdated cipher from the queue. > While this is mitigated somewhat by the caching of old cipher versions, newly joined members do not have the ability to read messages encrypted by outdated ciphers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

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 July 2020