I am sorry. In 3. I mean to say- " So old stateless beans are NOT garbaged as ThreadGroup is not garbaged. "
Also I found another scenario,
JBoss ServerThread class is also holding all ThreadLocal instances.
Is this a known bug?
JBoss doesn't invoke garbage collection, this is the job of the VM.
Stateless beans instances are pooled in a threadlocal variable stored in the EJBContainer. The EJBContainer should be undeployed and thus garbage collected and thus the ThreadLocal should be garbage collected as well. Are you seeing EJBContainer instances leaked?
Can you narrow this down to a really small reproducable test case?
I did force n number of times manual garbage collection while taking memory snapshot.But no luck. I am sure that those instances get never released.
From your input, I tried to look at EJB3/EJB instances leakage. Thanks god they are not leaked. It seems there is something to do with ThreadLocal or ServerThread instance.
Just as a quick test, I opened some file handles within POJO singleton class implementation,which internally used by one of my ejb3 slsb. In finalize() of singleton class I close these filehandles.
I tried redeploying my app n number of times,singleton instance is created n times(ofcourse) , but as no singleton is garbaged, all file handles are still kept opened (Used a ProcessExplorer tool in windows) ofcourse which leads to memory leak.
I will try providing you a testcase.
Till that time, here is referrer details:
StatelessBeanContext 1480412 (bean)
ThreadLocal$ThreadLocalMap$Entry 1482804 (value)
ThreadLocal$ThreadLocalMap$Entry  1293433 ()
ThreadLocal$ThreadLocalMap 1281230 (table)
ServerThread 741958 (threadLocals)
LinkedList$Entry 819620 (element)
WeakHashMap$Entry 777095 (referent)
Thread  775226 ()
Java Frame 1152921504606846993
Java Frame 1152921504606846990
Java Frame 1152921504606846989
Any updates on this issue? We are using EJB3 with Lazy fetch and we have noticed memory leaks even when JBoss is restarted.