On 14/12/2011 14:35, Gustavo Henrique Orair wrote:
> Hi Nigel,
> Could you please explain better the delay behavior and how to change it?
If a MDB throws an exception then Glassfish (actually the resource adapter) will sleep for
endpointExceptionRedeliveryInterval and then invoke the MDB again with the same message. This will repeat for
EndpointExceptionRedeliveryAttempts times.
If, after calling onMessage() endpointExceptionRedeliveryAttempts times the MDB still throws an exception, then what
happens next is determined by the sendUndeliverableMsgsToDMQ property.
If sendUndeliverableMsgsToDMQ is set to true the message is then sent to the dead message queue. If
sendUndeliverableMsgsToDMQ is not set the message is returned to the broker and it will be redelivered, causing the
whole process to repeat.
The above properties are all activation spec properties. The first post in this thread demonstrates how to configure them.
> "/(Remember you've got a pool of MDBs, so if the MDB starts throwing
> exceptions you'll see a sudden burst of, say, 32 exceptions, then a pause of
> 18 seconds, when another burst of 32 exceptions, and so on.)/"
>
> In my case, I have a MDB that may receive many messages in a minute. These messages (the TO inside the message) may
> already have been received previously. In this case, the MDB invokes a stateless session bean that will throw a
> BOAlreadyExists exception. Inside MDB, I get the BOAlreadyExists exception and just log this event.
> I have some problems because the pool seems "stop working" after a predefined number of these exceptions.
If the MDB's onMessage() isn't throwing an exception, but logs a message and returns, then none of the above applies.
Something else is going on.
Nigel