The setup:
queue/A -> QueueA_MDB -> CMT SSB Business Logic
|
| 3 retries, go to FlowErrorDLQ
\ /
*
queue/FlowErrorDLQ -> FlowErrorDLQ_MDB -> CMT SSB Failure Logic
|
| 3 retries, go to DLQ
\ /
*
queue/DLQ
- QueueA_MDB is configured with it's own invoker-proxy-binding that has ..
<MDBConfig>
<ReconnectIntervalSec>10</ReconnectIntervalSec>
<DLQConfig>
<DestinationQueue>queue/FlowErrorDLQ</DestinationQueue>
<MaxTimesRedelivered>3</MaxTimesRedelivered>
<TimeToLive>0</TimeToLive>
</DLQConfig>
</MDBConfig>
... After 3 failed retries, the message should be pushed by the DLQHandler
to queue/FlowErrorDLQ.
- FlowErrorDLQ_MDB uses the standard invoker-proxy-binding
"message-driven-bean". After 3 failed retries, the message should be pushed
by the DLQHandler to queue/DLQ.
- queue/DLQ has NO MDB or MessageListener attached.
The scenario:
My test was to force both the MDBs to rollback the CMT in the onMessage() in
order to test if the message ultimately arrives on the queue/DLQ in the
event of catastrophic failure of both the business logic, and the failure
handling logic layers.
The test flow I expected to occur is as follows:
1. Message arrives on queue/A
2. QueueA_MDB->onMessage() fires
3. QueueA_MDB->log a message
4. QueueA_MDB->ctx.setRollbackOnly()
5. retry steps 2-4 3 times.
6. DLQHandler pushes message to queue/FlowErrorDLQ
7. Message arrives on queue/FlowErrorDLQ
8. FlowErrorDLQ_MDB->onMessage() fires
9. FlowErrorDLQ_MDB->log a message
10. FlowErrorDLQ_MDB->ctx.setRollbackOnly()
11. retry steps 8-10 3 times.
12. DLQHandler pushes message to queue/DLQ
The flow up to step 7 works as expected. However, what happens after step 7
is as follows:
8. Error occurs prior to FlowErrorDLQ_MDB->onMessage() being invoked (no
stack trace though)
9. DLQHandler trace logging shows an internal retry of 3 times
10. DLQHandler pushes message to queue/DLQ
Here's the strange part. If I configure the retry count of the
FlowErrorDLQ_MDB to be 6 instead of 3 the following flow occurs:
8. Error occurs prior to FlowErrorDLQ_MDB->onMessage() being invoked (no
stack trace though)
9. DLQHandler trace logging shows an internal retry of 3 times
10. On retry attempt 4, FlowErrorDLQ_MDB->onMessage() fires
11. FlowErrorDLQ_MDB->log a message
12. FlowErrorDLQ_MDB->ctx.setRollbackOnly()
13. retry (10-12) ** 3 ** times (ie the 4 - 6 retries out of 6)
14. DLQHandler pushes message to queue/DLQ
If I set the FlowErrorDLQ_DMB to retry 10 times, the same behaviour occurs
with the exception that step 13 invokes the FlowErrorDLQ_MDB->onMessage() 7
times.
Any ideas on what could be going wrong with the MDB retry mechanism when
using multiple MDBs and DLQ destinations?
Dustin
-------------------------------------------------------
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
