September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10991) Memory leak when deployment is redeployed multiple times

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-10991?page=com.atlassian.jira.plugin... ] Jan Stourac commented on WFLY-10991: ------------------------------------ [~juraci.costa], yeah - the leak was 25MB for 100 re-deployments, so the fix you provided is probably the right-one. Thank you for running our test against that version. I'll do that myself manually too but as test passed for you I believe that the fix is correct :) > Memory leak when deployment is redeployed multiple times > -------------------------------------------------------- > > Key: WFLY-10991 > URL: https://issues.jboss.org/browse/WFLY-10991 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Juraci Paixão Kröhling > Priority: Blocker > Attachments: memoryLeaks.war, problematic-wf-build-heap-diff-start-end-org-filter.png, problematic-wf-build-heap-diff-start-end.png, sane-wf-build-heap-diff-start-end-org-filter.png, sane-wf-build-heap-diff-start-end.png > > > It looks like redeploying attached deployment [^memoryLeaks.war] multiple times (our automated test does it 100 times), there seems to be some memory leak in the WildFly. Using git bisect, the commit that started to fail is [651dc8a2f0d4ccad6a35f7b1d28626b43ebb2a5d in WildFly repository|https://github.com/wildfly/wildfly/commits/651dc8a2f0d4ccad6a3...]. That is why I selected MP OpenTracing component for this issue. Actual testing deployment is very simple and contains just some jsp file with some EJB classes that are used to call GC and check current heap usage. > Brief description of the test: > # attached deployment is deployed > # System.gc() is called via EJB call > # it checks initial heap usage at the beginning of the test via EJB call that checks all instances of ManagementFactory.getMemoryPoolMXBeans() > # deployment is redeployed 100 times > # calls System.gc() via EJP call again and checks heap usage again via EJB call and compares the results > Size of the extra heap in use is about 25MB plus when compared to the initial size. > I tried to check manually via [visualVM|https://visualvm.github.io/] tool. You can create a heapdump at the beginning of the test and at the end of the test. Then compare them easily and check the differences. Using a filter I can see quite a huge increase of instances of the {{org.jboss.modules.*}} classes. However, biggest memory footprint is huge increase of the instances of the {{java.util.HashMap$Node}}, {{char[]}}, {{java.util.HashMap$Node[]}} and few others. I don't see such huge increase of the instances of these classes when I use older build of WildFly prior to the problematic commit. To be honest I don't see direct link with the problematic commit I linked before. As the heapdumps are too big to be attached here, I am attaching some screenshots. > Also, when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > then no more memory leak is detected, after adding the subsystem back, the leak is present again. Thus opentracing is involved somehow into this indeed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1662) Increment WildFly Elytron schema version for client to 1.3

by Jan Kalina (JIRA)

