[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2593:
------------------------------------
Yes, the fix should be simple, just need to avoid passing the wrong query to Hibernate. At the moment, I'm getting a different error when I recreate this on WildFly 8.
{quote}
./jboss-cli.sh --connect --command='/deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.earjmxp.ejb.jar#fraudPU:read-children-resources(child-type=query-cache)'
Failed to get the list of the operation properties: "JBAS014883: No resource definition is registered for address [
("deployment" => "jmxp.ear.ear"),
("subdeployment" => "jmxp.ejb.jar"),
("subsystem" => "jpa"),
("hibernate-persistence-unit" => "jmxp.ear.earjmxp.ejb.jar#fraudPU")
]"
{quote}
> 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
10 years, 6 months
[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2593:
-----------------------------------
[~lklm] For EAP, please create bugzilla entry at https://bugzilla.redhat.com/
> 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
10 years, 6 months
[JBoss JIRA] (WFLY-1561) NullPointerException when deploying WAR on z/OS
by Mike Polan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1561?page=com.atlassian.jira.plugin.... ]
Mike Polan commented on WFLY-1561:
----------------------------------
Thank you for looking into this issue! I'll try to put together another WAR file to reproduce this problem, since the one in question is proprietary. I'll keep you updated once I have some materials.
> NullPointerException when deploying WAR on z/OS
> -----------------------------------------------
>
> Key: WFLY-1561
> URL: https://issues.jboss.org/browse/WFLY-1561
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: IBM z/OS 1.13, IBM Java 7 64-bit
> Reporter: Mike Polan
> Assignee: Jean-Frederic Clere
>
> I am getting a NullPointerException when attempting to deploy a WAR file on a JBoss 7.1.1.Final instance running on an IBM z/OS 1.13 mainframe. I tried running JBoss with IBM Java 6 and 7, both 64-bit, and got the same effect. I should also note that this WAR file contains no JBoss-specific configuration files (it's being ported from another servlet container), and that I do NOT encounter this exception when deploying on the same JBoss release on a Windows 7 machine. I do not know of a workaround for this problem.
> This stack trace appears after the "Starting deployment of app.war" message:
> 08:42:33,875 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."app.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."app.war".PARSE: Failed to process phase PARSE of deployment "app.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0]
> at java.lang.Thread.run(Thread.java:736) [vm.jar:1.6.0]
> Caused by: java.lang.NullPointerException
> at org.jboss.metadata.parser.util.MetaDataElementParser.readDTDLocation(MetaDataElementParser.java:319)
> at org.jboss.metadata.parser.jsp.TldMetaDataParser.parse(TldMetaDataParser.java:58)
> at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.parseTLD(TldParsingDeploymentProcessor.java:126)
> at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.processTlds(TldParsingDeploymentProcessor.java:107)
> at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.deploy(TldParsingDeploymentProcessor.java:83)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> I believe that I tracked down the offending code in the git repository (looks like "loc" is null): https://github.com/jboss/metadata/blob/d3a85c7869430831577035aad153c43203...
> Is there any way to enable some sort of logging so that I could see what file JBoss is trying to parse?
--
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
10 years, 6 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1752:
--------------------------------
The chances of this happening in UNICAST3 are close to 0, as a message is retransmitted {{xmit_interval *2}} ms after sending it for the first time. If the message was sent the first time, a potential resize() (if it has more than 3 headers) would have allocated the correct size for the message headers and subsequent retransmissions would not have changed that.
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.4.2, 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
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
10 years, 6 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1752:
---------------------------
Fix Version/s: 3.4.2
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.4.2, 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
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
10 years, 6 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1752:
---------------------------
Fix Version/s: 3.5
Can be caused by the following interleaving of threads:
* T1: Message.putHeaderIfAbsent()
* T1: inserts key (id)
* T2: Message.resize(): copies old array (with key and (null) value)
* T1: sets value in old array
* T2: replaces old array with new one (key != null, value == null)
{{Message.putIfAbsent(K,V)}} only checks if K is null and sets V only if K == null. This will never set V.
SOLUTION: change to {{Message.putHeaderIfAbsent()}}: if key != null but val == null -> set V anyway
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
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
10 years, 6 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1752 at 12/3/13 8:07 AM:
---------------------------------------------------------
Can be caused by the following interleaving of threads:
* T1: Message.putHeaderIfAbsent()
* T1: inserts key (id)
* T2: Message.resize(): copies old array (with key and (null) value)
* T1: sets value in old array
* T2: replaces old array with new one (key != null, value == null)
{{Message.putIfAbsent(K,V)}} only checks if K is null and sets V only if K == null. This will never set V.
SOLUTION: change {{Message.putHeaderIfAbsent()}}: if key != null but val == null -> set V anyway
was (Author: belaban):
Can be caused by the following interleaving of threads:
* T1: Message.putHeaderIfAbsent()
* T1: inserts key (id)
* T2: Message.resize(): copies old array (with key and (null) value)
* T1: sets value in old array
* T2: replaces old array with new one (key != null, value == null)
{{Message.putIfAbsent(K,V)}} only checks if K is null and sets V only if K == null. This will never set V.
SOLUTION: change to {{Message.putHeaderIfAbsent()}}: if key != null but val == null -> set V anyway
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
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
10 years, 6 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1752:
--------------------------------
Needs to be backported to a 3.4.2
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
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
10 years, 6 months