[JBoss JIRA] (DROOLS-4651) Scenario: Review Save interaction in Settings panel.
by Elizabeth Clayton (Jira)
Elizabeth Clayton created DROOLS-4651:
-----------------------------------------
Summary: Scenario: Review Save interaction in Settings panel.
Key: DROOLS-4651
URL: https://issues.jboss.org/browse/DROOLS-4651
Project: Drools
Issue Type: Enhancement
Components: Test Scenarios Editor
Reporter: Elizabeth Clayton
Assignee: Toni Rikkola
The use of a Save button in the Settings panel is inconsistent with other "properties" panel in the overall application. The purpose of this jira is to revisit the use case scenarios to determine if the inclusion of the Save button here is appropriate.
Verification conditions:
* Documented rationale for the keeping the Save button, as is, with Team acceptance.
or
* Documented rationale for removing the Save button, with Team acceptance, in addition to any design changes needed as a result of its removal.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Robin Schimpf (Jira)
[ https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin... ]
Robin Schimpf commented on WFLY-12671:
--------------------------------------
I think you are correct and the application was still deployed. I will create the heapdump tomorrow and report back.
> 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)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Scott Marlow (Jira)
[ 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)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Robin Schimpf (Jira)
[ https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin... ]
Robin Schimpf commented on WFLY-12671:
--------------------------------------
I used the heapdump from the {{memory leak after 5 deployments.png}} screenshot and got this as result
{code}
Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| | | |
class java.lang.ApplicationShutdownHooks @ 0x801041b0 System Class | 3 | 8 | 336 | 111.370.344
'- hooks java.util.IdentityHashMap @ 0x8033ba98 | 3 | 40 | 336 | 111.370.336
'- table java.lang.Object[64] @ 0x8033bac0 | 3 | 272 | 336 | 111.370.296
|- [24], [25] org.quartz.plugins.management.ShutdownHookPlugin$1 @ 0x8e90adb0 Quartz Shutdown-Hook TaskScheduler | 1 | 128 | 112 | 371.008
| '- val$scheduler org.quartz.impl.StdScheduler @ 0x8721c208 | 1 | 16 | 112 | 370.400
| '- sched org.quartz.core.QuartzScheduler @ 0x8721c218 | 1 | 88 | 112 | 370.384
|- [46], [47] org.quartz.plugins.management.ShutdownHookPlugin$1 @ 0xb036f5f8 Quartz Shutdown-Hook TaskScheduler | 1 | 128 | 112 | 371.192
| '- val$scheduler org.quartz.impl.StdScheduler @ 0x8821c4a0 | 1 | 16 | 112 | 370.584
| '- sched org.quartz.core.QuartzScheduler @ 0x8821c4b0 | 1 | 88 | 112 | 370.568
|- [48], [49] org.quartz.plugins.management.ShutdownHookPlugin$1 @ 0xbbc306a0 Quartz Shutdown-Hook TaskScheduler | 1 | 128 | 112 | 371.128
| '- val$scheduler org.quartz.impl.StdScheduler @ 0xaf4f5fd8 | 1 | 16 | 112 | 370.520
| '- sched org.quartz.core.QuartzScheduler @ 0xaf4f5fe8 | 1 | 88 | 112 | 370.504
'- Total: 3 entries | | | |
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread @ 0xeb29d310 Lucene Merge Thread #2 for index Files Native Stack, Thread | 2 | 136 | 224 | 50.291.968
|- <JNI Local> class org.jboss.as.jpa.subsystem.PersistenceUnitRegistryImpl @ 0x8869d388 | 1 | 8 | 112 | 8
| '- INSTANCE org.jboss.as.jpa.subsystem.PersistenceUnitRegistryImpl @ 0x96314ff8 | 1 | 16 | 112 | 208
| '- registry java.util.Collections$SynchronizedMap @ 0x96315008 | 1 | 32 | 112 | 192
| '- m java.util.HashMap @ 0x96315028 | 1 | 48 | 112 | 160
| '- table java.util.HashMap$Node[16] @ 0x96315058 | 1 | 80 | 112 | 112
| '- [1] java.util.HashMap$Node @ 0xd339c0d8 | 1 | 32 | 112 | 32
| '- value org.jboss.as.jpa.service.PersistenceUnitServiceImpl @ 0xcf2e8470 | 1 | 80 | 112 | 1.192
| '- pu org.jboss.as.jpa.config.PersistenceUnitMetadataImpl @ 0xd15a74d0 | 1 | 112 | 112 | 86.151.344
|- <JNI Local> class org.jboss.resteasy.plugins.providers.jsonb.AbstractJsonBindingProvider @ 0xa61cafe8 | 1 | 16 | 112 | 343.456
| '- jsonbObj org.eclipse.yasson.internal.JsonBinding @ 0x8d477108 | 1 | 16 | 112 | 343.384
| '- jsonbContext org.eclipse.yasson.internal.JsonbContext @ 0x8d477118 | 1 | 48 | 112 | 343.368
| '- componentInstanceCreator org.eclipse.yasson.internal.components.BeanManagerInstanceCreator @ 0x8d477238 | 1 | 24 | 112 | 1.000
| '- beanManager org.jboss.weld.bean.builtin.BeanManagerProxy @ 0x84d725a8 | 1 | 24 | 112 | 24
| '- manager org.jboss.weld.manager.BeanManagerImpl @ 0x8d4783a0 | 1 | 152 | 112 | 8.880
| '- services org.jboss.weld.bootstrap.api.helpers.SimpleServiceRegistry @ 0x8d478438 | 1 | 24 | 112 | 4.328
| '- services java.util.HashMap @ 0x8d478450 | 1 | 48 | 112 | 3.504
| '- table java.util.HashMap$Node[128] @ 0x8d478490 | 1 | 528 | 112 | 3.440
| '- [24] java.util.HashMap$Node @ 0x8d4788d0 | 1 | 32 | 112 | 32
| '- value org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices @ 0x8d4788f0 | 1 | 40 | 112 | 40
| '- applicationDescription org.jboss.as.ee.component.EEApplicationDescription @ 0x85a796f0 | 1 | 24 | 112 | 396.064
| '- componentsByName java.util.HashMap @ 0x85a93900 | 1 | 48 | 112 | 44.216
| '- table java.util.HashMap$Node[512] @ 0x85a93930 | 1 | 2.064 | 112 | 44.168
| '- [45] java.util.HashMap$Node @ 0x85a94140 | 1 | 32 | 112 | 104
| '- value java.util.ArrayList @ 0x85a94160 | 1 | 24 | 112 | 72
| '- elementData java.lang.Object[1] @ 0x85a94178 | 1 | 24 | 112 | 48
| '- [0] org.jboss.as.ee.component.EEApplicationDescription$Description @ 0x85a94190 | 1 | 24 | 112 | 24
| '- componentDescription org.jboss.as.ejb3.component.stateless.StatelessComponentDescription @ 0x98216790 | 1 | 272 | 112 | 4.696
| '- moduleDescription org.jboss.as.ee.component.EEModuleDescription @ 0x982162b0 | 1 | 88 | 112 | 100.728
| '- classDescriptions java.util.HashMap @ 0x9829a5e8 | 1 | 48 | 112 | 85.368
| '- table java.util.HashMap$Node[128] @ 0x9829a628 | 1 | 528 | 112 | 85.304
| '- [40] java.util.HashMap$Node @ 0x9829ad58 | 1 | 32 | 112 | 752
| '- value org.jboss.as.ee.component.EEModuleClassDescription @ 0x9829ad90 | 1 | 40 | 112 | 696
| '- bindingConfigurations java.util.ArrayList @ 0x9829ae08 | 1 | 24 | 112 | 232
| '- elementData java.lang.Object[10] @ 0x9829ae20 | 1 | 56 | 112 | 208
| '- [0] org.jboss.as.ee.component.BindingConfiguration @ 0x9829ae58 | 1 | 24 | 112 | 152
| '- source org.jboss.as.jpa.injectors.PersistenceContextInjectionSource @ 0x9829ae88 | 1 | 24 | 112 | 128
| '- injectable org.jboss.as.jpa.injectors.PersistenceContextInjectionSource$PersistenceContextJndiInjectable @ 0x9829aea0| 1 | 48 | 112 | 72
| '- pu org.jboss.as.jpa.config.PersistenceUnitMetadataImpl @ 0x9829af08 | 1 | 112 | 112 | 85.624.920
'- Total: 2 entries | | | |
Total: 2 entries | 5 | 144 | 560 |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{code}
Seems like lucene is holding the context which we use via the hibernate-search contained in Wildfly.
The ApplicationShutdownHooks tree is not fully expanded because there are coming some internal classes. The leaking there is most likely due to some of our code.
> 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)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin... ]
Scott Marlow edited comment on WFLY-12671 at 10/16/19 8:44 AM:
---------------------------------------------------------------
[~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 (or see attached jcaleakmarlow.txt):
{quote}
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
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{quote}
Let me know if you see the same or something different.
was (Author: smarlow):
[~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:
{quote}
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
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{quote}
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, 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)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12671:
--------------------------------
Attachment: jcaleakmarlow.txt
> 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)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin... ]
Scott Marlow edited comment on WFLY-12671 at 10/16/19 8:42 AM:
---------------------------------------------------------------
[~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:
{quote}
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
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{quote}
Let me know if you see the same or something different.
was (Author: smarlow):
[~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)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Scott Marlow (Jira)
[ 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)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Robin Schimpf (Jira)
[ https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin... ]
Robin Schimpf commented on WFLY-12671:
--------------------------------------
The new deployment strategy has a different object graph in the memory but the objects are still there (see memory leak with directory scanner undeploy and deploy.PNG) and this time referenced in the {{java.lang.ApplicationShutdownHooks}}.
Also upgrading to Wildfly 18 does not solve the issue.
> 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)
6 years, 9 months
[JBoss JIRA] (WFLY-12671) Memory Leak of PersistenceUnitMetadataImpl
by Robin Schimpf (Jira)
[ https://issues.jboss.org/browse/WFLY-12671?page=com.atlassian.jira.plugin... ]
Robin Schimpf updated WFLY-12671:
---------------------------------
Attachment: memory leak with directory scanner undeploy and deploy.PNG
> 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)
6 years, 9 months