Jan Kalina created ELY-1662: ------------------------------- Summary: Increment WildFly Elytron schema version for client to 1.3 Key: ELY-1662 URL: https://issues.jboss.org/browse/ELY-1662 Project: WildFly Elytron Issue Type: Task Components: XML Reporter: Jan Kalina Assignee: Jan Kalina -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10832) Determine the primary provider of Singleton Service using CLI

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10832?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10832: ---------------------------------- Summary: Determine the primary provider of Singleton Service using CLI (was: Determine the primary provider of Singleton Service using CLI.) > Determine the primary provider of Singleton Service using CLI > ------------------------------------------------------------- > > Key: WFLY-10832 > URL: https://issues.jboss.org/browse/WFLY-10832 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 13.0.0.Final > Reporter: Brad Maxwell > Assignee: Paul Ferraro > > Currently we do not expose any run-time metrics/statistics for singleton services , User needs to determine the primary provider of Singleton service and would like a CLI command to do so > Currently from CLI we can see that the singleton application is deployed on all the instance of the cluster , but not determine from CLI which node/instance is operating as primary provider of Singleton Service , User would like to give to his operations team a way to check that a certain application is in ha singleton among others which can be in just cluster mode. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10991) Memory leak when deployment is redeployed multiple times

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/WFLY-10991?page=com.atlassian.jira.plugin... ] Juraci Paixão Kröhling commented on WFLY-10991: ----------------------------------------------- I was able to run the test and it seems it passes when the fix is applied: {code} [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.088 s - in org.jboss.qa.management.web.UndeployMemoryLeakIT ... [INFO] jbossqe-eap-tests-management-parent ................ SUCCESS [ 0.217 s] [INFO] jbossqe-eap-tests-management-common ................ SUCCESS [ 8.609 s] [INFO] jbossqe-eap-tests-management-integration-tests ..... SUCCESS [02:28 min] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 02:37 min {code} Without this fix, I get: {code} [ERROR] UndeployMemoryLeakIT.undeployWithELTest:105 There was an increase in used heap size of 26521296 bytes. There is probably a leak, investigate. This might be caused by https://issues.jboss.org/browse/JBEAP-14901 {code} > Memory leak when deployment is redeployed multiple times > -------------------------------------------------------- > > Key: WFLY-10991 > URL: https://issues.jboss.org/browse/WFLY-10991 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Juraci Paixão Kröhling > Priority: Blocker > Attachments: memoryLeaks.war, problematic-wf-build-heap-diff-start-end-org-filter.png, problematic-wf-build-heap-diff-start-end.png, sane-wf-build-heap-diff-start-end-org-filter.png, sane-wf-build-heap-diff-start-end.png > > > It looks like redeploying attached deployment [^memoryLeaks.war] multiple times (our automated test does it 100 times), there seems to be some memory leak in the WildFly. Using git bisect, the commit that started to fail is [651dc8a2f0d4ccad6a35f7b1d28626b43ebb2a5d in WildFly repository|https://github.com/wildfly/wildfly/commits/651dc8a2f0d4ccad6a3...]. That is why I selected MP OpenTracing component for this issue. Actual testing deployment is very simple and contains just some jsp file with some EJB classes that are used to call GC and check current heap usage. > Brief description of the test: > # attached deployment is deployed > # System.gc() is called via EJB call > # it checks initial heap usage at the beginning of the test via EJB call that checks all instances of ManagementFactory.getMemoryPoolMXBeans() > # deployment is redeployed 100 times > # calls System.gc() via EJP call again and checks heap usage again via EJB call and compares the results > Size of the extra heap in use is about 25MB plus when compared to the initial size. > I tried to check manually via [visualVM|https://visualvm.github.io/] tool. You can create a heapdump at the beginning of the test and at the end of the test. Then compare them easily and check the differences. Using a filter I can see quite a huge increase of instances of the {{org.jboss.modules.*}} classes. However, biggest memory footprint is huge increase of the instances of the {{java.util.HashMap$Node}}, {{char[]}}, {{java.util.HashMap$Node[]}} and few others. I don't see such huge increase of the instances of these classes when I use older build of WildFly prior to the problematic commit. To be honest I don't see direct link with the problematic commit I linked before. As the heapdumps are too big to be attached here, I am attaching some screenshots. > Also, when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > then no more memory leak is detected, after adding the subsystem back, the leak is present again. Thus opentracing is involved somehow into this indeed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10907) ServiceRegistry lookup of legacy SingletonServiceBuilderFactory throws UnsupportedOperationException

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10907?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10907: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/11560 > ServiceRegistry lookup of legacy SingletonServiceBuilderFactory throws UnsupportedOperationException > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-10907 > URL: https://issues.jboss.org/browse/WFLY-10907 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.0.Beta2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 14.0.0.Final > > > Legacy code will lookup a SingletonPolicy or SingletonServiceBuilderFactory using the deprecated ServiceController.awaitValue() or getValue() methods. Services installed using the new MSC service installation API will throw an UnsupportedOperationException in this case. Consequently, the services providing the legacy implementations of these deprecated APIs need to be installed using the deprecated MSC API to prevent migrated applications from unexpected UnsupportedOperationExceptions. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2982) Create backend methods to pair with "duplicate row"

by Gabriele Cardosi (JIRA)

Gabriele Cardosi created DROOLS-2982: ---------------------------------------- Summary: Create backend methods to pair with "duplicate row" Key: DROOLS-2982 URL: https://issues.jboss.org/browse/DROOLS-2982 Project: Drools Issue Type: Task Components: Scenario Simulation and Testing Reporter: Gabriele Cardosi Assignee: Daniele Zonca Create a Simulation.insertScenario(Scenario, index) to insert a given Scenario at a specific index. Create Scenario.clone method to have a new Scenario instance with same values of original one. Check Scenario hashCode/equals methods so that SCENARIO_INSTANCE.equals(SCENARIO_INSTANCE.clone) = false -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10684) Upgrade Yasson to 1.0.2

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFLY-10684?page=com.atlassian.jira.plugin... ] Marek Kopecký updated WFLY-10684: --------------------------------- Priority: Critical (was: Major) > Upgrade Yasson to 1.0.2 > ----------------------- > > Key: WFLY-10684 > URL: https://issues.jboss.org/browse/WFLY-10684 > Project: WildFly > Issue Type: Task > Components: EE, REST > Affects Versions: 13.0.0.Final, 14.0.0.Final > Reporter: Erik . > Assignee: Alessio Soldano > Priority: Critical > Fix For: 14.0.1.Final > > > Upgrade to Eclipse Yasson from 1.0.1 to 1.0.2 to fix https://github.com/eclipse-ee4j/yasson/issues/137 > The implementation for PropertyVisibilityStrategy for fields does not work as it should. @JsonbProperty() on private fields does not work as mentioned on page 17 of the Json-B 1.0: Java™ API for JSON Binding published on May 15th 2017. > 1.0.2 will be released somewhere week -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2904) Show menu to add row and column

