March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled

by Scott Marlow (Jira)

[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ] Scott Marlow commented on WFLY-13259: ------------------------------------- Hi [~spotra] I was just looking at the test case source and noticed that simple-hibernate-war/src/com/microfocus/sa/web/ParentUpdateServlet.java doesn't call em.close() on the persistence context created via the EntityManagerFactory. The same is true for simple-hibernate-war/src/com/microfocus/sa/web/L2CacheCleanupServlet.java, this may have nothing to do with pending-puts cache, but thought I would mention it. Same for simple-hibernate-war/src/com/microfocus/sa/web/DataPopulatorListener.java. Same for simple-hibernate-war/src/com/microfocus/sa/web/AddChildServlet.java. I wonder if calling em.close() would have any impact on what you are seeing. It would be good to know that. > Memory leak in Hibernate pending-puts cache when L2 cache is enabled > -------------------------------------------------------------------- > > Key: WFLY-13259 > URL: https://issues.redhat.com/browse/WFLY-13259 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 18.0.1.Final, 19.0.0.Final > Reporter: Sorin Potra > Assignee: Scott Marlow > Priority: Critical > Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war.war, simple-hibernate-war.zip > > > Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider). > Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity. > Attached you can find the following: > - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue. > - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet > - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder: > > java -cp bin com.microfocus.sa.client.AddChildClient > > If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart). > - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13265) jaxrs-jwt - changed name of realm in web.xml

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13265?page=com.atlassian.jira.plugi... ] Eduardo Martins resolved WFLY-13265. ------------------------------------ Fix Version/s: 20.0.0.Beta1 Resolution: Done > jaxrs-jwt - changed name of realm in web.xml > -------------------------------------------- > > Key: WFLY-13265 > URL: https://issues.redhat.com/browse/WFLY-13265 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Reporter: Jan Bárta > Assignee: Eduardo Martins > Priority: Minor > Fix For: 20.0.0.Beta1 > > > *configure-elytron.cli* is creating _"jwt-realm"_, but web.xml is set to _"qsRealm"_ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4891) Upgrade WildFly Elytron to 1.11.3.Final

by James Perkins (Jira)

James Perkins created WFCORE-4891: ------------------------------------- Summary: Upgrade WildFly Elytron to 1.11.3.Final Key: WFCORE-4891 URL: https://issues.redhat.com/browse/WFCORE-4891 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.1.Final, 12.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4887) Upgrade slf4j 1.7.30

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4887?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-4887: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4117 > Upgrade slf4j 1.7.30 > -------------------- > > Key: WFCORE-4887 > URL: https://issues.redhat.com/browse/WFCORE-4887 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: Jeff Mesnil > Assignee: James Perkins > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13256) Upgrade bouncycastle to 1.65.0

by Ashley Abdel-Sayed (Jira)

[ https://issues.redhat.com/browse/WFLY-13256?page=com.atlassian.jira.plugi... ] Ashley Abdel-Sayed commented on WFLY-13256: ------------------------------------------- [~jim.ma] I've been looking at upgrading bouncycastle to version 1.65 beta found here: https://downloads.bouncycastle.org/betas/. With this upgrade, I still see the 4 test failures that were originally causing issues when we upgraded to 1.64: https://ci.wildfly.org/viewLog.html?buildId=192989&tab=buildResultsDiv&bu... (same stack trace). This upgrade was supposed to fix the issue seen here https://github.com/bcgit/bc-java/issues/620 and I am not seeing a {{ClassCastException}} but it may just be getting swallowed somewhere. The 2 errors i see in the server.log file are {{JBWS024054: User principal is not available on the current message}} and the following: http://pastebin.test.redhat.com/847874 (which I am not really familiar with). I believe the "User Principal is not available on the current message" is thrown from here https://github.com/jbossws/jbossws-cxf/blob/master/modules/server/src/mai.... I was debugging {{WSTrustTestCase#testBearer}} and I realized it passes when run individually and I never reached break points in that interceptor, but I do reach that error when i ran all the WSTrustTestCase tests at once. I was wondering if you had any tips for debugging this or how I can get more information as to why these tests are failing? > Upgrade bouncycastle to 1.65.0 > ------------------------------ > > Key: WFLY-13256 > URL: https://issues.redhat.com/browse/WFLY-13256 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Server > Reporter: Bartosz Spyrko > Assignee: Brian Stansberry > Priority: Blocker > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4887) Upgrade slf4j 1.7.30

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4887?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-4887: ---------------------------------- Summary: Upgrade slf4j 1.7.30 (was: Upgrade jcl-over-slf4j 1.7.30) > Upgrade slf4j 1.7.30 > -------------------- > > Key: WFCORE-4887 > URL: https://issues.redhat.com/browse/WFCORE-4887 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: Jeff Mesnil > Assignee: James Perkins > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4434) Upgrade slf4j to 1.7.26

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4434?page=com.atlassian.jira.plug... ] James Perkins closed WFCORE-4434. --------------------------------- Resolution: Out of Date Closed in favor of WFCORE-4887 > Upgrade slf4j to 1.7.26 > ----------------------- > > Key: WFCORE-4434 > URL: https://issues.redhat.com/browse/WFCORE-4434 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: James Perkins > Priority: Major > Labels: downstream_dependency > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1931) Upgrade SmallRye JWT to 2.0.13

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1931?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1931: ---------------------------------- Fix Version/s: 1.11.4.CR1 (was: 1.11.3.Final) > Upgrade SmallRye JWT to 2.0.13 > ------------------------------ > > Key: ELY-1931 > URL: https://issues.redhat.com/browse/ELY-1931 > Project: WildFly Elytron > Issue Type: Component Upgrade > Components: MicroProfile > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.11.4.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1947) Release WildFly Elytron 1.11.3.Final

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1947?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved ELY-1947. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.11.3.Final > ------------------------------------ > > Key: ELY-1947 > URL: https://issues.redhat.com/browse/ELY-1947 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.11.3.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-267) Better handle encoding for handlers

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-267?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-267: --------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/289, https://github.com/jboss-logging/jboss-logmanager/pull/290 (was: https://github.com/jboss-logging/jboss-logmanager/pull/289) > Better handle encoding for handlers > ----------------------------------- > > Key: LOGMGR-267 > URL: https://issues.redhat.com/browse/LOGMGR-267 > Project: JBoss Log Manager > Issue Type: Enhancement > Components: core > Reporter: James Perkins > Assignee: David Lloyd > Priority: Major > Fix For: 2.2.0.Final, 3.0.0.Final > > > Currently by default handlers use a {{null}} encoding. This should default to the default charset for the platform. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2020