| Author |
Message
|
| angka |
 Posted: Mon Mar 02, 2009 4:41 am Post subject: Compute Node accessing DB retry |
 |
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
What will happen if the Database is down when the compute node tries to access it and no exception handling is done? will the message just drop to the dead letter queue? can it be set to retry with configuration? Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Mar 02, 2009 4:50 am Post subject: Re: Compute Node accessing DB retry |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| angka wrote: |
| What will happen if the Database is down when the compute node tries to access it and no exception handling is done? will the message just drop to the dead letter queue? |
It's the same as any unhandled exception in a Compute node - the message will roll back through the flow until it finds a connected failure terminal or the original input queue. At this point it will retry or backout as you've determined, possibly becoming a poison message in the process.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| angka |
| Posted: Mon Mar 02, 2009 4:57 am Post subject: |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
it will roll back to the input node and retry. this is my understanding too but a message drop to Dead letter queue when my server (running on MS clustering) failover. the database and broker is on different resource. why is this so?
Thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 02, 2009 5:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| angka wrote: |
| a message drop to Dead letter queue |
What's the reason code in the message?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| angka |
| Posted: Mon Mar 02, 2009 5:22 am Post subject: |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
i dun ve the error currently..it is those default application error... |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 02, 2009 6:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Is there a backout queue specified on the input queue?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| angka |
| Posted: Mon Mar 02, 2009 6:09 am Post subject: |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 02, 2009 6:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MQEnthu |
| Posted: Mon Mar 02, 2009 6:26 am Post subject: |
|
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
What is the reason code? You can find the details on deadletter header.. please check the reason and the original queue to which message was supposed to deliver..
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 02, 2009 6:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| If a persistent message is backed all the way out to the failure terminal of an MQ Input node, and there is no backout retry queue configured on the queue that MQInput is reading from, the message will be put on the DLQ with a Reason Code in the DLH that is one of the "user defined" DLQ reason codes, not one of the WMQ defined reason codes. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 02, 2009 6:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQEnthu wrote: |
| What is the reason code? You can find the details on deadletter header.. please check the reason |
The poster had already said it was the default WMB error.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| angka |
| Posted: Tue Jul 14, 2009 12:05 am Post subject: |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
So there is no way to configure the compute node to retry accessing the database until it is up?? How many times the compute node will try to connect to the Data source before it fails?
Due to message affinity, the message must be process in sequence.
Thanks.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 14, 2009 1:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| angka wrote: |
| So there is no way to configure the compute node to retry accessing the database until it is up?? |
| angka wrote: |
| How many times the compute node will try to connect to the Data source before it fails? |
Once.
| angka wrote: |
| Due to message affinity, the message must be process in sequence. |
Another reason why message affinity is such a bad idea.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| angka |
| Posted: Tue Jul 14, 2009 1:45 am Post subject: |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
So if my server failover(MS clustering) and the Broker resource get online faster thAn the database resource (which are in different resource group), the message will be drop into SYSTEM.DEAD.LETTER.QUEUE if no failure node is created in any part of the flow? |
|
| Back to top |
|
|
| jbanoop |
| Posted: Tue Jul 14, 2009 4:57 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Your recovery script / Failover should always bring up the dependant resources before bringing up the MQ and MB components.
There should be proper error handling procedures defined to handle your specific case.
It is always advisable to have a backout queue so that the failed messages go to that queue instead of a generic dead letter queue.
You can set the backout threshold to make the flow retry the message a fixed number of times. In fact if required the backout count can be inspected within your error handling framework and appropriate actions taken depending on the number of retries that have already been completed.
There are a number of ways to achieve your objective within code/error handling frameworks but as I mentioned, your recovery process should factor in these conditions. This would be the right approach |
|
| Back to top |
|
|
|
|
