December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration

by Michael Kozak (JIRA)

[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ] Michael Kozak edited comment on WFLY-2593 at 12/3/13 7:13 AM: -------------------------------------------------------------- I didn't notice the fix is so simple. I see scopedPUName is not used in your snippet so puService is not need either since getPersistenceUnitService does only a map lookup. I also noticed getQueryNames() handles the case when there are no statistics very well therefore I propose a simplified version: {code} private boolean hasQuery(final PathElement element) { return getQueryNames().contains(element.getValue()); } {code} Correct me if I'm wrong. Is there any chance the fix will land in EAP 6.2 ? was (Author: lklm): I didn't notice the fix is so simple. I see scopedPUName is not used in your snippet so puService is not need either since getPersistenceUnitService does only a map lookup. I also noticed getQueryNames() handles the case when there are no statistics very well therefore I propose a simplified version: {code} private boolean hasQuery(final PathElement element) { return getQueryNames().contains(element.getValue()); } {code} Correct me if I'm wrong. Is there any chance the fix will land is EAP 6.2 ? > Memory leak in JBoss AS / Hibernate JPA integration > --------------------------------------------------- > > Key: WFLY-2593 > URL: https://issues.jboss.org/browse/WFLY-2593 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: No Release > Environment: JBoss 7.1.1 > JBoss EAP 6.2 beta > Reporter: Michael Kozak > Assignee: Scott Marlow > Priority: Critical > Fix For: No Release > > Attachments: jmxp.ear.ear, jmxp.tar.gz > > > The leak exists in AS integration code with Hibernate JPA. > When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements. > The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found. > Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do. > This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration

by Michael Kozak (JIRA)

[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ] Michael Kozak commented on WFLY-2593: ------------------------------------- I didn't notice the fix is so simple. I see scopedPUName is not used in your snippet so puService is not need either since getPersistenceUnitService does only a map lookup. I also noticed getQueryNames() handles the case when there are no statistics very well therefore I propose a simplified version: {code} private boolean hasQuery(final PathElement element) { return getQueryNames().contains(element.getValue()); } {code} Correct me if I'm wrong. Is there any chance the fix will land is EAP 6.2 ? > Memory leak in JBoss AS / Hibernate JPA integration > --------------------------------------------------- > > Key: WFLY-2593 > URL: https://issues.jboss.org/browse/WFLY-2593 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: No Release > Environment: JBoss 7.1.1 > JBoss EAP 6.2 beta > Reporter: Michael Kozak > Assignee: Scott Marlow > Priority: Critical > Fix For: No Release > > Attachments: jmxp.ear.ear, jmxp.tar.gz > > > The leak exists in AS integration code with Hibernate JPA. > When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements. > The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found. > Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do. > This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-1533: ------------------------------------ Actually I was wrong the stacktrace will only show if the logging level for Weld is set to DEBUG. A more concise message is logged with WARN level. > UT015005: Error invoking method requestDestroyed on listener class > ------------------------------------------------------------------- > > Key: WFLY-1533 > URL: https://issues.jboss.org/browse/WFLY-1533 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4 > Reporter: Juergen Zimmermann > Assignee: Martin Kouba > Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip > > > I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace: > 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9 > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ] Martin Kouba reopened WFLY-1533: -------------------------------- > UT015005: Error invoking method requestDestroyed on listener class > ------------------------------------------------------------------- > > Key: WFLY-1533 > URL: https://issues.jboss.org/browse/WFLY-1533 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4 > Reporter: Juergen Zimmermann > Assignee: Martin Kouba > Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip > > > I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace: > 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9 > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/SECURITY-770?page=com.atlassian.jira.plug... ] Ivo Studensky commented on SECURITY-770: ---------------------------------------- Thanks. > Support external password for keystore of PicketBoxVault implementation > ----------------------------------------------------------------------- > > Key: SECURITY-770 > URL: https://issues.jboss.org/browse/SECURITY-770 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Ivo Studensky > Assignee: Peter Skopek > Fix For: PicketBox_4_0_20.Final > > Attachments: SECURITY-770_with_testcase_2.patch > > > At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-363) Incremental compilation fails with declared types

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-363?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-363. -------------------------------- Fix Version/s: 6.0.1.Final Resolution: Done > Incremental compilation fails with declared types > ------------------------------------------------- > > Key: DROOLS-363 > URL: https://issues.jboss.org/browse/DROOLS-363 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation doesn't work if the newly added drl contains a declared type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-363) Incremental compilation fails with declared types

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-363?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-363: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1037572 > Incremental compilation fails with declared types > ------------------------------------------------- > > Key: DROOLS-363 > URL: https://issues.jboss.org/browse/DROOLS-363 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation doesn't work if the newly added drl contains a declared type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-363) Incremental compilation fails with declared types

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-363?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-363: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1037572|https://bugzilla.redhat.com/show_bug.cgi?id=1037572] from NEW to ASSIGNED > Incremental compilation fails with declared types > ------------------------------------------------- > > Key: DROOLS-363 > URL: https://issues.jboss.org/browse/DROOLS-363 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > Incremental compilation doesn't work if the newly added drl contains a declared type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-363) Incremental compilation fails with declared types

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-363: ---------------------------------- Summary: Incremental compilation fails with declared types Key: DROOLS-363 URL: https://issues.jboss.org/browse/DROOLS-363 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco Incremental compilation doesn't work if the newly added drl contains a declared type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-770?page=com.atlassian.jira.plug... ] Peter Skopek resolved SECURITY-770. ----------------------------------- Fix Version/s: PicketBox_4_0_20.Final Resolution: Done > Support external password for keystore of PicketBoxVault implementation > ----------------------------------------------------------------------- > > Key: SECURITY-770 > URL: https://issues.jboss.org/browse/SECURITY-770 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Ivo Studensky > Assignee: Peter Skopek > Fix For: PicketBox_4_0_20.Final > > Attachments: SECURITY-770_with_testcase_2.patch > > > At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 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 December 2013