| Author |
Message
|
| mbwannabe1 |
 Posted: Fri Aug 17, 2012 1:53 pm Post subject: message flow in continous loop |
 |
|
Novice
Joined: 18 Apr 2012
Posts: 13
|
Hi,
We have a situation where, under certain conditions an input message is put back to the input queue pending correction of the error condition. is there any hazard from this kind of an endless loop - such as resource utilization.. this is likely very similar to a message backing out endlessly. any ideas what kind of issues this might lead to?
Thx |
|
| Back to top |
|
 |
| McueMart |
| Posted: Fri Aug 17, 2012 1:59 pm Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
If you are simply 'putting' a message back onto the input queue continuously then of course this will result in an endless loop (and the resultant high resource utilisation).
If a message is being 'backed out' to its input queue, then the MQInput node will use the Backout threshold and Backout count values to decide whether to process the message normally, or to stick it onto the Backout queue (or DLQ..).
I think your question needs further clarification in order for us to be of more help. |
|
| Back to top |
|
|
| mbwannabe1 |
| Posted: Fri Aug 17, 2012 2:09 pm Post subject: |
|
|
Novice
Joined: 18 Apr 2012
Posts: 13
|
| it is simply being put back to the input queue qhile an error condition exists to automate reprocessing, but what kind of high resource utilization would this result in? that is the question. shouldnt the threads etc.. be released after the message is put back? |
|
| Back to top |
|
|
| McueMart |
| Posted: Fri Aug 17, 2012 2:18 pm Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
The result will be that the message will be repeatedly processed by the flow. I would expect this will result in potentially high amount of CPU utilisation and IO (The extent of how much utilisation would depend on many factors).
To answer your questions about 'shouldn't the thread be released..' - If you have 1 instance of the flow running, you only have 1 thread ever running. So saying it is 'released' isnt the correct term. What will happen is that this one thread will continuosuly be picking up the message, processing it, putting it back onto the input queue.... then repeating. |
|
| Back to top |
|
|
| NealM |
| Posted: Fri Aug 17, 2012 2:23 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Is the flow somehow correcting the error situation such that when it message is put back on the input Q it will work immediately? If not the flow is unnecessarily wasting cycles. Most flows would put the message in error to a failure/hold queue, and have a switch that would trigger another retry flow to grab the message and put it back on the original queue when the situation is fixed. The switch could be via the Timeout nodes, which would retry every n minutes say. And if you didn't want it to be an endless retry, you could maybe involve a retry counter in an RFH2 header. We do that all the time for situations where a database or email server may be temporarily down but is usually back up within a few hours at most. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 17, 2012 2:37 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So, again, a bit of clarification.
Is the message being put using an MQOutput, or is it being rolled back by the MQinput?
If it is being rolled back, then not only are you running a risk of high cpu/memory utilization, you have created what is known as a poison message that will prevent all other messages on the queue from being processed until the 'bad' one is working. |
|
| Back to top |
|
|
| McueMart |
| Posted: Fri Aug 17, 2012 2:43 pm Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| If it is being rolled back, then not only are you running a risk of high cpu/memory utilization |
Interestingly, if a message is rolled back, the thread processing the message will sleep for 1 second (Which was presumably to prevent poison messages causing a hard loop), so you are unlikely to actually see high cpu in this situation, but poison messages are obviously pretty bad... |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Aug 20, 2012 5:23 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Why not fix the root cause: logic that is incomplete?
Are you not permitted to use backout queues?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
