June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4510) remoting cannot start without default worker and does not work with non-default worker for http-upgrade

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4510?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-4510: ------------------------------------- Affects Version/s: 8.0.0.Final > remoting cannot start without default worker and does not work with non-default worker for http-upgrade > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4510 > URL: https://issues.jboss.org/browse/WFCORE-4510 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Affects Versions: 8.0.0.Final, 9.0.0.Final > Environment: jboss-eap-7.3.0.CD16-CR1 > Reporter: Will Reichert > Assignee: Flavia Rainone > Priority: Critical > Attachments: standalone-full.noDefault.xml > > > Originally we could not get remote+http to work with a non-default worker after following all the changes we found in the schema. It looks like remoting uses the default worker even when the endpoint is configured to use a different worker. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4510) remoting cannot start without default worker and does not work with non-default worker for http-upgrade

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4510?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-4510: ---------------------------------------- Assignee: Brian Stansberry (was: Flavia Rainone) > remoting cannot start without default worker and does not work with non-default worker for http-upgrade > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4510 > URL: https://issues.jboss.org/browse/WFCORE-4510 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Affects Versions: 8.0.0.Final, 9.0.0.Final > Environment: jboss-eap-7.3.0.CD16-CR1 > Reporter: Will Reichert > Assignee: Brian Stansberry > Priority: Critical > Attachments: standalone-full.noDefault.xml > > > Originally we could not get remote+http to work with a non-default worker after following all the changes we found in the schema. It looks like remoting uses the default worker even when the endpoint is configured to use a different worker. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4509) Release JBoss MSC to 1.4.7.Final

by Richard Opalka (Jira)

