August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13779) MicroProfile Metrics tests started to fail since changes in ConfigSource

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13779?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFLY-13779: ------------------------------------ When is the `config.source.properties.path` system property set? With https://github.com/wildfly/wildfly/pull/13247 changes, the config source can now be read by other subsystems before any deployment is done. If the sys prop was set during deployment while the config source was configured by the subsystems, that would be an issue in the test fixture. > MicroProfile Metrics tests started to fail since changes in ConfigSource > ------------------------------------------------------------------------ > > Key: WFLY-13779 > URL: https://issues.redhat.com/browse/WFLY-13779 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: Sultan Zhantemirov > Assignee: Jeff Mesnil > Priority: Major > > WildFly build: 21.0.0.Beta1-SNAPSHOT > Java: oracle-java-11 > A several failures appeared in our small standalone test suite [1] for MicroProfile on WF/EAP. To be more specific, a few failures in MP Metrics that have one common cause: > {noformat} > java.lang.RuntimeException: config.source.properties.path property not defined > {noformat} > caused by line [2]. > I have a reason to believe that this PR [3] could be reason of these failures. What should be done in this case? > Thank you. > [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite/tree/master/m... > [2] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite/blob/8b726042... > [3] - https://github.com/wildfly/wildfly/pull/13247 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up

by Alojzij Blatnik (Jira)

[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ] Alojzij Blatnik commented on WFLY-13808: ---------------------------------------- Hi. Thanks for the information. I attached the patch here. It can be applied on top of wildfly-core, tag 12.0.3.Final. Br. [^diff.patch] > Make HTTP server available during deployment when starting up > ------------------------------------------------------------- > > Key: WFLY-13808 > URL: https://issues.redhat.com/browse/WFLY-13808 > Project: WildFly > Issue Type: Bug > Affects Versions: 20.0.1.Final > Reporter: Alojzij Blatnik > Assignee: Brian Stansberry > Priority: Major > Attachments: diff.patch > > > HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase. > That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly). > I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up

by Alojzij Blatnik (Jira)

