[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:
------------------------------------
Thanks for reporting this issue!
> 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
[JBoss JIRA] (WFLY-364) a "failure-causes-rollback="false"" attribute for the filesystem scanner
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/WFLY-364?page=com.atlassian.jira.plugin.s... ]
Martin Malina commented on WFLY-364:
------------------------------------
I just verified that with Wildfly 8.0.0.Beta1 it works as expected - a broken deployment doesn't break other modules when the server is restarted. And the broken deployment is marked as .failed.
> a "failure-causes-rollback="false"" attribute for the filesystem scanner
> ------------------------------------------------------------------------
>
> Key: WFLY-364
> URL: https://issues.jboss.org/browse/WFLY-364
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Max Rydahl Andersen
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> JBIDE-11509, AS7-783 and TORQUE-576 all talk about the problem of all deployments found at startup is deployed in one operation and if one deployment fails all is rolled back resulting in some rather bad usability issues - especially at development time, but even also at production time for those using file deployments.
> Suggestion on irc was that there could be an option on the file scanner (possibly false by default?) to say that failure causes rollback.
> Individual deployments could then still fail, but at least not everything would be rolledback and it would still allow proper interdependent deployments to work.
--
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
[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 OutOfMemoryError will occur.
was:
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.
> 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
[JBoss JIRA] (WFLY-2594) Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2594?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-2594:
----------------------------------
Sure, I'll look into this.
> Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-2594
> URL: https://issues.jboss.org/browse/WFLY-2594
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JSF
> Environment: WildFly Beta2-SNAPSHOT from 2013-12-02
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> When you deploy more than one JSF application and then you undeploy one of them, you'll face following message in server log:
> {noformat}
> SEVERE [javax.faces] (MSC service thread 1-2) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
> SEVERE [javax.faces] (MSC service thread 1-2) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
> {noformat}
> I think javax.faces.FactoryFinder.FactoryManagerCache.getApplicationFactoryManager(ClassLoader) shouldn't try to create new instance of FactoryManager in this case. I am not really sure, what is special initialization case, but it seems to me that this should evaluate to true in this case (btw Does this javax.faces.FactoryFinder.FactoryManagerCache.detectSpecialInitializationCase(FacesContext) ever evaluate as true?).
--
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
[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:
--------------------------------
Description:
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.
was:
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.
Workaround Description: Disable statistics in the persistence unit. (was: Disable statistics globally or for query cache in 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 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
[JBoss JIRA] (WFLY-2594) Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-2594?page=com.atlassian.jira.plugin.... ]
Stan Silvert reassigned WFLY-2594:
----------------------------------
Assignee: Farah Juma (was: Stan Silvert)
Farah, can you look at this?
> Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-2594
> URL: https://issues.jboss.org/browse/WFLY-2594
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JSF
> Environment: WildFly Beta2-SNAPSHOT from 2013-12-02
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> When you deploy more than one JSF application and then you undeploy one of them, you'll face following message in server log:
> {noformat}
> SEVERE [javax.faces] (MSC service thread 1-2) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
> SEVERE [javax.faces] (MSC service thread 1-2) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
> {noformat}
> I think javax.faces.FactoryFinder.FactoryManagerCache.getApplicationFactoryManager(ClassLoader) shouldn't try to create new instance of FactoryManager in this case. I am not really sure, what is special initialization case, but it seems to me that this should evaluate to true in this case (btw Does this javax.faces.FactoryFinder.FactoryManagerCache.detectSpecialInitializationCase(FacesContext) ever evaluate as true?).
--
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
[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:
--------------------------------
Not really: in {{NAKACK2.removeAndPassUp()}}, we take the highest seqno of the message batch *after it's been pushed up and returned* and set the highest application digest seqno to it.
> 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
12 years, 7 months