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: ------------------------------------ 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)

8 years, 1 month

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)

8 years, 1 month

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)

8 years, 1 month

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)

8 years, 1 month

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)

8 years, 1 month

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)

8 years, 1 month

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)

8 years, 1 month

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)

8 years, 1 month

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)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-286) HTTP Digest Authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-286?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-286: -------------------------------------- I would like us to be able to support all the options related to Digest authentication, how feasible that is at the moment I am not so sure but that should start to drop out during analysis. > HTTP Digest Authentication > -------------------------- > > Key: ELY-286 > URL: https://issues.jboss.org/browse/ELY-286 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > > Original Digest RFC [https://tools.ietf.org/html/rfc2069] > Current Digest RFC [https://tools.ietf.org/html/rfc2617] > HTTP 1.1 Authentication (Updates RFC2617) [https://tools.ietf.org/html/rfc7235] > Draft currently under discussion - [https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/] > RFC7616 Now Proposed Standard > "HTTP Digest Access Authentication", September 2015 > [https://www.rfc-editor.org/info/rfc7616] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

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 2018