[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ] Alojzij Blatnik updated WFLY-13808: ----------------------------------- Attachment: diff.patch > Make HTTP server available during deployment when starting up > ------------------------------------------------------------- > > Key: WFLY-13808 > URL: https://issues.redhat.com/browse/WFLY-13808 > Project: WildFly > Issue Type: Bug > Affects Versions: 20.0.1.Final > Reporter: Alojzij Blatnik > Assignee: Brian Stansberry > Priority: Major > Attachments: diff.patch > > > HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase. > That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly). > I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13810) Intermittent failure in ExternalizerTestCase

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13810?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13810: --------------------------------------- Assignee: Brian Stansberry (was: Paul Ferraro) > Intermittent failure in ExternalizerTestCase > -------------------------------------------- > > Key: WFLY-13810 > URL: https://issues.redhat.com/browse/WFLY-13810 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13810) Intermittent failure in ExternalizerTestCase

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13810?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFLY-13810 at 8/30/20 6:17 PM: ------------------------------------------------------------------ Two more failures. I'm bumping this to Critical as this kind of wiring problem should not be happening. https://ci.wildfly.org/viewLog.html?buildId=219289&buildTypeId=WF_PullReq... was (Author: brian.stansberry): Two more failures. I'm bumping this to Critical as this kind of wiring problem should not be happening. > Intermittent failure in ExternalizerTestCase > -------------------------------------------- > > Key: WFLY-13810 > URL: https://issues.redhat.com/browse/WFLY-13810 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Priority: Critical > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13810) Intermittent failure in ExternalizerTestCase

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13810?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13810: ------------------------------------ Priority: Critical (was: Major) Two more failures. I'm bumping this to Critical as this kind of wiring problem should not be happening. > Intermittent failure in ExternalizerTestCase > -------------------------------------------- > > Key: WFLY-13810 > URL: https://issues.redhat.com/browse/WFLY-13810 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Priority: Critical > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13774) Difference in OpenTracing subsystem standard configuration leads to the tests failures

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13774?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13774: ------------------------------------ Component/s: Build System > Difference in OpenTracing subsystem standard configuration leads to the tests failures > --------------------------------------------------------------------------------------- > > Key: WFLY-13774 > URL: https://issues.redhat.com/browse/WFLY-13774 > Project: WildFly > Issue Type: Bug > Components: Build System, MP OpenTracing > Reporter: Sultan Zhantemirov > Assignee: Emmanuel Hugonnet > Priority: Major > > Since OpenTracing has been introduced, `standalone.xml` had the following OT SmallRye subsystem configuration: > {noformat} > <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0" default-tracer="jaeger"> > <jaeger-tracer name="jaeger"> > <sampler-configuration sampler-type="const" sampler-param="1.0"/> > </jaeger-tracer> > </subsystem> > {noformat} > With WildFly 19 and later we also have `standalone-microprofile.xml` configuration file which is used by default in MicroProfile test suite [1]. It has the following configuration: > {noformat} > <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0"/> > {noformat} > As it is recommended in documentation [2] it's better to define missing Jaeger properties (_sampler type _and _sampler param_) in order to sample every request. Sampling every request is needed by MicroProfile test suite OpenTracing basic tests. > A question is: will `standalone-microprofile.xml` configuration file have the wider OT subsystem configuration? Or do the tests have to define additional attributes in subsystem by themselves? > Thank you. > [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite#target-distri... > [2] - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13808: ----------------------------------------- This isn't a bug; it was deliberately done. Accepting requests over the network while the server is starting results in requests hitting incompletely started resources and getting random errors. WFCORE-4291 is a Feature Request to add an ability to turn off this behavior; it sounds like you are looking for a similar thing. There is no diff.patch attached. https://github.com/bstansberry/wildfly-core/tree/WFCORE-4291 is the work I did on it before I had to move away from it. If you have any suggestions they're welcome. I expect the issue will be resolved for WildFly 22. > Make HTTP server available during deployment when starting up > ------------------------------------------------------------- > > Key: WFLY-13808 > URL: https://issues.redhat.com/browse/WFLY-13808 > Project: WildFly > Issue Type: Bug > Affects Versions: 20.0.1.Final > Reporter: Alojzij Blatnik > Assignee: Brian Stansberry > Priority: Major > > HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase. > That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly). > I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFLY-13808. ------------------------------------- Resolution: Duplicate Issue > Make HTTP server available during deployment when starting up > ------------------------------------------------------------- > > Key: WFLY-13808 > URL: https://issues.redhat.com/browse/WFLY-13808 > Project: WildFly > Issue Type: Bug > Affects Versions: 20.0.1.Final > Reporter: Alojzij Blatnik > Assignee: Brian Stansberry > Priority: Major > > HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase. > That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly). > I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13774) Difference in OpenTracing subsystem standard configuration leads to the tests failures

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13774?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13774: --------------------------------------- Component/s: MP OpenTracing (was: Build System) Assignee: Emmanuel Hugonnet (was: Brian Stansberry) > Difference in OpenTracing subsystem standard configuration leads to the tests failures > --------------------------------------------------------------------------------------- > > Key: WFLY-13774 > URL: https://issues.redhat.com/browse/WFLY-13774 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Reporter: Sultan Zhantemirov > Assignee: Emmanuel Hugonnet > Priority: Major > > Since OpenTracing has been introduced, `standalone.xml` had the following OT SmallRye subsystem configuration: > {noformat} > <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0" default-tracer="jaeger"> > <jaeger-tracer name="jaeger"> > <sampler-configuration sampler-type="const" sampler-param="1.0"/> > </jaeger-tracer> > </subsystem> > {noformat} > With WildFly 19 and later we also have `standalone-microprofile.xml` configuration file which is used by default in MicroProfile test suite [1]. It has the following configuration: > {noformat} > <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0"/> > {noformat} > As it is recommended in documentation [2] it's better to define missing Jaeger properties (_sampler type _and _sampler param_) in order to sample every request. Sampling every request is needed by MicroProfile test suite OpenTracing basic tests. > A question is: will `standalone-microprofile.xml` configuration file have the wider OT subsystem configuration? Or do the tests have to define additional attributes in subsystem by themselves? > Thank you. > [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite#target-distri... > [2] - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 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 August 2020