June 2018 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (SWSQE-11) Create test plan for RH Scale Lab

by Michael Foley (JIRA)

[ https://issues.jboss.org/browse/SWSQE-11?page=com.atlassian.jira.plugin.s... ] Michael Foley commented on SWSQE-11: ------------------------------------ Please consider doing this on the developer Jira project ... for greater transparency on activies and results. > Create test plan for RH Scale Lab > --------------------------------- > > Key: SWSQE-11 > URL: https://issues.jboss.org/browse/SWSQE-11 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-286) HTTP Digest Authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-286?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-286: -------------------------------------- I would like us to be able to support all the options related to Digest authentication, how feasible that is at the moment I am not so sure but that should start to drop out during analysis. > HTTP Digest Authentication > -------------------------- > > Key: ELY-286 > URL: https://issues.jboss.org/browse/ELY-286 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > > Original Digest RFC [https://tools.ietf.org/html/rfc2069] > Current Digest RFC [https://tools.ietf.org/html/rfc2617] > HTTP 1.1 Authentication (Updates RFC2617) [https://tools.ietf.org/html/rfc7235] > Draft currently under discussion - [https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/] > RFC7616 Now Proposed Standard > "HTTP Digest Access Authentication", September 2015 > [https://www.rfc-editor.org/info/rfc7616] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-286) HTTP Digest Authentication

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-286?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-286: -------------------------------- [~dlofthouse] are we going to support `userhash` parameter on server? (it requires a lookup of the identity by hash of the username - probably to obtain identity from security realm by something like DigestEvidence?) > HTTP Digest Authentication > -------------------------- > > Key: ELY-286 > URL: https://issues.jboss.org/browse/ELY-286 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > > Original Digest RFC [https://tools.ietf.org/html/rfc2069] > Current Digest RFC [https://tools.ietf.org/html/rfc2617] > HTTP 1.1 Authentication (Updates RFC2617) [https://tools.ietf.org/html/rfc7235] > Draft currently under discussion - [https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/] > RFC7616 Now Proposed Standard > "HTTP Digest Access Authentication", September 2015 > [https://www.rfc-editor.org/info/rfc7616] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2606) Drools 7 KieServices.Factory.get() returns null

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2606: ----------------------------------- Summary: Drools 7 KieServices.Factory.get() returns null Key: DROOLS-2606 URL: https://issues.jboss.org/browse/DROOLS-2606 Project: Drools Issue Type: Bug Components: kie server Affects Versions: 7.5.0.Final Environment: JBoss Fuse 6.3.0.redhat-187 Drools version: 7.5.0.Final-redhat-4 Reporter: Tom Dalbo Assignee: Mario Fusco It seems that there might be a regression from Drools 6.x. This line in my code worked fine: {{KieServices ks = KieServices.Factory.get()}} But now does not. The only thing I did was upgrade these dependencies in my pom.xml (as well as updated my OSGi features to install the right bundles) org.drools.drools-core org.drools.drools-compiler org.kie.kie-api org.kie.soup.kie-soup-project-datamodel-api org.kie.soup.kie-soup-commons org.kie.soup.kie-soup-project-datamodel-commons Lastly, there have been a few StackOverflows related to this, but none of the answers are overwhelmingly positive: https://stackoverflow.com/questions/49295671/kieservices-factory-get-retu... https://stackoverflow.com/questions/47556233/drools-7-4-1-kieservices-fac... https://groups.google.com/forum/#!topic/jbpm-usage/aD58UTCqu-c -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2559) Drools 7 KieServices.Factory.get() returns null

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2559?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2559. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/droolsjbpm-knowledge/commit/9c26878f8ecda6f04... https://github.com/kiegroup/drools/commit/daf2b0d2f30f2a24c43e5c03f9032f9... > Drools 7 KieServices.Factory.get() returns null > ----------------------------------------------- > > Key: DROOLS-2559 > URL: https://issues.jboss.org/browse/DROOLS-2559 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.5.0.Final > Environment: JBoss Fuse 6.3.0.redhat-187 > Drools version: 7.5.0.Final-redhat-4 > Reporter: Tom Dalbo > Assignee: Mario Fusco > > It seems that there might be a regression from Drools 6.x. This line in my code worked fine: > {{KieServices ks = KieServices.Factory.get()}} > But now does not. The only thing I did was upgrade these dependencies in my pom.xml (as well as updated my OSGi features to install the right bundles) > org.drools.drools-core > org.drools.drools-compiler > org.kie.kie-api > org.kie.soup.kie-soup-project-datamodel-api > org.kie.soup.kie-soup-commons > org.kie.soup.kie-soup-project-datamodel-commons > Lastly, there have been a few StackOverflows related to this, but none of the answers are overwhelmingly positive: > https://stackoverflow.com/questions/49295671/kieservices-factory-get-retu... > https://stackoverflow.com/questions/47556233/drools-7-4-1-kieservices-fac... > https://groups.google.com/forum/#!topic/jbpm-usage/aD58UTCqu-c -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2559) Drools 7 KieServices.Factory.get() returns null

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2559?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-2559: -------------------------------- Sprint: RHPAM7-Iteration13 > Drools 7 KieServices.Factory.get() returns null > ----------------------------------------------- > > Key: DROOLS-2559 > URL: https://issues.jboss.org/browse/DROOLS-2559 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.5.0.Final > Environment: JBoss Fuse 6.3.0.redhat-187 > Drools version: 7.5.0.Final-redhat-4 > Reporter: Tom Dalbo > Assignee: Mario Fusco > > It seems that there might be a regression from Drools 6.x. This line in my code worked fine: > {{KieServices ks = KieServices.Factory.get()}} > But now does not. The only thing I did was upgrade these dependencies in my pom.xml (as well as updated my OSGi features to install the right bundles) > org.drools.drools-core > org.drools.drools-compiler > org.kie.kie-api > org.kie.soup.kie-soup-project-datamodel-api > org.kie.soup.kie-soup-commons > org.kie.soup.kie-soup-project-datamodel-commons > Lastly, there have been a few StackOverflows related to this, but none of the answers are overwhelmingly positive: > https://stackoverflow.com/questions/49295671/kieservices-factory-get-retu... > https://stackoverflow.com/questions/47556233/drools-7-4-1-kieservices-fac... > https://groups.google.com/forum/#!topic/jbpm-usage/aD58UTCqu-c -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2018