[
https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin...
]
Scott Marlow commented on WFLY-12671:
-------------------------------------
With the heapdump from 5 deployments.png, does that still have the application still
deployed?
If the "Quartz Shutdown-Hook TaskScheduler" is from the (still) deployed
application, that is not really a leak.
The same is true for
"org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread".
It would be clearer, if you examine a heapdump that is from some number of deployments,
followed by undeploying the application, so we know for sure that there should be zero
PersistenceUnitMetadataImpl instances that are strongly referenced in the heap dump. Make
sense?
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,
jcaleakmarlow.txt, 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)