We suspect that our stateless EJBs are leaking.
Attaching jmx-console stats and path to GC for one of the leaking beans from a test system that has been running on small load for 12 hours.
Name | Type | Access | Value | Description |
---|---|---|---|---|
Name | java.lang.String | R | StatelessDelegateWrapper | MBean Attribute. |
StateString | java.lang.String | R | Started | MBean Attribute. |
CreateCount | int | R | 116902 | MBean Attribute. |
State | int | R | 3 | MBean Attribute. |
InvokeStats | org.jboss.ejb3.statistics.InvocationStatistics | R | MBean Attribute. | |
CurrentSize | int | R | 116898 | MBean Attribute. |
RemoveCount | int | R | 4 | MBean Attribute. |
MaxSize | int | R | 30 | MBean Attribute. |
AvailableCount | int | R | 29 | MBean Attribute |
If I annotate a leaking bean to use another pooling class (as suggested by http://community.jboss.org/thread/110175) the leak seems to go away.
@PoolClass(value=org.jboss.ejb3.StrictMaxPool.class)
So my guess is that the default ThreadLocalPool retains the EJB instances and the mechanism for removing old ones is somehow misconfigured?
Should I make all our beans to use StrictMaxPool instead?