| Author |
Message
|
| andy1989 |
 Posted: Thu Apr 04, 2013 4:39 am Post subject: Retry mechanism pattern for broken connection |
 |
|
Novice
Joined: 07 Jan 2013
Posts: 22
|
Hello,
My IBM WS MB: 7.0.0.2
What is the best way to implement retry mechanism for a broken connection in flow like below:
MQInput --> Compute --> SOAPRequest --> Output
By broken connection I mean anynetwork problem with accessing a SOAP service through SOAPRequest.
I know that I can configure MQ (BOTHRESH & BOQNAME parameters) but i cannot find in documentation what is a delay period between subsequent requests. ( in my testing looks for about 1 second )
Is that approach enough ( I found an article about generic retry mechanism
http://www.ibm.com/developerworks/websphere/library/techarticles/0601_cox/0601_cox.html
with additional timeout but maybe it is not required for a simple flow)
Best regards,
Andy |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Apr 04, 2013 4:43 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Your error handler can requeue the message and set the retry count accordingly. Where are your trace nodes? Have you attended the required training?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| andy1989 |
| Posted: Thu Apr 04, 2013 5:01 am Post subject: |
|
|
Novice
Joined: 07 Jan 2013
Posts: 22
|
Trace node is between Compute and SOAPRequest.
SOAPRequest node is connected to my web service through monitor proxy
Regarding training - could you recommend any?
I searched the examples in the documentation and I didn't find any similiar.
Also in documentation i found a description of MQInput node behaviour.
Andy |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Apr 04, 2013 5:04 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Apr 04, 2013 5:07 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| andy1989 wrote: |
| Trace node is between Compute and SOAPRequest |
I put separate Trace nodes between every major node in all my flows and separately on each terminal. So for example, between the MQInput [out] node & Compute, between the Compute & SoapRequest, between SoapRequest [out] and the Compute that decodes the result, and all the error/fault terminals. Make sure your Trace nodes point to unique files, not the same file.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| andy1989 |
| Posted: Thu Apr 04, 2013 5:10 am Post subject: |
|
|
Novice
Joined: 07 Jan 2013
Posts: 22
|
Thank you, i will forward it to my superior.
Going back to my question - my approach is wrong? why?
Andy |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Apr 04, 2013 5:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| andy1989 wrote: |
| Going back to my question - my approach is wrong? why? |
I didn't say 'wrong'. You could improve your approach by adding a Compute node after the SoapRequest so that you can test the reply from the downstream provider. You also need to add an error handler, usually off the Input node. Backout queues are nice to have. You also need a separate Trace node & separate Compute node off the Fault terminal of the SoapRequest.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| andy1989 |
| Posted: Thu Apr 04, 2013 5:25 am Post subject: |
|
|
Novice
Joined: 07 Jan 2013
Posts: 22
|
| Quote: |
| I didn't say 'wrong'. You could improve your approach by adding a Compute node after the SoapRequest so that you can test the reply from the downstream provider. You also need to add an error handler, usually off the Input node. Backout queues are nice to have. You also need a separate Trace node & separate Compute node off the Fault terminal of the SoapRequest. |
Ok, In my question I specially removed components that work fine for me ( in real system each 'fault' generates Idoc and it is send to a SAP system)
Also i don't wantt to lose the heart of the matter.
So at this moment positive tests, negative business test works OK , but there is time to solve network issues - how to provide retry mechanism and not overload network.
Andy |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Apr 04, 2013 5:29 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| andy1989 wrote: |
| how to provide retry mechanism and not overload network. |
From your error handler, backout the original message into the original input queue, incrementing the backout count. When backout count is greater than desired (five times for example), move the message to a backout queue.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 04, 2013 5:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| andy1989 wrote: |
| how to provide retry mechanism and not overload network. |
From your error handler, backout the original message into the original input queue, incrementing the backout count. When backout count is greater than desired (five times for example), move the message to a backout queue. |
Yes, by all means, hand-code the behavior already provided with the MQInput node.
Or, alternately, consider understanding the product function and how to cause the MQInput node to perform an automatic backout. |
|
| Back to top |
|
|
| andy1989 |
| Posted: Thu Apr 04, 2013 5:37 am Post subject: |
|
|
Novice
Joined: 07 Jan 2013
Posts: 22
|
| Do you know what is the default delay between subsequent attempts? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Apr 04, 2013 5:39 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| lancelotlinc wrote: |
| andy1989 wrote: |
| how to provide retry mechanism and not overload network. |
From your error handler, backout the original message into the original input queue, incrementing the backout count. When backout count is greater than desired (five times for example), move the message to a backout queue. |
Yes, by all means, hand-code the behavior already provided with the MQInput node.
Or, alternately, consider understanding the product function and how to cause the MQInput node to perform an automatic backout. |
I never said hand-code anything. 90 percent of the functionality described is already implemented, but if someone doesn't read the InfoCentre or attend the Training, it would be difficult to osmosize that concept.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 04, 2013 5:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Apr 04, 2013 5:40 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| andy1989 wrote: |
| Do you know what is the default delay between subsequent attempts? |
Try it and find out. Also experiment with how you would modify that value.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| andy1989 |
| Posted: Thu Apr 04, 2013 6:01 am Post subject: |
|
|
Novice
Joined: 07 Jan 2013
Posts: 22
|
| Quote: |
Try it and find out. Also experiment with how you would modify that value.
|
I've check it and for BOTHRESH=3 period is about 1 second:
| Code: |
Date: 2013-04-04 15:50:36.866836
Date: 2013-04-04 15:50:38.131391
Date: 2013-04-04 15:50:39.128313 |
|
|
| Back to top |
|
|
|
|
