| Author |
Message
|
| WMB_DEV |
 Posted: Mon Jun 28, 2010 6:32 am Post subject: Urgent**Replay Failed messages: MqInput-browse only-> MqG |
 |
|
Novice
Joined: 23 Mar 2010
Posts: 10
|
Im doing following in my message flow.
1. MQ input node in the browse only mode
2. checking for a condition in the compute node.
3. returning false in the compute node if the check condition fails else returning true.
4. if condition fails the message is not taken out of the queue and available in the input queue.
5. if condition succeeds, the message is taken out using MQGet node with get by message id box checked.
6. the failed messages at MQ input node are not getting reprocessed untill message flow is restarted.
7. This is happening in case of erroneous messages also.
8. when trying to resubmit the message, its not getting reprocessed until the message flow is restarted.
Please suggest, how to process the failed or erroneous messages without restarting the message flow. |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Jun 28, 2010 6:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Reset the browse cursor.
This does seem a strange design, I have to say.
I have seen something similar before and it became exponentially inefficient when there were a large number of "pending" messages at the start of the queue which were constantly being retried before it could get as far as a message which actually was processsed.
It may be better to remove each message normally and put it back on the same queue if it needs to be reprocessed.
That way it will be at the back of the queue and not delay processing of other messages. Therefore the expoential delays will not occur.
Generally browsing should not be used in applications, with the possible exception of getting reference data held on a queue. |
|
| Back to top |
|
|
| WMB_DEV |
| Posted: Mon Jun 28, 2010 6:52 am Post subject: |
|
|
Novice
Joined: 23 Mar 2010
Posts: 10
|
Thanks for the reply. But my question is even if the messages are taken off the queue using MqGet why I am not able to process the messages until I restart the message flow. Does it have to do something with messageID or correlation ID..would appreciate some response on this part..
| zpat wrote: |
Reset the browse cursor.
This does seem a strange design, I have to say.
I have seen something similar before and it became exponentially inefficient when there were a large number of "pending" messages at the start of the queue which were constantly being retried before it could get as far as a message which actually was processsed.
It may be better to remove each message normally and put it back on the same queue if it needs to be reprocessed.
That way it will be at the back of the queue and not delay processing of other messages. Therefore the expoential delays will not occur.
Generally browsing should not be used in applications, with the possible exception of getting reference data held on a queue. |
|
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jun 28, 2010 7:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You said the failed messages remain on the input queue.
You need to understand what a browse cursor is. or better still re-design it so it does not use browse.
I repeat - get browsing is almost always a bad application design.
How can this be urgent - are you saying that you did not test this in development? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 28, 2010 8:28 am Post subject: Re: Urgent**Replay Failed messages: MqInput-browse only-> |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMB_DEV wrote: |
| Please suggest, how to process the failed or erroneous messages without restarting the message flow. |
Redesign your flow to use rollback and check backout count.
What you're currently doing is very odd & inefficient. And seems to be confusing the browse cursor.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jun 28, 2010 9:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Rollback would process the same message again immediately. This would then be a backout retry loop until the backout requeue threshold is reached.
I think he wants to retry them, but also carry on processing other messages until it works, in which case puting them to the same queue as used for input will achieve that.
It depends what changes to make the failed message become successful. I assume it is more than simply trying again immediately. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 28, 2010 9:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Rollback would process the same message again immediately. This would then be a backout retry loop until the backout requeue threshold is reached. |
Not if the threshold is 1.
| zpat wrote: |
| I think he wants to retry them, but also carry on processing other messages until it works, in which case puting them to the same queue as used for input will achieve that. |
So have a timed flow which moves the messages out of the backout queue back into the input queue after n time periods have elapsed.
| zpat wrote: |
| It depends what changes to make the failed message become successful. I assume it is more than simply trying again immediately. |
Maybe. Or maybe patience is it's own reward in this design.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
