As I commented on the "bug" report. This is not JMS, this is EJB3.
OFF TOPIC - use the ejb3 forum rather than respond to this post.
It isn't clear to me what you are doing, but it doesn't look like a bug to me.
It looks like you don't understand that ejbs are pooled and/or that multiple copies
of an entity bean can exist simultanously,
e.g. for optimisitic locking
To have singletons you need to use some form of pessimistic locking which is usually not
Apologies for posting on the wrong forum, but the issue seems to present itself only in MDBs, therefore my assumption that it was an MDB problem. I didn't write the code, so you might be right.
I think my understanding of pooling is pretty good, ergo the post and the "Bug" in the title. I'm pretty sure this is broken:
After making 351 requests, how many instances of RecordManagerBean do you think were created? The answer is, 351. postConstruct was called 351 times and preDestroy was called 0 times, so none of these instances were claimed back. Is there a fault in my understanding of how this should work?
What happened on the 352'nd request? Here:
Can't create thread: 5 13:34:45,519 ERROR [JmsServerSession] Unable to schedule work javax.resource.spi.work.WorkRejectedException: org.jboss.util.threadpool.ThreadPoolFullException: java.lang.OutOfMemoryError: unable to create new native thread at org.jboss.resource.work.WorkWrapper.rejected(WorkWrapper.java:250) ...
JBoss is started with -Xms128m -Xmx512m, so maybe these memory settings will make it easier to replicate the bug.
Here is also a script to call the calculator injection mdb 3 times every second:
URL="http://<YOURIP>:8080/EJB3Trail/serviceobjects/injection/calculator.jsp?action=send&start=25&end=65&growthrate=0.08&saving=300&submit=Calculate" out=/dev/null content=/dev/null i=0 while [ $i -ne 500 ]; do i=`echo "1 + $i" | bc -q` echo $i wget $URL --output-file $out --output-document $content wget $URL --output-file $out --output-document $content wget $URL --output-file $out --output-document $content sleep 1 done
Please be so kind to ponder on my comments and reconsider whether it still looks like I don't understand ejb's and pooling.
Also consider that jaikiran independently verified this with his own code.
Also consider the fact that this behaviour does not occur if we do not use MDB, i.e. just by using stateless beans.