[
https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin...
]
Scott Marlow commented on WFLY-12671:
-------------------------------------
[~rschimpf] could you please recreate the memory leak (with WF17 is fine) and in Eclipse
Memory Analyzer, open the histogram, you can filter to only show
PersistenceUnitMetadataImpl if you like or just scroll to PersistenceUnitMetadataImpl.
Then, do:
# Right mouse button click on the PersistenceUnitMetadataImpl row
# Choose Merge Shortest Paths to GC roots
# Choose Exclude all phantom/weak/soft etc. references
# In the merge_shortest_paths window, fully expand the displayed tree
# Select all of the displayed rows and copy to clipboard
# Paste clipboard here (or attach as text file attachment).
Here is what I see after deploying a small app with WildFly 18.0.0.Final and deleting the
standalone/deployments/myapp.jar.deployed file, which undeploys myapp.jar:
{code}
Class Name
| Ref. Objects | Shallow Heap | Ref. Shallow Heap |
Retained Heap
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
java.lang.Thread @ 0xe1741c30 IdleRemover Thread
| 1 | 120 | 112 |
328
'- <Java Local>
org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner @ 0xe1a0d1d8
| 1 | 16 | 112 | 16
'- this$0 org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover @ 0xe184d1e0
| 1 | 56 |
112 | 184
'- registeredPools java.util.concurrent.CopyOnWriteArrayList @ 0xe184d218
| 1 | 24 |
112 | 96
'- array java.lang.Object[1] @ 0xe2df46e8
| 1 | 24 |
112 | 24
'- [0]
org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool
@ 0xe2df4700| 1 | 88 | 112 | 1,416
'- mcf org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory
@ 0xe1dd6ec8 | 1 | 216 |
112 | 776
'- originalTCCL org.jboss.modules.ModuleClassLoader @ 0xe27d0380
| 1 | 88 |
112 | 125,760
'- transformer org.jboss.modules.JLIClassTransformer @ 0xe2804560
| 1 | 16 |
112 | 152
'- transformer
org.jboss.as.server.deployment.module.DelegatingClassFileTransformer @ 0xe2804570
| 1 | 24 | 112 | 136
'- delegateTransformers
java.util.concurrent.CopyOnWriteArrayList @ 0xe2804588 |
1 | 24 | 112 | 112
'- array java.lang.Object[1] @ 0xe28045d0
| 1 | 24 |
112 | 40
'- [0]
org.jboss.as.jpa.classloader.JPADelegatingClassFileTransformer @ 0xe28045e8 |
1 | 16 | 112 | 16
'- persistenceUnitMetadata
org.jboss.as.jpa.config.PersistenceUnitMetadataImpl @ 0xe28045f8 | 1 |
112 | 112 | 9,208
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{code}
Let me know if you see the same or something different.
Memory Leak of PersistenceUnitMetadataImpl
------------------------------------------
Key: WFLY-12671
URL:
https://issues.jboss.org/browse/WFLY-12671
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 17.0.1.Final
Reporter: Robin Schimpf
Assignee: Scott Marlow
Priority: Major
Attachments: Trying_to_catch_memory_leak_with_more_trace_logging.patch, memory
leak after 4 deployments.PNG, memory leak after 5 deployments.PNG, memory leak with
directory scanner undeploy and deploy.PNG, persistence-unit-not-stopped.txt,
persistence-unit-stopped.txt
After updating from Wildfly 13 to Wildfly 17 we noticed a slowdown of our application
after multiple deployments to the application server without restarting it between the
deployments. Heapdumps are showing that after redeployment the number of
{{PersistenceUnitMetadataImpl}} are growing (see screenshots).
We are deploying 2 ear files and 2 war files. Only one ear has a database connection
configured. We are using the bundeled hibernate version of Wildfly 17.
The ear structure is like the following:
{noformat}
- app.ear
|
|- META-INF
|
|- lib
| |
| |- all dependencies
|
|- own jars and wars (e.g. jpa)
{noformat}
Since I failed to create a reproducing project for this behaviour I added some trace
logging (Patch attached). The only difference I noticed was that sometimes the {{Stopping
Persistence Unit}} logstatement is missing before the {{Stopped subdeployment}}
logstatement.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)