[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Parul Sharma updated WFLY-10137:
--------------------------------
Comment: was deleted
(was: [~crazycradd] Can you quickly see below issues: is this issues were you facing? otherwise we need to look into that forum.
Adding 204 and 340 via the remote stateless calculator deployed on the server
Exception in thread "main" javax.ejb.EJBException: javax.naming.AuthenticationException: WFHTTP000013: Authentication failed (full response ClientResponse{responseHeaders={www-authenticate=[Digest realm="ApplicationRealm", nonce="AAAAAgAANmMw7plvVHUZLnwvMwkp9bw9JstLLmulwvu6Bm+r0XWoiyiTsYI=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth], content-length=[77], content-type=[text/html], date=[Tue, 24 Mar 2020 11:07:46 GMT]}, responseCode=401, status='', protocol=HTTP/2.0})
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:221)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy2.add(Unknown Source)
at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:59)
at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:40)
Caused by: javax.naming.AuthenticationException: WFHTTP000013: Authentication failed (full response ClientResponse{responseHeaders={www-authenticate=[Digest realm="ApplicationRealm", nonce="AAAAAgAANmMw7plvVHUZLnwvMwkp9bw9JstLLmulwvu6Bm+r0XWoiyiTsYI=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth], content-length=[77], content-type=[text/html], date=[Tue, 24 Mar 2020 11:07:46 GMT]}, responseCode=401, status='', protocol=HTTP/2.0})
at org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:232)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.256 s
[INFO] Finished at: 2020-03-24T16:37:47+05:30
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.6.0:exec (default-cli) on project ejb-remote-client: Command execution failed.: Process exited with an error: 1 (Exit value: 1) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
)
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Assignee: Parul Sharma
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-10137:
-------------------------------------
[~crazycradd] Can you quickly see below issues: is this issues were you facing? otherwise we need to look into that forum.
Adding 204 and 340 via the remote stateless calculator deployed on the server
Exception in thread "main" javax.ejb.EJBException: javax.naming.AuthenticationException: WFHTTP000013: Authentication failed (full response ClientResponse{responseHeaders={www-authenticate=[Digest realm="ApplicationRealm", nonce="AAAAAgAANmMw7plvVHUZLnwvMwkp9bw9JstLLmulwvu6Bm+r0XWoiyiTsYI=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth], content-length=[77], content-type=[text/html], date=[Tue, 24 Mar 2020 11:07:46 GMT]}, responseCode=401, status='', protocol=HTTP/2.0})
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:221)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy2.add(Unknown Source)
at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:59)
at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:40)
Caused by: javax.naming.AuthenticationException: WFHTTP000013: Authentication failed (full response ClientResponse{responseHeaders={www-authenticate=[Digest realm="ApplicationRealm", nonce="AAAAAgAANmMw7plvVHUZLnwvMwkp9bw9JstLLmulwvu6Bm+r0XWoiyiTsYI=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth], content-length=[77], content-type=[text/html], date=[Tue, 24 Mar 2020 11:07:46 GMT]}, responseCode=401, status='', protocol=HTTP/2.0})
at org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:232)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.256 s
[INFO] Finished at: 2020-03-24T16:37:47+05:30
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.6.0:exec (default-cli) on project ejb-remote-client: Command execution failed.: Process exited with an error: 1 (Exit value: 1) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Assignee: Parul Sharma
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4596) Write lock is acquired reading patching resource using include-runtime
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFCORE-4596?page=com.atlassian.jira.plug... ]
Ingo Weiss updated WFCORE-4596:
-------------------------------
Labels: downstream_dependency (was: )
> Write lock is acquired reading patching resource using include-runtime
> ----------------------------------------------------------------------
>
> Key: WFCORE-4596
> URL: https://issues.redhat.com/browse/WFCORE-4596
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Reporter: Yeray Borges Santana
> Assignee: Yeray Borges Santana
> Priority: Major
> Labels: downstream_dependency
> Fix For: 11.0.0.Beta3, 11.0.0.Final
>
>
> This is initially created as a bug but it needs first some investigation to discover if it is really necessary to acquire the write lock when the patching resource is read. If it is unnecessary, we should remove this need.
> The following operation is acquiring the write lock:
> {noformat}
> /host=slave/core-service=patching:read-resource(include-runtime=true)
> {noformat}
> It potentially will block if there is any other operation that has already acquired the lock. One consequence found due to this issue was HAL could block and hang if an HC is starting and the user clicks on 'Patching' menu entry. It was fixed in HAL, where an HC being restarted is no longer shown in the Patching menu.
> The main problem seems to be in PatchStreamResourceOperationStepHandler, which is the parent handler used for the handlers that manage patching operations. This parent handler is always acquiring the write lock.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Peter Craddoock (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Peter Craddoock commented on WFLY-10137:
----------------------------------------
can you search the old site ?
https://developer.jboss.org/en/wildfly/overview
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Assignee: Parul Sharma
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Peter Craddoock (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Peter Craddoock commented on WFLY-10137:
----------------------------------------
I'll see what I can do this happened a long time ago and I have worked around the code since then. Saying that I guess i would have raised this in a chat forum and been asked to raise it here so I'll have a quick look.
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Assignee: Parul Sharma
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Parul Sharma edited comment on WFLY-10137 at 3/24/20 6:49 AM:
--------------------------------------------------------------
[~crazycradd] Can you provide me error logs? or what errors were you facing?
was (Author: parsharma):
[~crazycradd] Can you provide me error logs?
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Assignee: Parul Sharma
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10137) EJB lookup over HTTP fails if object is used in the signiture
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-10137?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-10137:
-------------------------------------
[~crazycradd] Can you provide me error logs?
> EJB lookup over HTTP fails if object is used in the signiture
> -------------------------------------------------------------
>
> Key: WFLY-10137
> URL: https://issues.redhat.com/browse/WFLY-10137
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 11.0.0.Final
> Reporter: peter craddock
> Assignee: Parul Sharma
> Priority: Major
>
> I have a swing client that makes calls to the EJB tier via RMI the majority of the calls work fine using the workaround from WFLY-9636.
> The following calls was failing when connected over HTTP but was fine when using the original TCP connection
> public EntityList getAllWorkingSetsForCube( ModelRef modelRef, FinanceCubeRef financeCubeRef, int userId, Integer[] allowedStates )
> I worked round this and found that creating a method without the Integer[] as part of the signature works.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled
by Sorin Potra (Jira)
[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ]
Sorin Potra commented on WFLY-13259:
------------------------------------
Before raising this bug I investigated a bit some heap dumps and did some debugging and found the following (please note that I am not an expert in Hibernate / Infinispan so my conclusions might not be very accurate):
- when a new entity is persisted, Hibernate tries to determine if the entity is new or detached. For this it performs a find in the L2 cache and the database. For new entities (our case) the find will add an entry in the pending-puts cache by calling PutFromLoadValidator.registerPendingPut() before reaching to the DB. For new entities the find will not yield any results from the DB so PutFromLoadValidator.acquirePutFromLoadLock() is not called which basically leaks the pending-puts entry in the cache. This pending-puts entry contains a reference to org.hibernate.internal.SessionImpl which can be quite a large object for large transactions (transactions that load a lot of entities in their PersistenceContext).
- normally the entry in the pending-puts cache expires in 60s so it will be removed from the cache by the reaping thread. However this is still a leak as we need to keep data in memory for longer than required by the application.
- In our case the situation is even worse as the next transaction will load the collection of Files (Children) again and this will cause the load of all its child entities, including the previously added File, which in turn will access the pending-puts entry, effectively resetting its "lastUsed" field and preventing it from expire.
- The above repeats for each subsequent transaction. This raises another potential issue. From my observations, it seems that at the end of each transaction, the collection entry in the L2 cache is invalidated. This is correct as the collection has been modified by the addition of the newly created File entity. However it also seems that all File entities in the L2 cache are also invalidated which will cause them to be reloaded from the DB during the next transaction. This does not seem to be correct as the existing File entities are not modified in the current transaction. This also causes a performance hit as the L2 cache is basically bypassed for these entities. So this invalidation of the L2 cache entries ensures that the leaked entries in the pending-puts are never removed with each new transaction adding a new such entry in the pending-puts cache.
As a workaround I implemented some logic to manually remove the leaked pending-puts entry after each entity persistence. So basically I'm performing the following steps:
- get a reference to the pending-puts cache by looking up the hibernate CacheContainer in the JNDI and then getting the pending-puts cache
- Get the PendingPutMap entry from the cache, for the key of the entity that has just been persisted
- Using reflection, get a reference to the PutFromLoadValidator instance for the PendingPutMap
- Call acquirePutFromLoadLock() on the above PutFromLoadValidator which will remove the leaked entry from the pending-puts cache
You can find the code in the source code archive attached to this issue (See com.microfocus.sa.persistence.JPAUtil.removePendingPutAfterCreate()).
With this method called after each entity persistence, the problem does not reproduce anymore. However this has the big disadvantage that it uses Hibernate / Infinispan internal classes so it might become invalid in future WildFly releases.
And then there is the performance impact of continuously loading the File entities from the DB instead of L2 cache. But the performance issue is less severe as our importer runs as a background process (although we might be affected by this on other application flows too).
Hope this makes sense, please let me know in case you need more details.
> 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