[jboss-user] [EJB/JBoss] - Re: MDB calling a session bean, session bean not getting reu

[ryanrlamothe]

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=bb&op=viewtopic&t=132763
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=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=10000)

to

@org.jboss.annotation.ejb.PoolClass (value=org.jboss.ejb3.StrictMaxPool.class, maxSize=30, timeout=10000)

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=bb&op=viewtopic&p=4212417#4212417

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4212417