[Red Hat JIRA] (WFLY-14434) Heap usage continuously growing and exhausting available heap memory in production
by Manas Panda (Jira)
[ https://issues.redhat.com/browse/WFLY-14434?page=com.atlassian.jira.plugi... ]
Manas Panda commented on WFLY-14434:
------------------------------------
Thank you so much Paul.
> Heap usage continuously growing and exhausting available heap memory in production
> ----------------------------------------------------------------------------------
>
> Key: WFLY-14434
> URL: https://issues.redhat.com/browse/WFLY-14434
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Manas Panda
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: Heap_Size_keeps_increasing.jpg, Heap_dump_analysis_1.jpg
>
>
> # Problem description:
> Critical issue of heap usage continuously growing and exhausting available heap memory in production. As you can see in below heap dump org.infinispan.container.impl.DefaultDataContainer is growing as the time passes and not garbage collected by GC. This increase in heap happening after upgrading from Wildfly 10.1 to Wildfly 18.0.1. There is no change in JDK in both cases ( Wildfly 10.1 and Wildfly 18.0.1).
> 2. Web application environment
> * OS: RHEL 7.5
> * Wildfly 18.0.1
> * JDK 1.8
> * Wildfly is being run in cluster mode
> * Integrated with Keycloak 3.4.3 for SSO ( SAML)
> * Enabled Wildfly clustering mode
> * G1GC garbage collector used. And 20gigs of heap allocated ( -Xmx)
> * Environment of Web App on Wildfly 10.1 is same ( except Wildfly 18) with same hardware
> * Web application uses Spring web framework and security
> 3. Heap dump analysis
> * We have few web users logging in and every second and external application consuming few API’s exposed by same application.
> * As you can see infinispan.container.impl.DefaultDataContainer Has already grown 14gigs.
> * Please note that web application does not use infinispan directly.
> * The heap does not grow in wildfly 10.1 and its normal ( garbage gets collected and size gets reduced after GC)
> Please find the snapshot as attached.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 2 months
[Red Hat JIRA] (WFLY-14052) EE 9 jms/core20/jmscontexttopictests#getMetaDataTest tests expects JMS version 3.0 but is seeing 2.0
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-14052?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFLY-14052.
-------------------------------------
Fix Version/s: 23.0.0.Beta1
Resolution: Done
> EE 9 jms/core20/jmscontexttopictests#getMetaDataTest tests expects JMS version 3.0 but is seeing 2.0
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-14052
> URL: https://issues.redhat.com/browse/WFLY-14052
> Project: WildFly
> Issue Type: Sub-task
> Components: JMS
> Reporter: Scott Marlow
> Assignee: Emmanuel Hugonnet
> Priority: Major
> Labels: EE9
> Fix For: 23.0.0.Beta1
>
>
> {quote}
> \u001b[0m\u001b[0m13:52:58,657 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: Error: incorrect JMSVersion=2.0
> \u001b[0m\u001b[0m13:52:58,657 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: Error: incorrect JMSMajorVersion=2
> \u001b[0m\u001b[0m13:52:58,657 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: getMetaDataTest failed
> \u001b[0m\u001b[0m13:52:58,658 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: Test case throws exception: getMetaDataTest failed
> \u001b[0m\u001b[0m13:52:58,658 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: Exception at:
> \u001b[0m\u001b[0m13:52:58,658 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: com.sun.ts.lib.harness.EETest$Fault: getMetaDataTest failed
> \u001b[0m\u001b[0m13:52:58,658 INFO [stdout] (Thread-161) at com.sun.ts.tests.jms.core20.jmscontexttopictests.Client.getMetaDataTest(Client.java:475)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at java.lang.reflect.Method.invoke(Method.java:498)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.EETest.run(EETest.java:596)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:40)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> \u001b[0m\u001b[0m13:52:58,660 INFO [stdout] (Thread-161) at java.lang.reflect.Method.invoke(Method.java:498)
> \u001b[0m\u001b[0m13:52:58,660 INFO [stdout] (Thread-161) at org.jboss.as.appclient.service.ApplicationClientStartService$1.run(ApplicationClientStartService.java:99)
> \u001b[0m\u001b[0m13:52:58,660 INFO [stdout] (Thread-161) at java.lang.Thread.run(Thread.java:748)
> {quote}
> [jakarta.jms.ConnectionMetaData.classConnectionMetaData|https://jakarta.ee/specifications/messaging/3.0/apidocs/] is returning Jakarta EE 8 versions instead of Jakarta EE 9.0 versions
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (JBMETA-420) Add the EE 9 xsds
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/JBMETA-420?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved JBMETA-420.
-------------------------------------
Fix Version/s: 14.0.0.Beta1
Resolution: Done
> Add the EE 9 xsds
> -----------------
>
> Key: JBMETA-420
> URL: https://issues.redhat.com/browse/JBMETA-420
> Project: JBoss Metadata
> Issue Type: Enhancement
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 14.0.0.Beta1
>
>
> Follow up on JBMETA-419 by adding the relevant EE 9 xsd documents.
> They're not final yet so I figure it's better to add them separately from the JBMETA-419 parsing enhancement, which isn't particularly reliant on the exact schema files.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months