Richard Opalka created WFCORE-4509: -------------------------------------- Summary: Release JBoss MSC to 1.4.7.Final Key: WFCORE-4509 URL: https://issues.jboss.org/browse/WFCORE-4509 Project: WildFly Core Issue Type: Component Upgrade Components: Server Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 9.0.1.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1827) Release WildFly Elytron 1.6.3.Final

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1827?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1827: ---------------------------- Fix Version/s: 1.6.3.Final > Release WildFly Elytron 1.6.3.Final > ----------------------------------- > > Key: ELY-1827 > URL: https://issues.jboss.org/browse/ELY-1827 > Project: WildFly Elytron > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.6.3.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1827) Release WildFly Elytron 1.6.3.Final

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1827?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1827. ----------------------------- Resolution: Done > Release WildFly Elytron 1.6.3.Final > ----------------------------------- > > Key: ELY-1827 > URL: https://issues.jboss.org/browse/ELY-1827 > Project: WildFly Elytron > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.6.3.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12167) Memory leak in metrics in standalone-ha configuration

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12167?page=com.atlassian.jira.plugin... ] Paul Ferraro edited comment on WFLY-12167 at 6/6/19 2:45 PM: ------------------------------------------------------------- The code in ServiceSupplier is correct. Using the new MSC API, the only way to obtain a value provided by an ON_DEMAND service is install a service that depends on the target service. Once the value is retrieved, the mode of the temporary service is set to REMOVE. However, this removal happens asynchronously. Even if there were a memory leak in MSC this would still cause a heap spike until some MSC thread is able to perform the removal. To resolve that, ServiceSupplier.get() can block until the temporary service removal is complete which would prevent any spike in heap due to a pile-up of to-be-removed services. was (Author: pferraro): The code in ServiceSupplier is correct. Using the new MSC API, the only way to obtain a value provided by an ON_DEMAND service is install a service that depends on the target service. Once the value is retrieved, the mode of the temporary service is set to REMOVE. However, this removal happens asynchronously. If ServiceSupplier were to block until the temporary service removal is complete, that should address the memory consumption issues (assuming the MSC will not retain a reference to a removed service), though value retrieval will be slower. > Memory leak in metrics in standalone-ha configuration > ----------------------------------------------------- > > Key: WFLY-12167 > URL: https://issues.jboss.org/browse/WFLY-12167 > Project: WildFly > Issue Type: Bug > Components: Clustering, MP Metrics, MSC > Affects Versions: 16.0.0.Final > Reporter: Bernd Stolle > Assignee: Richard Opalka > Priority: Blocker > Labels: memoryleak > Attachments: Screenshot 2019-06-06 at 11.07.00.png > > > When started in standalone HA configuration every request to the recently added metrics endpoint ({{<management-if>:9990/metrics}}) lead to an increase in memory consumption until the JVM is slowed down significantly by GC to a point where even the requests to {{/health}} fail within a reasonable timeout (2s) and untlimately lead to OOM. > The same issue does not occur when WildFly is started in the default standalone configuration (non HA). > I can provide a (compressed) heap dump if required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12167) Memory leak in metrics in standalone-ha configuration

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12167?page=com.atlassian.jira.plugin... ] Paul Ferraro edited comment on WFLY-12167 at 6/6/19 2:45 PM: ------------------------------------------------------------- The code in ServiceSupplier is correct. Using the new MSC API, the only way to obtain a value provided by an ON_DEMAND service is install a service that depends on the target service. Once the value is retrieved, the mode of the temporary service is set to REMOVE. However, this removal happens asynchronously. Even if there was no memory leak in MSC this would still cause a heap spike until an available MSC thread is able to perform the removal. To resolve that, ServiceSupplier.get() can block until the temporary service removal is complete which would prevent any spike in heap due to a pile-up of to-be-removed services. was (Author: pferraro): The code in ServiceSupplier is correct. Using the new MSC API, the only way to obtain a value provided by an ON_DEMAND service is install a service that depends on the target service. Once the value is retrieved, the mode of the temporary service is set to REMOVE. However, this removal happens asynchronously. Even if there were a memory leak in MSC this would still cause a heap spike until some MSC thread is able to perform the removal. To resolve that, ServiceSupplier.get() can block until the temporary service removal is complete which would prevent any spike in heap due to a pile-up of to-be-removed services. > Memory leak in metrics in standalone-ha configuration > ----------------------------------------------------- > > Key: WFLY-12167 > URL: https://issues.jboss.org/browse/WFLY-12167 > Project: WildFly > Issue Type: Bug > Components: Clustering, MP Metrics, MSC > Affects Versions: 16.0.0.Final > Reporter: Bernd Stolle > Assignee: Richard Opalka > Priority: Blocker > Labels: memoryleak > Attachments: Screenshot 2019-06-06 at 11.07.00.png > > > When started in standalone HA configuration every request to the recently added metrics endpoint ({{<management-if>:9990/metrics}}) lead to an increase in memory consumption until the JVM is slowed down significantly by GC to a point where even the requests to {{/health}} fail within a reasonable timeout (2s) and untlimately lead to OOM. > The same issue does not occur when WildFly is started in the default standalone configuration (non HA). > I can provide a (compressed) heap dump if required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12167) Memory leak in metrics in standalone-ha configuration

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12167?page=com.atlassian.jira.plugin... ] Paul Ferraro edited comment on WFLY-12167 at 6/6/19 2:33 PM: ------------------------------------------------------------- The code in ServiceSupplier is correct. Using the new MSC API, the only way to obtain a value provided by an ON_DEMAND service is install a service that depends on the target service. Once the value is retrieved, the mode of the temporary service is set to REMOVE. However, this removal happens asynchronously. If ServiceSupplier were to block until the temporary service removal is complete, that should address the memory consumption issues (assuming the MSC will not retain a reference to a removed service), though value retrieval will be slower. was (Author: pferraro): The code in ServiceSupplier is correct. Using the new MSC API, the only way to obtain a value provided by an ON_DEMAND service is install a service that depends on the target service. Once the value is retrieved, the mode of the temporary service is set to REMOVE. However, this removal happens asynchronously. If ServiceSupplier were to block until the temporary service removal is complete, that should address the memory consumption issues, though value retrieval will be slower. > Memory leak in metrics in standalone-ha configuration > ----------------------------------------------------- > > Key: WFLY-12167 > URL: https://issues.jboss.org/browse/WFLY-12167 > Project: WildFly > Issue Type: Bug > Components: Clustering, MP Metrics, MSC > Affects Versions: 16.0.0.Final > Reporter: Bernd Stolle > Assignee: Richard Opalka > Priority: Blocker > Labels: memoryleak > Attachments: Screenshot 2019-06-06 at 11.07.00.png > > > When started in standalone HA configuration every request to the recently added metrics endpoint ({{<management-if>:9990/metrics}}) lead to an increase in memory consumption until the JVM is slowed down significantly by GC to a point where even the requests to {{/health}} fail within a reasonable timeout (2s) and untlimately lead to OOM. > The same issue does not occur when WildFly is started in the default standalone configuration (non HA). > I can provide a (compressed) heap dump if required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12167) Memory leak in metrics in standalone-ha configuration

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12167?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-12167: ------------------------------------- The code in ServiceSupplier is correct. Using the new MSC API, the only way to obtain a value provided by an ON_DEMAND service is install a service that depends on the target service. Once the value is retrieved, the mode of the temporary service is set to REMOVE. However, this removal happens asynchronously. If ServiceSupplier were to block until the temporary service removal is complete, that should address the memory consumption issues, though value retrieval will be slower. > Memory leak in metrics in standalone-ha configuration > ----------------------------------------------------- > > Key: WFLY-12167 > URL: https://issues.jboss.org/browse/WFLY-12167 > Project: WildFly > Issue Type: Bug > Components: Clustering, MP Metrics, MSC > Affects Versions: 16.0.0.Final > Reporter: Bernd Stolle > Assignee: Richard Opalka > Priority: Blocker > Labels: memoryleak > Attachments: Screenshot 2019-06-06 at 11.07.00.png > > > When started in standalone HA configuration every request to the recently added metrics endpoint ({{<management-if>:9990/metrics}}) lead to an increase in memory consumption until the JVM is slowed down significantly by GC to a point where even the requests to {{/health}} fail within a reasonable timeout (2s) and untlimately lead to OOM. > The same issue does not occur when WildFly is started in the default standalone configuration (non HA). > I can provide a (compressed) heap dump if required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12175) Broken links in "Description of the Management Model"

by Robert Johnson (Jira)

Robert Johnson created WFLY-12175: ------------------------------------- Summary: Broken links in "Description of the Management Model" Key: WFLY-12175 URL: https://issues.jboss.org/browse/WFLY-12175 Project: WildFly Issue Type: Bug Affects Versions: 16.0.0.Final, 15.0.0.Final, 14.0.0.Final, 13.0.0.Final, 12.0.0.Final Reporter: Robert Johnson Assignee: Brian Stansberry In the section "http://docs.wildfly.org/16/Admin_Guide.html#Description_of_the_Management...", the links on the following text strings return 404 errors when clicked: * Global operations * Management Resource -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 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 June 2019