[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 resolved WFLY-13259.
---------------------------------
Resolution: Duplicate Issue
Duplicate of [https://hibernate.atlassian.net/browse/HHH-13916]
> 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: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Optional
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25
>
>
> 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)
5 years, 11 months
[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:
-------------------------------------
[~spotra] in theory, you could explore understanding why the cache.evict(cls,pk) is no longer working for you. Please do communicate that as a possible solution via issue [https://hibernate.atlassian.net/browse/HHH-13916], so that others could possibly use the same solution if you can help resolve that.
I'll close [WFLY-13259], as there aren't any WildFly code changes to make for this issue.
> 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: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Optional
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25
>
>
> 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)
5 years, 11 months
[JBoss JIRA] (WFLY-13547) Smallrye OpenAPI throws java.lang.NullPointerException when processing JAX-RS resources which define methods acception a SortedSet type parameter
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13547?page=com.atlassian.jira.plugi... ]
Paul Ferraro moved JBEAP-19602 to WFLY-13547:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13547 (was: JBEAP-19602)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: MP OpenAPI
(was: MP OpenAPI)
Affects Version/s: 20.0.0.Beta1
(was: EAP-XP-1.0.0.GA-CR1)
(was: EAP-XP-1.0.0.GA-CR2)
> Smallrye OpenAPI throws java.lang.NullPointerException when processing JAX-RS resources which define methods acception a SortedSet type parameter
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13547
> URL: https://issues.redhat.com/browse/WFLY-13547
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI
> Affects Versions: 20.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Deployment of WAR containing JAX-RS resource classes which define methods accepting parameters of type {{SortedSet}} will fail with a NPE.
> {{SortedSet}} is allowed by JAX-RS spec: https://docs.oracle.com/javaee/7/api/javax/ws/rs/FormParam.html
> The following stack trace represents the output of a deployment failure when an attempt to deploy a WAR with such a resource:
> {code}
> Caused by: java.lang.NullPointerException
> at io.smallrye.openapi.runtime.scanner.ParameterProcessor.setSchemaProperties(ParameterProcessor.java:637)
> at io.smallrye.openapi.runtime.scanner.ParameterProcessor.getFormBodyContent(ParameterProcessor.java:605)
> at io.smallrye.openapi.runtime.scanner.ParameterProcessor.process(ParameterProcessor.java:404)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:577)
> at io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> ...
> {code}
> The failure was initially noticed while testing RESTEasy against EAP XP 1.0.0 CR1 and CR2.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13545) Smallrye OpenAPI annotaton scanner throws StackOverflowError when processing JAX-RS resource classes which implement a locator that will return the class itself
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13545?page=com.atlassian.jira.plugi... ]
Paul Ferraro moved JBEAP-19601 to WFLY-13545:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13545 (was: JBEAP-19601)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: MP OpenAPI
(was: MP OpenAPI)
Affects Version/s: 20.0.0.Beta1
(was: EAP-XP-1.0.0.GA-CR1)
(was: EAP-XP-1.0.0.GA-CR2)
> Smallrye OpenAPI annotaton scanner throws StackOverflowError when processing JAX-RS resource classes which implement a locator that will return the class itself
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13545
> URL: https://issues.redhat.com/browse/WFLY-13545
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenAPI
> Affects Versions: 20.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> When deploying a WAR which contains a JAX-RS resource class which is declaring a locator that is supposed to return the resource class itself - i.e. {{this}} - the depoyment fails with a {{StackOverflowError}}.
> The annotation scanner loops until the stack overflow happens because it tries to process the JAX-RS resource class recursively and maybe the process tself should be protected against this case.
> The following stack trace represents the output of a deployment failure when an attempt to deploy a WAR with such a resource:
> {code}
> at org.jboss.logging@3.4.1.Final-redhat-00001//org.jboss.logging.Logger.getLogger(Logger.java:2490)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.dataobject.DataObjectDeque.<init>(DataObjectDeque.java:38)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiDataObjectScanner.<init>(OpenApiDataObjectScanner.java:138)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiDataObjectScanner.process(OpenApiDataObjectScanner.java:163)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.util.SchemaFactory.typeToSchema(SchemaFactory.java:360)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:924)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1603)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsSubResource(OpenApiAnnotationScanner.java:511)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:426)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsSubResource(OpenApiAnnotationScanner.java:511)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:426)
> at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsSubResource(OpenApiAnnotationScanner.java:511)
> ...
> {code}
> The failure was initially noticed during RESTEasy tests against EAP XP 1.0.0 CR1 and CR2.
> The SmallRye OpenAPI versions that I tested this against are 1.1.21 and 1.1.22.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13542) Container does not enforce bean-managed concurrency for timeout methods
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13542?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13542:
-----------------------------------
I don't think this is a bug. See related issue AS7-3119 for detailed discussion. When multiple executions of the same timer overlaps while the first exection is still running, WildFly drops other overlapping executions of the same timer, to prevent over-flooding the bean instance and also to avoid confusing users. After all, the purpose of a specific timer is to do something at a certain time, which is already fulfilled by running the first execution.
> Container does not enforce bean-managed concurrency for timeout methods
> -----------------------------------------------------------------------
>
> Key: WFLY-13542
> URL: https://issues.redhat.com/browse/WFLY-13542
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.1.0.Final
> Reporter: Fábio Silva
> Assignee: Cheng Fang
> Priority: Major
>
> Bean-managed concurrency for @Singleton EJBs is not enforced for timeout methods annotated with @Schedule. When a timeout is fired while the previous one is still running, the timeout method is not called. Instead, WildFly logs a warning like the following:
> {code:java}
> 20:58:54,000 WARN [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=aa716284-ef7b-4bb3-a356-a8ca187255c4 timedObjectId=myweb.myweb.MySingleton auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@303bd2d5 previousRun=Sun May 31 20:57:10 BRT 2020 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sun May 31 20:58:54 BRT 2020 timerState=IN_TIMEOUT info=null] ScheduleExpression [second=0/1;minute=*;hour=*;dayOfMonth=*;month=*;dayOfWeek=*;year=*;timezoneID=null;start=null;end=null] is still in progress, skipping this overlapping scheduled execution at: Sun May 31 20:58:54 BRT 2020.
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months