I wanted to post some follow-up information, in case anyone had any additional
thoughts. This appears to be a bug in multiple versions of JBoss AS, including
apparently 5.0, where any time a stateless session bean is injected into an MDB
a new instance of that stateless session bean is created, but never removed
from the thread pool. Therefore, if an MDB makes 500 calls to a SLSB, the
container will end up with 500 instances of that SLSB which never get removed.
This could potentially be the source of a major memory leak.
So, after some digging, the following information pointed to the ability to
force the SLSB's into a pool of a specific maximum size:
http://www.jboss.org/jbossejb3/docs/reference/build/reference/en/html/session-bean-config.html
Which worked, for the specific SLSB which you annotated to use that pool, but
unfortunately each subsequent SLSB that was called from that initial SLSB would
still display the original behavior. Now, adding that annotation to every
single bean individually down the stack did not seem like a great idea either,
although it could be done if required. But the idea of controlling the pool
was interesting, which lead me to research this more, and I came up with the
following information:
https://jira.jboss.org/jira/browse/JBAS-5345 (BUG Report!)
http://www.jboss.org/index.html?module=bbop=viewtopict=132763
http://www.jboss.org/index.html?module=bbop=viewtopict=132331
Long story short:
- EJB3 annotations are intercepted using JBoss AOP and are configured in
default/deploy/ejb3-aop-interceptors.xml. So, instead of annotating each
SLSB individually, we can provide a blanket solution at this point to all
SLSB's.
- ThreadlocalPool isn't very strict, apparently, but StrictMaxPool appears to
give us the behavior we want
- As noted by wolfc in the first forum thread...It would appear that JBossMQ
does not use a ThreadPool, but instantiates threads on the fly. Thus the
ThreadlocalPool will keep on creating instances to match. That makes the use
of StrictMaxPool mandatory. Which is the behavior we are seeing.
To put all of this to the test, all of the Stateless Bean domain annotation
expressions in ejb3-aop-interceptors.xml where changed from:
@org.jboss.annotation.ejb.PoolClass
(value=org.jboss.ejb3.ThreadlocalPool.class, maxSize=30, timeout=1)
to
@org.jboss.annotation.ejb.PoolClass (value=org.jboss.ejb3.StrictMaxPool.class,
maxSize=30, timeout=1)
Note: The MDB domain annotation expressions use StrictMaxPool by default!
This appears to solve the problem, but will require more monitoring in the
coming weeks. Any other thoughts on this issue? Concerns about contention in
the StrictMaxPool? Thoughts on another, better solution?
Thanks!
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4212417#4212417
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4212417
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user