June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9849: ------------------------------------ I opened wildfly-leak-2.hprof and verified that there is no leak, I just had forgotten to verify that the suspected leaks had strong references to them. In summary, having four org.hibernate.internal.SessionFactoryImpl instances in memory is correct, as three of them are only have *weak* references to them (will be garbage collected eventually). One difference between Hibernate 5.3.1.Final and earlier Hibernate versions, is that 5.3.1.Final defaults to using ByteBuddy for enhancing entity classes, instead of Javassist. Which probably has something to do with why with 5.3.1, I don't see any weak references to the undeployed (org.hibernate.internalSessionFactoryImpl) test app. Hope this helps you, I'm closing this issue as not a bug. Thank you for reporting it and providing the needed information to verify, that there is no leak. :) Scott > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9849: ------------------------------------ For example, one of the weak references to the org.hibernate.internalSessionFactoryImpl is: {code} Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ class java.lang.reflect.Proxy @ 0xe01da968 System Class | 1 | 24 | 144 | 7,152 '- proxyClassCache java.lang.reflect.WeakCache @ 0xe00ea488 | 1 | 32 | 144 | 7,088 '- map java.util.concurrent.ConcurrentHashMap @ 0xe00ea4d8 | 1 | 64 | 144 | 4,208 '- table java.util.concurrent.ConcurrentHashMap$Node[16] @ 0xe00ea518 | 1 | 80 | 144 | 4,144 '- [2] java.util.concurrent.ConcurrentHashMap$Node @ 0xff265af0 | 1 | 32 | 144 | 1,376 '- next java.util.concurrent.ConcurrentHashMap$Node @ 0xff265f60 | 1 | 32 | 144 | 464 '- key java.lang.reflect.WeakCache$CacheKey @ 0xff265f80 | 1 | 32 | 144 | 32 '- referent org.jboss.modules.ModuleClassLoader @ 0xe077cde8 | 1 | 88 | 144 | 161,776 '- classes java.util.Vector @ 0xe077cf48 | 1 | 32 | 144 | 65,312 '- elementData java.lang.Object[2560] @ 0xff1d0588 | 1 | 10,256 | 144 | 65,280 '- [1448] class org.hibernate.proxy.pojo.javassist.JavassistProxyFactory$2 @ 0xff2049c0| 1 | 0 | 144 | 0 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ {code} I'll look again at the heap dump that you posted and verify if the leaked session factories have strong references. > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1596) Verify all permission checks on public API are documented in the Javadoc

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1596?page=com.atlassian.jira.plugin.s... ] Jan Kalina reassigned ELY-1596: ------------------------------- Assignee: Jan Kalina > Verify all permission checks on public API are documented in the Javadoc > ------------------------------------------------------------------------ > > Key: ELY-1596 > URL: https://issues.jboss.org/browse/ELY-1596 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Jan Kalina > > We have methods such as the following where a permission check occurs but the Javadoc does not describe the required permission so an end user would only discover this by trial and error. > http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/index... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1531) Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1531?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1531: ---------------------------------- It would be very difficult to do so in a clean manner I think. > Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext > ------------------------------------------------------------------------------------------ > > Key: ELY-1531 > URL: https://issues.jboss.org/browse/ELY-1531 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client, Authentication Server > Reporter: David Lloyd > > Both AuthenticationContext and SecurityIdentity can be captured and restored in a similar manner; they should use the same gamut of {{run*()}} methods. > The methods from {{org.wildfly.common.function.Functions}} can help with this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1531) Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1531?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1531: --------------------------------- [~dmlloyd], run*() methods are added into AuthenticationContext from Contextual interface. Does this issue mean SecurityIdentity should use Contextual interface too? (and deprecate currently used runAs*() methods?) > Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext > ------------------------------------------------------------------------------------------ > > Key: ELY-1531 > URL: https://issues.jboss.org/browse/ELY-1531 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client, Authentication Server > Reporter: David Lloyd > > Both AuthenticationContext and SecurityIdentity can be captured and restored in a similar manner; they should use the same gamut of {{run*()}} methods. > The methods from {{org.wildfly.common.function.Functions}} can help with this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow edited comment on WFLY-9849 at 6/1/18 10:45 AM: ------------------------------------------------------------- Updated: I don't seem to actually see a leak with Hibernate ORM 5.1.14.Final, as there weren't any strong references to the (undeployed) org.hibernate.internal.SessionFactoryImpl objects was (Author: smarlow): I do seem to see a leak also with Hibernate ORM 5.1.14.Final but not 5.3.1.Final. Could you verify that you don't see a leak with WildFly 13 started up via "standalone.sh -Dee8.preview.mode=true". > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9849: ------------------------------------ I do seem to see a leak also with Hibernate ORM 5.1.14.Final but not 5.3.1.Final. Could you verify that you don't see a leak with WildFly 13 started up via "standalone.sh -Dee8.preview.mode=true". > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow edited comment on WFLY-9849 at 6/1/18 10:40 AM: ------------------------------------------------------------- I started up WildFly 13, with Hibernate 5.3.1.Final and couldn't reproduce with the following steps: # Copied HibernateLeakTest-1.0-SNAPSHOT.jar into wildfly/standalone/deployments and then started up WildFly using "standalone.sh -Dee8.preview.mode=true" # I touched (updated) the wildfly/standalone/deployments/HibernateLeakTest-1.0-SNAPSHOT.jar four times, which caused it to redeploy four times, no leak (I only see one instance of org.hibernate.internal.SessionFactoryImpl instances in memory). # I removed the wildfly/standalone/deployments/HibernateLeakTest-1.0-SNAPSHOT.jar file, which undeployed it. I verified now that there are zero org.hibernate.internal.SessionFactoryImpl instances in memory. I'll try again with "/standalone.sh" on WildFly 13, which will use Hibernate ORM 5.1 instead. was (Author: smarlow): I started up WildFly 13, with Hibernate 5.3.1.Final and couldn't reproduce with the following steps: # Copied HibernateLeakTest-1.0-SNAPSHOT.jar into wildfly/standalone/deployments and then started up WildFly using "/standalone.sh -Dee8.preview.mode=true" # I touched (updated) the wildfly/standalone/deployments/HibernateLeakTest-1.0-SNAPSHOT.jar four times, which caused it to redeploy four times, no leak (I only see one instance of org.hibernate.internal.SessionFactoryImpl instances in memory). # I removed the wildfly/standalone/deployments/HibernateLeakTest-1.0-SNAPSHOT.jar file, which undeployed it. I verified now that there are zero org.hibernate.internal.SessionFactoryImpl instances in memory. I'll try again with "/standalone.sh" on WildFly 13, which will use Hibernate ORM 5.1 instead. > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9849: ------------------------------------ I started up WildFly 13, with Hibernate 5.3.1.Final and couldn't reproduce with the following steps: # Copied HibernateLeakTest-1.0-SNAPSHOT.jar into wildfly/standalone/deployments and then started up WildFly using "/standalone.sh -Dee8.preview.mode=true" # I touched (updated) the wildfly/standalone/deployments/HibernateLeakTest-1.0-SNAPSHOT.jar four times, which caused it to redeploy four times, no leak (I only see one instance of org.hibernate.internal.SessionFactoryImpl instances in memory). # I removed the wildfly/standalone/deployments/HibernateLeakTest-1.0-SNAPSHOT.jar file, which undeployed it. I verified now that there are zero org.hibernate.internal.SessionFactoryImpl instances in memory. I'll try again with "/standalone.sh" on WildFly 13, which will use Hibernate ORM 5.1 instead. > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-11) Create test plan for RH Scale Lab

by Michael Foley (JIRA)

[ https://issues.jboss.org/browse/SWSQE-11?page=com.atlassian.jira.plugin.s... ] Michael Foley commented on SWSQE-11: ------------------------------------ Please consider doing this on the developer Jira project ... for greater transparency on activies and results. > Create test plan for RH Scale Lab > --------------------------------- > > Key: SWSQE-11 > URL: https://issues.jboss.org/browse/SWSQE-11 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 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 June 2018