HornetQ memory leak using jBPM Human Task component in BRMS 5.3.1
Issue
We are running load tests with the jBPM Human Task component. We have already applied the one-off patch mentioned in https://access.redhat.com/site/solutions/772333, which has fixed the big ramp in memory comsumption. But there is still something HornetQ related being accumulated in within a day of intermediate load (running the test with 300 parallel threads).
Looking at the heap dump with MemoryAnalyzer showed the following leak suspects:
1) One instance of "org.hornetq.core.client.impl.ClientSessionImpl" loaded
by "org.jboss.classloader.spi.base.BaseClassLoader @ 0x788eb4ad8"
occupies 346,468,576 (28.80%) bytes. The memory is accumulated in one
instance of "java.util.concurrent.ConcurrentHashMap$Segment[]" loaded
by "<system class loader>".
2) One instance of "org.jbpm.task.service.hornetq.HornetQTaskClientHandler"
loaded by "org.jboss.classloader.spi.base.BaseClassLoader @ 0x788eb4ad8"
occupies 209,507,600 (17.41%) bytes. The memory is accumulated in one
instance of "java.util.HashMap$Entry[]" loaded by
"<system class loader>".
Environment
- Red Hat JBoss BRMS
- 5.3.1
- Roll-Up patch #4 applied
- One-off patch https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=29153&product=brms&version=5.3.1&downloadType=patches applied
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.