> I have written a generic MDB. When it recieves
> a message (an object message), it looks up in an
> XML file the "activities" that it needs to
> execute based on a parameter that gets passed in the
> If an activity fails, then the
> MDB fails and the message gets requeued.
> This basically puts the app server into an infinite
> loop. Are there parameters that allow how soon
> a message gets requeued or how many times it will be
No there is not. Up to 2.4.1 you will fall into an endless loop if you do not handle your messages.
In 3.0 there is a Dead Letter Queue where messages recent a certain amount of times wil be sent to.
> Is anyone else doing this sort of thing. i'm
> interested in how to best handle
> exception handling within the MDB. If there are 8
> activities for a given message, how best do i handle
> making sure each one gets executed eventually or even
> better yet, that no activity gets executed twice.
> ... that sort of thing :)
what do you mean by handling messages? If one has a try/catch block in the onMessage() method and an exception is thrown, does this mean the transaction is rolled back or that some how the message is requeued?
If this is indeed the case, would you recommend BMP so that the MDB could commit the transaction regardless? Thanks for your insight in the matter.
> what do you mean by handling messages? If one has
> as a try/catch block in the onMessage() method and an
> exception is thrown, does this mean the transaction
> is rolled back or that some how the message is
If there is a EJBException thrown in onMessage, if you invoke setRollbackOnly or if any bean that is called from the MDB in any way has inherited the transaction (not of type NotSupported, RequiresNew and the like) causes a transaction rollback, then the message receipt will not be acked. The message will then (up to but not including JBoss 3.0) will be resent for ever until the bean finally handles the message or JBoss crash.
> If this is indeed the case, would you recommend
> nd BMP so that the MDB could commit the transaction
Yes, if the failing happend in another bean where transaction is autmatically rolled back. A guess another way of doing it is to require the called bean to start their own transactions.
Hope this helps.
> Thanks for your insight in the matter.