[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 updated WFLY-2593:
--------------------------------
Workaround Description: Disable statistics globally or for query cache in the persistence unit. (was: Disable statistics for the persistence unit.)
> 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 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, 5 months
[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 updated WFLY-2593:
--------------------------------
Steps to Reproduce:
Unpack a distribution of 7.1.1 community or EAP 6.2 beta. No changes are required to the configuration.
1. Deploy attached jmxp.ear.ear
2. Send a request to the application so a query gets executed:
curl http://localhost:8080/jmxp/jmxp
Expected output:
queries executed
Class is class org.hibernate.stat.internal.ConcurrentStatisticsImpl
3. Ask for queries:
./jboss-cli.sh --connect --command='/deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.ear\/jmxp.ejb.jar\#fraudPU:read-children-resources(child-type=query-cache)'
First time the result is fine. On subsequent requests with jboss-cli.sh new elements will appear although no requests were issued to the application.
After a number of request (for example from a monitoring system) an OutOfMemoryException will occur.
was:
1. Deploy attached jmxp.ear.ear
2. Send a request to the application so a query gets executed:
curl http://localhost:8080/jmxp/jmxp
Expected output:
queries executed
Class is class org.hibernate.stat.internal.ConcurrentStatisticsImpl
3. Ask for queries:
./jboss-cli.sh --connect --command='/deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa/hibernate-persistence-unit=jmxp.ear.ear\/jmxp.ejb.jar\#fraudPU:read-children-resources(child-type=query-cache)'
First time the result is fine. On subsequent requests with jboss-cli.sh new elements will appear although no requests were issued to the application.
After a number of request (for example from a monitoring system) an OutOfMemoryException will occur.
> 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 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, 5 months
[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 updated WFLY-2593:
--------------------------------
Attachment: jmxp.ear.ear
jmxp.tar.gz
Ear ready for deployment and it's source code.
> 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 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, 5 months
[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Michael Kozak (JIRA)
Michael Kozak created WFLY-2593:
-----------------------------------
Summary: 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
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 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, 5 months
[JBoss JIRA] (JGRP-1742) BARRIER: minimize closing time
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1742?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1742:
--------------------------------
Hmm, OOB messages (which are unordered) might kill the above plan... :-(
> BARRIER: minimize closing time
> ------------------------------
>
> Key: JGRP-1742
> URL: https://issues.jboss.org/browse/JGRP-1742
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> During a state transfer, BARRIER.up() waits until all incoming threads (delivering messages to the application) are done, and blocks further incoming messages. This is done to get the digest and the state.
> However, duing the block, the following messages are not sent up:
> * Views !
> * STABLE messages, triggering retransmissions
> This is bad, so we should try to minimize the time BARRIER is closed. This can be done with JGRP-1352.
> However, we could also do the following:
> * A state request is received
> * Close BARRIER and flush all pending threads. This ensures that any message which updated the *digest* also updated the *application state*
> * Get the digest D
> * *Open* BARRIER. Messages will now be delivered and thus applied to the state
> * Get the application state S
> * When done, return D and S to the state requester
> The difference to JGRP-1352 is that we don't queue messages during state transfer. How does this work ? It is critical to ensure that all mesages which updated the digest D also updated the state S, or else messages present in D but not in S would not be retransmitted. However, if there are more messages in S than in D, this is not an issue as they will be retransmitted again.
> Example:
> * BARRIER is closed and pending threads are flushed
> * Digest D is (only for a given member P) 5, state S is 5 as well
> * Now we open BARRIER
> * P sends a few more messages (6, 7 and 8)
> * The digest is now 8, but the copy we have is still 5
> * State S is 8
> * We return D=5 and S=8
> * The state requester closes BARRIER and sets its digest to 5 and its state to 8
> * Since the digest is only 5 for P, the state requester asks P for retransmission of messages 6, 7 and 8
> * Messages 6, 7 and 8 from P are received and applied to the state
> * The assumption here is that if messages 6, 7 and 8 are applied twice, the state doesn't change (idempotency). This should be the case with Infinispan.
> The advantage of this issue over JGRP-1352 is that we don't need to queue messages for a long time if the state is large.
--
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, 5 months
[JBoss JIRA] (DROOLS-360) Incremental compilation: Flawed for Rule Templates
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-360?page=com.atlassian.jira.plugin... ]
Michael Anstis updated DROOLS-360:
----------------------------------
Description:
Incremental compilation does not add new messages when a Rule Template is updated from being valid to being invalid. Full build with valid Rule Template passes; but Incremental Compilation with updated (and invalid) Rule Template does not lead to any "added" messages.
Updating a Rule Template from invalid to valid does however work. Full build with invalid Rule Template correctly returns error messages and Incremental Compilation with updated (and valid) Rule Template does lead to error message being removed.
Unit tests created (failing one @Ignored).
> Incremental compilation: Flawed for Rule Templates
> --------------------------------------------------
>
> Key: DROOLS-360
> URL: https://issues.jboss.org/browse/DROOLS-360
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Michael Anstis
> Assignee: Mark Proctor
>
> Incremental compilation does not add new messages when a Rule Template is updated from being valid to being invalid. Full build with valid Rule Template passes; but Incremental Compilation with updated (and invalid) Rule Template does not lead to any "added" messages.
> Updating a Rule Template from invalid to valid does however work. Full build with invalid Rule Template correctly returns error messages and Incremental Compilation with updated (and valid) Rule Template does lead to error message being removed.
> Unit tests created (failing one @Ignored).
--
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, 5 months