by Gabriele Cardosi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2904?page=com.atlassian.jira.plugi... ] Gabriele Cardosi edited comment on DROOLS-2904 at 9/10/18 6:01 AM: ------------------------------------------------------------------- In this version the "collapsed cell" issue won't be addressed. It will be fixed with https://issues.jboss.org/browse/DROOLS-2981 was (Author: gabriolo): In this version the "collapsed cell" issue won't be addressed. It will be fixed withhttps://issues.jboss.org/browse/DROOLS-2981 > Show menu to add row and column > ------------------------------- > > Key: DROOLS-2904 > URL: https://issues.jboss.org/browse/DROOLS-2904 > Project: Drools > Issue Type: Sub-task > Reporter: Juraj Soltes > Assignee: Gabriele Cardosi > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2904) Show menu to add row and column

by Gabriele Cardosi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2904?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-2904: ------------------------------------- Comment: was deleted (was: In this version the "collapsed cell" issue won't be addressed. It will be fixed withhttps://issues.jboss.org/browse/DROOLS-2981) > Show menu to add row and column > ------------------------------- > > Key: DROOLS-2904 > URL: https://issues.jboss.org/browse/DROOLS-2904 > Project: Drools > Issue Type: Sub-task > Reporter: Juraj Soltes > Assignee: Gabriele Cardosi > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10991) Memory leak when deployment is redeployed multiple times

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/WFLY-10991?page=com.atlassian.jira.plugin... ] Juraci Paixão Kröhling commented on WFLY-10991: ----------------------------------------------- [~jstourac], are you getting 25MB extra for each deployment, or 25 MB after 100 re-deployments? I submitted a PR that solves a memory leak that I could find, but this is probably not the right fix if we are talking about 25 MB per deployment. https://github.com/wildfly/wildfly/pull/11654 > Memory leak when deployment is redeployed multiple times > -------------------------------------------------------- > > Key: WFLY-10991 > URL: https://issues.jboss.org/browse/WFLY-10991 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Juraci Paixão Kröhling > Priority: Blocker > Attachments: memoryLeaks.war, problematic-wf-build-heap-diff-start-end-org-filter.png, problematic-wf-build-heap-diff-start-end.png, sane-wf-build-heap-diff-start-end-org-filter.png, sane-wf-build-heap-diff-start-end.png > > > It looks like redeploying attached deployment [^memoryLeaks.war] multiple times (our automated test does it 100 times), there seems to be some memory leak in the WildFly. Using git bisect, the commit that started to fail is [651dc8a2f0d4ccad6a35f7b1d28626b43ebb2a5d in WildFly repository|https://github.com/wildfly/wildfly/commits/651dc8a2f0d4ccad6a3...]. That is why I selected MP OpenTracing component for this issue. Actual testing deployment is very simple and contains just some jsp file with some EJB classes that are used to call GC and check current heap usage. > Brief description of the test: > # attached deployment is deployed > # System.gc() is called via EJB call > # it checks initial heap usage at the beginning of the test via EJB call that checks all instances of ManagementFactory.getMemoryPoolMXBeans() > # deployment is redeployed 100 times > # calls System.gc() via EJP call again and checks heap usage again via EJB call and compares the results > Size of the extra heap in use is about 25MB plus when compared to the initial size. > I tried to check manually via [visualVM|https://visualvm.github.io/] tool. You can create a heapdump at the beginning of the test and at the end of the test. Then compare them easily and check the differences. Using a filter I can see quite a huge increase of instances of the {{org.jboss.modules.*}} classes. However, biggest memory footprint is huge increase of the instances of the {{java.util.HashMap$Node}}, {{char[]}}, {{java.util.HashMap$Node[]}} and few others. I don't see such huge increase of the instances of these classes when I use older build of WildFly prior to the problematic commit. To be honest I don't see direct link with the problematic commit I linked before. As the heapdumps are too big to be attached here, I am attaching some screenshots. > Also, when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > then no more memory leak is detected, after adding the subsystem back, the leak is present again. Thus opentracing is involved somehow into this indeed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 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 September 2018