May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-6173: ------------------------------------ [~joeydaowang] [~jaikiran] Hi guys, I've tried the reproducer and it seems the leak only occurs when Omnifaces JSF library is used. {{WeldModuleResourceLoader}} is a regular per-module (per-BeanManager) service which does not require any cleanup after undeploy. The problematic class is {{org.omnifaces.config.BeanManager}} - this enum holds a reference to one of the webapp's {{BeanManager}}. We should probably idenfity all the GC roots first. > Classes not unloaded after undeployment > --------------------------------------- > > Key: WFLY-6173 > URL: https://issues.jboss.org/browse/WFLY-6173 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 8.2.0.Final, 10.0.0.Final > Reporter: Joey Wang > Assignee: Martin Kouba > Priority: Blocker > Fix For: 10.1.0.Final > > Attachments: memory-leak.zip > > > I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. > Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances. > Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1319) WildFly/IronJacamar 1.3.4.Final

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1319?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1319. ------------------------------------ Resolution: Done > WildFly/IronJacamar 1.3.4.Final > ------------------------------- > > Key: JBJCA-1319 > URL: https://issues.jboss.org/browse/JBJCA-1319 > Project: IronJacamar > Issue Type: Release > Components: Build > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: WildFly/IronJacamar 1.3.4.Final > > > Release notes: https://issues.jboss.org/projects/JBJCA/versions/12329856 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1319) WildFly/IronJacamar 1.3.4.Final

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1319: -------------------------------------- Summary: WildFly/IronJacamar 1.3.4.Final Key: JBJCA-1319 URL: https://issues.jboss.org/browse/JBJCA-1319 Project: IronJacamar Issue Type: Release Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: WildFly/IronJacamar 1.3.4.Final Release notes: https://issues.jboss.org/projects/JBJCA/versions/12329856 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-765) Externalize error codes for exception sorters

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-765?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-765. --------------------------------- Assignee: Johnathon Lee Resolution: Out of Date JBJCA-1318 > Externalize error codes for exception sorters > --------------------------------------------- > > Key: JBJCA-765 > URL: https://issues.jboss.org/browse/JBJCA-765 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Reporter: Jesper Pedersen > Assignee: Johnathon Lee > > Provide a format .properties / XML where the error codes for the different exception sorters can be defined, such that no Java code updates needs to happen -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1285) rar-info: CCI interface information missing

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1285?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1285. ------------------------------------ Fix Version/s: 1.2.8.Final (was: 1.2.7.Final) Resolution: Done > rar-info: CCI interface information missing > ------------------------------------------- > > Key: JBJCA-1285 > URL: https://issues.jboss.org/browse/JBJCA-1285 > Project: IronJacamar > Issue Type: Bug > Components: AS > Reporter: Jesper Pedersen > Assignee: Johnathon Lee > Fix For: 1.2.8.Final > > > If a resource adapter is using CCI then the ConnectionFactory and Connection information isn't included in the report. > The information should be based directly on the actual interface classes -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2067) Protocol: add down(Message) and up(Message)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2067?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2067: -------------------------------- To really force all protocols to implement these new callbacks, {{Event.MSG}} would have to be removed! > Protocol: add down(Message) and up(Message) > ------------------------------------------- > > Key: JGRP-2067 > URL: https://issues.jboss.org/browse/JGRP-2067 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Oftentime we have code like this, e.g. in a protocol: > {code:java} > void send(Message msg) { > ... > down_prot.down(new Event(Event.MSG, msg)); > } > {code} > Most protocols deal mainly with {{Message}} types, so adding {{down(Message msg)}} and {{up(Message msg)}} would simplify the code above to: > {code:java} > void send(Message msg) { > ... > down_prot.down(msg); > } > {code} > This would also lead to a (massive) reduction of {{Event}} class creations. > Downside: this requires a lot of code changes (mainly in protocols)! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6632) Unable to create replicated cache

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6632?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6632: ------------------------------------ Forgive me, but I don't see anything in your attached application that references the cache. Can you point me in the right direction? Also, please post the error message or stack trace from step 5 - as the attached server.log does not reflect this. > Unable to create replicated cache > ---------------------------------- > > Key: WFLY-6632 > URL: https://issues.jboss.org/browse/WFLY-6632 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.2.Final > Reporter: Vinay Lodha > Assignee: Paul Ferraro > Attachments: server.log, spring2-mvc-xml-hello-world-1.0-SNAPSHOT.war, spring2-mvc-xml.zip > > > servers is unable to create replicated or distributed infinispan cache, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2067) Protocol: add down(Message) and up(Message)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2067?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2067: -------------------------------- We could even get rid of {{Event}} altogether: instead of creating an event, e.g. {code:java} View view; Event evt=new Event(Event.VIEW, view); down(evt); {code} , we could change the {{down()}} and {{up()}} methods to take a type and an argument, e.g. {code:java} View view; down(Event.VIEW, view); {code} This is currently not critical though as 99% of all events are messages anyway. > Protocol: add down(Message) and up(Message) > ------------------------------------------- > > Key: JGRP-2067 > URL: https://issues.jboss.org/browse/JGRP-2067 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Oftentime we have code like this, e.g. in a protocol: > {code:java} > void send(Message msg) { > ... > down_prot.down(new Event(Event.MSG, msg)); > } > {code} > Most protocols deal mainly with {{Message}} types, so adding {{down(Message msg)}} and {{up(Message msg)}} would simplify the code above to: > {code:java} > void send(Message msg) { > ... > down_prot.down(msg); > } > {code} > This would also lead to a (massive) reduction of {{Event}} class creations. > Downside: this requires a lot of code changes (mainly in protocols)! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2067) Protocol: add down(Message) and up(Message)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2067?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2067: --------------------------- Description: Oftentime we have code like this, e.g. in a protocol: {code:java} void send(Message msg) { ... down_prot.down(new Event(Event.MSG, msg)); } {code} Most protocols deal mainly with {{Message}} types, so adding {{down(Message msg)}} and {{up(Message msg)}} would simplify the code above to: {code:java} void send(Message msg) { ... down_prot.down(msg); } {code} This would also lead to a (massive) reduction of {{Event}} class creations. Downside: this requires a lot of code changes (mainly in protocols)! was: Oftentime we have code like this, e.g. in a protocol: {code:java} void send(Message msg) { ... down_prot.down(new Event(Event.MSG, msg)); } {code} Most protocols deal mainly with {{Message}} types, so adding {{down(Message msg)}} and {{up(Message msg)}} would simplify the code above to: {code:java} void send(Message msg) { ... down_prot.down(msg); } {code} This would also lead to a (massive) reduction of {{Event}} class creations. > Protocol: add down(Message) and up(Message) > ------------------------------------------- > > Key: JGRP-2067 > URL: https://issues.jboss.org/browse/JGRP-2067 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Oftentime we have code like this, e.g. in a protocol: > {code:java} > void send(Message msg) { > ... > down_prot.down(new Event(Event.MSG, msg)); > } > {code} > Most protocols deal mainly with {{Message}} types, so adding {{down(Message msg)}} and {{up(Message msg)}} would simplify the code above to: > {code:java} > void send(Message msg) { > ... > down_prot.down(msg); > } > {code} > This would also lead to a (massive) reduction of {{Event}} class creations. > Downside: this requires a lot of code changes (mainly in protocols)! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2067) Protocol: add down(Message) and up(Message)

by Bela Ban (JIRA)

Bela Ban created JGRP-2067: ------------------------------ Summary: Protocol: add down(Message) and up(Message) Key: JGRP-2067 URL: https://issues.jboss.org/browse/JGRP-2067 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Oftentime we have code like this, e.g. in a protocol: {code:java} void send(Message msg) { ... down_prot.down(new Event(Event.MSG, msg)); } {code} Most protocols deal mainly with {{Message}} types, so adding {{down(Message msg)}} and {{up(Message msg)}} would simplify the code above to: {code:java} void send(Message msg) { ... down_prot.down(msg); } {code} This would also lead to a (massive) reduction of {{Event}} class creations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 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 May 2016