[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months
[JBoss JIRA] (WFWIP-23) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
by Michal Toth (JIRA)
[ https://issues.jboss.org/browse/WFWIP-23?page=com.atlassian.jira.plugin.s... ]
Michal Toth commented on WFWIP-23:
----------------------------------
I managed to reproduce this issue in 7.1.0 & current 7.2.0 release (not GA build yet).
If 7.2.0 will be based just on artemis 2.5.x branch, then this fix won't be in it. Fixed in 2.6.0.
I have tried 2.6.0, but I lost 1 message. Maybe during client reconnecting/failover. I was using Core protocol.
> [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-23
> URL: https://issues.jboss.org/browse/WFWIP-23
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jiri Ondrusek
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: journal-node-2.txt
>
>
> There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
> Test Scenario:
> * start two servers in cluster (JGroups used for discovery)
> * send messages to testQueue0 on node-1 and node-2
> * wait until consumers on both nodes receive 300 messages
> * cleanly shut down 1st and then 2nd server
> * leave servers shut down for one minute
> * start both servers
> * wait until both consumers receive 500 messages
> * stop sending messages and receive all remaining messages
> Pass Criteria: All send messages are received by consumer
> Actual Result: There are lost messages.
> Investigation:
> There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
> I'm attaching trace logs from client and servers and content of journal from 2nd server.
> This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months