-
1. Re: MDB Fails to retrieve messages from Topic after bombardm
pallidan Feb 9, 2006 3:26 PM (in response to pallidan)I should mention that if this is a known bug that has been fixed, I may be able to make a case to upgrade to a newer version of jboss.
Thanks. -
2. Re: MDB Fails to retrieve messages from Topic after bombardm
genman Feb 9, 2006 5:56 PM (in response to pallidan)
Hmm, I would at least try to switch to 3.2.7. There's been many fixed bugs. -
3. Re: MDB Fails to retrieve messages from Topic after bombardm
adrian.brock Feb 10, 2006 6:01 AM (in response to pallidan)And this is a bug in oswego-concurrent anyway :-)
-
4. Re: MDB Fails to retrieve messages from Topic after bombardm
thoennes Feb 10, 2006 6:53 AM (in response to pallidan)In this JBoss version, oswego-concurrent thread pools are used to process the messages. Every message picked up is handed over to the thread pool for processing.
If the thread pool is set to 1 (using maximumSize), the MDB acts as a singleton.
If some reasons a thread from the thread pools exits (due to an exception etc), in some cases no thread is re-created by the thread pool. So you have some sort of thread leakage. Restarting the MDB probably re-creates the thread pool completely.
We also use singleton MDBs and had a similiar looking case a while ago. From the java thread dump we could see that the blocking MDB was waiting on its thread pool for a thread to process the message. But the pool was empty, so the MDB waited forever.
Dough Lea, the creator of the oswego-concurrent package, said the reason was an unsupported way how JBoss used the thread pool settings, but Adrian regarded it as a bug in the lib.
Anyway, Dough added a change to support the JBoss usage and now it works.
Just have a look at the thread dump and upgrade the version of the concurrent library you are using. The latest version you can find here:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
Replace the version used by JBoss and try again.
Upgrading to the newest JBoss in the 3.2 branch is a good idea anyway, besides of pulling in the newest concurrent lib it would also fix a couple of other issues with JMS.
HTH. Jörg -
5. Re: MDB Fails to retrieve messages from Topic after bombardm
pallidan Feb 10, 2006 3:32 PM (in response to pallidan)Thanks for your help. I tried the new concurrent.jar that came with jboss 3.2.8, but it didn't fix the problem. In fact, whiel the problem still occured, the event handling seemed to be out of order.
I'll have to try switching completely to 3.2.8 when I have the chance. When I get around to it, I'll post my results!
Thanks a lot! -
6. Re: MDB Fails to retrieve messages from Topic after bombardm
adrian.brock Feb 12, 2006 9:11 AM (in response to pallidan)"Thoennes" wrote:
Dough Lea, the creator of the oswego-concurrent package, said the reason was an unsupported way how JBoss used the thread pool settings, but Adrian regarded it as a bug in the lib.
It is a bug. Just because Doug no longer supports it, doesn't stop it being a bug. ;-)
It is still a bug as well in the latest oswego concurrent, we just have a workaround
that avoids the problem (we don't let the threadpool go empty through idle removal).
The problem comes because you have something like:
Scheduling thread: Are there any unused threads? Yes
Idle Remover: Remove all the unused threads (they just timed out)
Scheduling thread: Add the work for the now non-existant threads to pickup
Result: Work is never performed
It is a simple race condition. The check for unused threads and the addition of work
are not synchronized (atomic).
It is also NOT easy to fix because of the design of the code. Which is why Doug
does not support it.
The handling of idle threads in general is pretty poor in concurrent's executor. It is very
difficult to achieve a controlled shutdown that doesn't leaving hanging/orphaned
threads lying around. Again NOT easy to fix. -
7. Re: MDB Fails to retrieve messages from Topic after bombardm
adrian.brock Feb 12, 2006 9:22 AM (in response to pallidan)"adrian@jboss.org" wrote:
It is very
difficult to achieve a controlled shutdown that doesn't leaving hanging/orphaned
threads lying around.
To be later removed when they pass the idle timeout ("long after" the thread pool is dead).