January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ] Jean Francois Denise updated WFCORE-4785: ----------------------------------------- Attachment: standalone-minimal2.xml > PathAddress leaked on reload > ---------------------------- > > Key: WFCORE-4785 > URL: https://issues.redhat.com/browse/WFCORE-4785 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jean Francois Denise > Assignee: Jeff Mesnil > Priority: Major > Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml > > > Boot server, connect CLI and reload. > As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). > Attached heapdump, server.log and configuration used (reduced standalone.xml). > server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. > server.log contains stacktrace of PathAddress allocation. > You will notice: > 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. > 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. > 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. > 4) We have 3 remaining PathAddress 149, 600 and 789 > 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. > So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

Jean Francois Denise created WFCORE-4785: -------------------------------------------- Summary: PathAddress leaked on reload Key: WFCORE-4785 URL: https://issues.redhat.com/browse/WFCORE-4785 Project: WildFly Core Issue Type: Bug Components: Management Reporter: Jean Francois Denise Assignee: Jeff Mesnil Boot server, connect CLI and reload. As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). Attached heapdump, server.log and configuration used (reduced standalone.xml). server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. server.log contains stacktrace of PathAddress allocation. You will notice: 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. 4) We have 3 remaining PathAddress 149, 600 and 789 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12927) wildfly 8.2 huge memory allocation during and after deployement

by sandev sandev (Jira)

[ https://issues.redhat.com/browse/WFLY-12927?page=com.atlassian.jira.plugi... ] sandev sandev updated WFLY-12927: --------------------------------- Issue Type: Bug (was: Feature Request) > wildfly 8.2 huge memory allocation during and after deployement > --------------------------------------------------------------- > > Key: WFLY-12927 > URL: https://issues.redhat.com/browse/WFLY-12927 > Project: WildFly > Issue Type: Bug > Reporter: sandev sandev > Assignee: Brian Stansberry > Priority: Major > Attachments: threads.png > > > I am using wildfly 8.2.1 final to deploy java ee 7 maven web application wars about 30 war with dependence between them using rmi remote ejb. I found that the server consumes a lot of memory special on startup of the server to 8 g my java opt are -xms 8g -xmx 8g -metaspacesize 1g .so I use java "visualvm" to understand what is happening. I found that the most consumed memory is for 2 types of threads at deploy: MSC service thread and after deploy finish: DeployementScanner-threads in additional that no user use the server or the deployed application this server was just for test > my question is why wildfly starts with about 3g and after some time the memory growth to ~= 8g without any action on the server its idle any help to solve this problem please -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4779) Upgrade Woodstox from 5.0.3 to 6.0.3

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4779?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4779: -------------------------------- Component/s: Management (was: Build System) > Upgrade Woodstox from 5.0.3 to 6.0.3 > ------------------------------------ > > Key: WFCORE-4779 > URL: https://issues.redhat.com/browse/WFCORE-4779 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Management > Reporter: Ilia Vassilev > Assignee: Jeff Mesnil > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12927) wildfly 8.2 huge memory allocation during and after deployement

by sandev sandev (Jira)

[ https://issues.redhat.com/browse/WFLY-12927?page=com.atlassian.jira.plugi... ] sandev sandev updated WFLY-12927: --------------------------------- Attachment: threads.png > wildfly 8.2 huge memory allocation during and after deployement > --------------------------------------------------------------- > > Key: WFLY-12927 > URL: https://issues.redhat.com/browse/WFLY-12927 > Project: WildFly > Issue Type: Feature Request > Reporter: sandev sandev > Assignee: Brian Stansberry > Priority: Major > Attachments: threads.png > > > I am using wildfly 8.2.1 final to deploy java ee 7 maven web application wars about 30 war with dependence between them using rmi remote ejb. I found that the server consumes a lot of memory special on startup of the server to 8 g my java opt are -xms 8g -xmx 8g -metaspacesize 1g .so I use java "visualvm" to understand what is happening. I found that the most consumed memory is for 2 types of threads at deploy: MSC service thread and after deploy finish: DeployementScanner-threads in additional that no user use the server or the deployed application this server was just for test > my question is why wildfly starts with about 3g and after some time the memory growth to ~= 8g without any action on the server its idle any help to solve this problem please -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12927) wildfly 8.2 huge memory allocation during and after deployement

by sandev sandev (Jira)

sandev sandev created WFLY-12927: ------------------------------------ Summary: wildfly 8.2 huge memory allocation during and after deployement Key: WFLY-12927 URL: https://issues.redhat.com/browse/WFLY-12927 Project: WildFly Issue Type: Feature Request Reporter: sandev sandev Assignee: Brian Stansberry Attachments: threads.png I am using wildfly 8.2.1 final to deploy java ee 7 maven web application wars about 30 war with dependence between them using rmi remote ejb. I found that the server consumes a lot of memory special on startup of the server to 8 g my java opt are -xms 8g -xmx 8g -metaspacesize 1g .so I use java "visualvm" to understand what is happening. I found that the most consumed memory is for 2 types of threads at deploy: MSC service thread and after deploy finish: DeployementScanner-threads in additional that no user use the server or the deployed application this server was just for test my question is why wildfly starts with about 3g and after some time the memory growth to ~= 8g without any action on the server its idle any help to solve this problem please -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-84) Upgrade Undertow to 2.0.29.Final

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELYWEB-84?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated ELYWEB-84: ----------------------------------- Fix Version/s: 1.7.0.CR4 (was: 1.6.1.CR1) > Upgrade Undertow to 2.0.29.Final > -------------------------------- > > Key: ELYWEB-84 > URL: https://issues.redhat.com/browse/ELYWEB-84 > Project: Elytron Web > Issue Type: Component Upgrade > Components: Undertow > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.7.0.CR4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-84) Upgrade Undertow to 2.0.29.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created ELYWEB-84: -------------------------------------- Summary: Upgrade Undertow to 2.0.29.Final Key: ELYWEB-84 URL: https://issues.redhat.com/browse/ELYWEB-84 Project: Elytron Web Issue Type: Component Upgrade Components: Undertow Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.6.1.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4902) Can not use mod operators (%) in when closures.

by xb l (Jira)

xb l created DROOLS-4902: ---------------------------- Summary: Can not use mod operators (%) in when closures. Key: DROOLS-4902 URL: https://issues.redhat.com/browse/DROOLS-4902 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.31.0.Final Reporter: xb l Assignee: Mario Fusco When I study drools , I write a rule use divide operator {code:java} rule "Buzz" salience 2 when $n: Number( this / 5 == 3 ) then System.out.println("Buzz"); end {code} It's OK. But: {code:java} rule "Buzz" salience 2 when $n: Number( this % 5 == 0 ) then System.out.println("Buzz"); end {code} Report parser error: Unable to Analyse Expression this % 5 == 0: -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1048) Testcases - Kiali Validations sync-up

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1048: ------------------------------------- Summary: Testcases - Kiali Validations sync-up Key: SWSQE-1048 URL: https://issues.redhat.com/browse/SWSQE-1048 Project: Kiali QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Sync up all validations from https://kiali.io/documentation/validations/ with Polarion estcases. Make sure all validations have up-to-date testcases in Polarion. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2020