UnifiedClassLoader3 or RepositoryClassLoader's resourceBlackList causing memory leaks in JBoss

Solution Verified - Updated 7 Aug 2024

Environment

JBoss Enterprise Application Platform (EAP) 4.3.x
JBoss Enterprise Application Platform (EAP) 5.x

Issue

Memory leak using JBossWS. Heap analysis showing that the resourceblackList from UnifiedClassLoader3 or RepositoryClassLoader is holding hashmap references. Sample hashmap entry:
```
  key  java.lang.String "JBossWS_deltacast.tv_asisws_5535759035290179420.xsd"
```

value char[103] "file:/C:/Java/jboss-4.3.0/server/MARCuS/tmp/jbossws/JBossWS_deltacast.tv_asisws_5535759035290179420.xsd"

Resolution

Starting with EAP 4.3 CP07, there is the ability to limit the growth of the blacklist by adding the following system property:
```
  -Dorg.jboss.mx.loading.blacklistMode=LRUSet
```
There is also the ability to set a custom limit for each repository with the following system property:
```
  -Dorg.jboss.mx.loading.blacklistMax=X
```
where X is an integer (the default maximum is 1000)
On EAP 5, you can change the blacklist to use soft references:
```
  -Dorg.jboss.mx.loading.blacklistMode=SoftSet
```
The cache would then only have soft references to its entries, meaning the JVM can GC them at any time it needs to reclaim that heap space, ensuring they'd always be freed before an OOME would occur.
A workaround would be to change the application code to cache the Service.

Root Cause

SBR

Product(s)

Red Hat JBoss Enterprise Application Platform

Components

jbossas

Category

Troubleshoot

Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.