January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12949) Upgrade WildFly-Http-Client from 1.0.18.final to 1.1.0.Final

by Richard Opalka (Jira)

[ https://issues.redhat.com/browse/WFLY-12949?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFLY-12949: ---------------------------------- Summary: Upgrade WildFly-Http-Client from 1.0.18.final to 1.1.0.Final (was: Upgrade WildFly-Http-Client from 1.0.18.final to 1.0.19.Final) > Upgrade WildFly-Http-Client from 1.0.18.final to 1.1.0.Final > ------------------------------------------------------------ > > Key: WFLY-12949 > URL: https://issues.redhat.com/browse/WFLY-12949 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 19.0.0.Beta1 > > > This component upgrade incorporates: > > New features: > * [WEJBHTTP-34] EJB over HTTP discovery support > > Bug fixes: > * [WEJBHTTP-31] Notify waiters when WildflyClientInputStream read listener reads 0 regardless of whether pooled.getBuffer().hasRemaining() returns true or false > * [WEJBHTTP-32] Remove duplicate notifyAll invocation from WildflyClientInputStream read listener > * [WEJBHTTP-35] Discovery result is not completed if no HTTP connections are configured -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12972) MP Fault Tolerance - Fault Tolerance is missing logging code when activated

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12972?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-12972: --------------------------------------- I can see if we can get this done in the new impl. > MP Fault Tolerance - Fault Tolerance is missing logging code when activated > --------------------------------------------------------------------------- > > Key: WFLY-12972 > URL: https://issues.redhat.com/browse/WFLY-12972 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Reporter: Miroslav Novak > Assignee: Radoslav Husar > Priority: Minor > > If MP FT is activated by deployment then INFO log is missing logging code: > {code} > 10:18:31,626 INFO [io.smallrye.faulttolerance.HystrixExtension] (MSC service thread 1-1) MicroProfile: Fault Tolerance activated > {code} > Logging code should be added. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12925) MP FT retry.callsSucceededRetried.total metric has wrong value

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12925?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-12925: --------------------------------------- Needs 2.1.5 or newer upgrade. > MP FT retry.callsSucceededRetried.total metric has wrong value > -------------------------------------------------------------- > > Key: WFLY-12925 > URL: https://issues.redhat.com/browse/WFLY-12925 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Major > > When method annotated with @Fallback and @Retry fails, MP FT retry.callsSucceededRetried.total metric even though the method fails everytime and falls into a fallback method. > The issue is only in the metric. The method is retried as expected and fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/159 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12924?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-12924: --------------------------------------- Needs 2.1.5 or newer upgrade. > MP FT fallback metric is incremented wrongly > -------------------------------------------- > > Key: WFLY-12924 > URL: https://issues.redhat.com/browse/WFLY-12924 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Major > > When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. > The issue is only in the metric. Fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/158 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-158) Artemis 2.7.0 logs password for STOMP protocol in clear text in debug logs

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-158?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFWIP-158: -------------------------------------- Assignee: Emmanuel Hugonnet (was: Justin Bertram) [~ehugonnet] Please link this to the EAP7 for a still WIP feature being developed on a topic branch, or move it to another issue tracker like JBEAP that tracks work on the main code branches. > Artemis 2.7.0 logs password for STOMP protocol in clear text in debug logs > -------------------------------------------------------------------------- > > Key: WFWIP-158 > URL: https://issues.redhat.com/browse/WFWIP-158 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Emmanuel Hugonnet > Priority: Major > > If TRACE log is enabled for {{org.apache.activemq.artemis}} then StompProtoco is logging password in clear text: > {code} > 13:48:06,488 DEBUG [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) BeanUtils.populate(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, {needClientAuth=tru > e, trustStorePassword=hornetqexample, keyStorePassword=hornetqexample, port=6445, sslEnabled=true, host=127.0.0.1, trustStorePath=/home/hudson/hudson_workspace/workspace/eap-7.x-messaging-weekly-common-ssl/eap-t > estsuite/jboss-hornetq-testsuite/tests-eap7/src/test/resources/org/jboss/qa/hornetq/test/transportprotocols/hornetq.example.truststore, keyStorePath=/home/hudson/hudson_workspace/workspace/eap-7.x-messaging-week > ly-common-ssl/eap-testsuite/jboss-hornetq-testsuite/tests-eap7/src/test/resources/org/jboss/qa/hornetq/test/transportprotocols/hornetq.example.keystore}) > ... > 13:48:06,488 TRACE [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) setProperty(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, trustStorePassword, horn > etqexample) > ... > 13:48:06,489 TRACE [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) setProperty(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, keyStorePassword, hornet > qexample) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-134) Bad WARN messages: AMQ222211: Storage is back to stable now...

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-134?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFWIP-134: ---------------------------------------- [~ehugonnet] Please link this to the EAP7 for a still WIP feature being developed on a topic branch, or move it to another issue tracker like JBEAP that tracks work on the main code branches. Or resolve if out of date. > Bad WARN messages: AMQ222211: Storage is back to stable now... > -------------------------------------------------------------- > > Key: WFWIP-134 > URL: https://issues.redhat.com/browse/WFWIP-134 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Francesco Nigro > Priority: Major > > There are unwanted WARN messages: > {code} > 13:47:48,158 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 15.0.0.Alpha1-SNAPSHOT (WildFly Core 7.0.0.Alpha4) started in 8017ms - Started 495 of 723 services (489 services are lazy, passive or on-demand) > 13:47:50,235 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222183: Blocking message production on address 'jms.queue.InQueue'; size is currently: 10,635,300 bytes; max-size-bytes on address: 10,485,760, global-max-size is 10,635,300 > 13:47:52,642 WARN [org.apache.activemq.artemis.core.server] (Thread-4 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage. > 13:47:57,642 WARN [org.apache.activemq.artemis.core.server] (Thread-15 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage. > ... > {code} > when server has configured {{global-max-memory-size}} and address-full-policy to BLOCK. Once {{global-max-memory-size}} then starts to log above warnings which with max-disk-usage. Which is not correct as no disk limitation was reached. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-273) Templates at eap-cd-dev branch still referring to image version 17

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-273?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFWIP-273: ---------------------------------------- [~luck3y] This should not be in WFWIP. It's not about work on a WIP feature in a topic branch. Perhaps it was a topic branch when originally filed but now it should be in CLOUD. > Templates at eap-cd-dev branch still referring to image version 17 > ------------------------------------------------------------------ > > Key: WFWIP-273 > URL: https://issues.redhat.com/browse/WFWIP-273 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Ken Wills > Priority: Critical > > https://github.com/jboss-container-images/jboss-eap-7-openshift-image/tre... > These templates still use image version 17 instead of 18. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-259) Delete s2i-producers and s2i-universe project files during image build

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-259?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFWIP-259: ---------------------------------------- [~jdenise] Please resolve this if done or move to CLOUD if not done. The WIP feature it was reported against is merged. > Delete s2i-producers and s2i-universe project files during image build > ---------------------------------------------------------------------- > > Key: WFWIP-259 > URL: https://issues.redhat.com/browse/WFWIP-259 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Minor > > These files seem to be not needed after image is built: > {code:java} > /opt/jboss/container/wildfly/s2i/galleon/provisioning/jboss-s2i-producers/ > /opt/jboss/container/wildfly/s2i/galleon/provisioning/jboss-s2i-universe/ > {code} > The artifacts themselves are already installed at galleon-m2-repository so these files ^ can be probably deleted during image build. > {code:java} > /opt/jboss/container/wildfly/s2i/galleon/galleon-m2-repository/org/jboss/universe/producer/s2i-producers/1.0.0.Final/ > /opt/jboss/container/wildfly/s2i/galleon/galleon-m2-repository/org/jboss/universe/s2i-universe/1.0.0.Final/ > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-256) Duration of server configuration is not printed

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-256?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFWIP-256. ------------------------------------ Resolution: Migrated to another ITS [~yersan] I'm resolving this as the WIP feature it was reported against is now merged. I resolve it as "Migrated to another ITS" with the other Issue Tracking System being the CLOUD JIRA project where you've got an issue open. > Duration of server configuration is not printed > ----------------------------------------------- > > Key: WFWIP-256 > URL: https://issues.redhat.com/browse/WFWIP-256 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Yeray Borges > Priority: Minor > > {code:java} > INFO Configuring the server using embedded server > INFO Duration: > INFO Running jboss-eap-7-tech-preview/eap-cd-openshift-rhel8 image, version 18.0 > {code} > The cause is the wrong usage of log_info function in {{/opt/eap/bin/launch/openshift-common.sh}} > {code:java} > log_info "Duration: " $((end-start)) " milliseconds" > {code} > which is actually calling it with 3 arguments while the function prints only the first one. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-276?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFWIP-276. ------------------------------------ Resolution: Migrated to another ITS [~jdenise] I'm closing this one out as the WIP feature it was reported against is closed. I'm treating it as "Migrated to another ITS", the other Issue Tracking System being the EAP7 JIRA project. > Boot time of application built via S2I is much longer than in before-Galleon times > ---------------------------------------------------------------------------------- > > Key: WFWIP-276 > URL: https://issues.redhat.com/browse/WFWIP-276 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > Attachments: test-app.zip > > > As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. > This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): > ||17.0-6||pod time||EAP boot||config time > |#1 | 8283|6128|2155 > |#2 | 9446|7548|1898 > |#3 | 8767|6871| 1896 > |#4 | 8568|6272| 2296 > |#5 | 8000 |6362|1638 > ||average ||8613ms||6636ms||1977ms > ||18.0-7||pod time||EAP boot||config time > |#1 |13769|5716|8053 > |#2 |13362|5952|7410 > |#3 |14261|6093|8168 > |#4 |14322|6135|8187 > |#5 |13921|6326|7595 > ||average||13927ms||6044ms||7883ms > pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) > EAP boot = time of boot EAP itself == {{started in ..}} > config time = the difference of previou timess = anything before EAP boot begins > Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. > This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. > The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 January 2020