[jboss-jira] [JBoss JIRA] (WFLY-4617) Huge garbage created at regular intervals in Wildfly 8.2.0.Final
[
https://issues.jboss.org/browse/WFLY-4617?page=com.atlassian.jira.plugin....
]
Srivathsan Agaram Venkatavaradhan commented on WFLY-4617:
---------------------------------------------------------
We are using CDI. We have made "require-bean-descriptor" as true , so only CDI
scans necessary bean archives. We are using infinispan as second level cache. Infact we
have 250 JPA entities stored in separate cache region in infinispan. We notice a lot of
background threads kept for each JPA in infinispan for cleaning up transactions. Yes the
entities are moved to old gen before the server is done with request. We want to know why
wildlfy is creating substantially more number of objects than Jboss 7.1.1 for every
request which is filling up young generation. I noticed there are large number of
interceptors in wildfly for every EJB invocation which might be creating more number of
objects. Is there a way to disable wildfly security interceptors for EJB calls. Any other
optimization possible ?
Huge garbage created at regular intervals in Wildfly 8.2.0.Final
----------------------------------------------------------------
Key: WFLY-4617
URL: https://issues.jboss.org/browse/WFLY-4617
Project: WildFly
Issue Type: Bug
Affects Versions: 8.2.0.Final
Environment: Centos 7, JDK 7
Reporter: Srivathsan Agaram Venkatavaradhan
Assignee: Stuart Douglas
Labels: 8.2.0.Final, gc, undertow, wildfly
Attachments: Char Array Incoming reference, Char Array Retained Objects, Heap
Histogram View, merge paths - ArtifactDetailList, newheap1_Leak_Suspects.zip, Overall
Heap, Overall Memory Usages
Huge garbage is created in wildfly every couple of minutes. Though Full GC is able to
reclaim memory, this causes frequent full gcs, as heap is getting occupied due to the
increase in number of objects created . We can reproduce this issue in 60 users Jmeter
loadtest. This was not the case in Jboss 7.1.1Final.
After analyzing heapdumps, Huge char arrays are created and they are not garbage
collected by Minor GC. Incoming reference for the char array suggest that they have valid
reference to io.undertow.servlet.spec.HttpServletRequestImpl. However full gc is able to
recover the memory. Not sure why attributes in
io.undertow.servlet.spec.HttpServletRequestImpl are not getting gced by minor gc's.
"org.apache.struts.tiles.ComponentContext" is kept in attributes Map by
io.undertow.servlet.spec.HttpServletRequestImpl. org.apache.struts.tiles.ComponentContext
contains a big char array.
We suspect issue with undertow.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)