| Author |
Message
|
| sravan |
 Posted: Mon Jun 25, 2012 3:16 pm Post subject: retry requests with time interval. |
 |
|
Centurion
Joined: 02 Apr 2010
Posts: 104
Location: Charlotte
|
I have the following design
MQ Request --> build a REST based request --> if sucessful response send a notification by email.
if unsucessful response call the REST webservice with a timedelay(upto few mints) until sucessful response upto 9 times.
I want to know the best approach to call the REST service with delay as holding the flow for few mints can cause issues with the EG.
_________________
skr_wmb |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jun 25, 2012 5:21 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 26, 2012 1:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It may not be obvious to most viewers, but lancelotlinks suggestions are all excellent suggestions, but should be viewed as "the hard way".
Except the bit about using a database. That's not a bad way, depending entirely on how the database schema is laid out.
Two common ways to do this in Broker use message expiry or use a TimeoutControl/TimeoutNotification node pair. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jun 26, 2012 2:15 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
Another way, if you know how to use the Java programming language (who doesn't?)
|
sigh.
Not every Broker developer knows or even wants to know Java.
There are some of us who'd clearly rather write JCL/Cobol or even Coral-66  than write Java code. Personally, I find it just a PITA to use. This is probably because I don't have to use it very often(about as often a Cobol these days) in order to get my job done. I know that I am not alone here.
Naturally, every site is different. Many of us know from you past posts that you seem to almost love and worship the Java subsystem. Not all of us are a fortunate as your esteemed self.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Jun 26, 2012 3:29 am Post subject: Re: retry requests with time interval. |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| sravan wrote: |
I want to know the best approach to call the REST service with delay as holding the flow for few mints can cause issues with the EG. |
I interpret this that your flow is getting a lot of calls that should be forwarded to the REST service. The issues with the EG are either memory getting low or the flow running out of instances.
The java alternatives suggested by lancelotlinc are all holding the flow, they are all more or less putting the thread into sleep while keeping all resources (parsers, memory etc). So obviously they are not going to relieve you from the EG issues. Besides, Message Broker is optimized to run short-lived, transactional microflows, so I would say that Thread.sleep() is seldom part of a Message Broker best practice solution.
TimeOutControl/TimeoutNotification pair would be a pure Message Broker solution.
But if you really have for example hundreds of requests coming in every minute, that migth accumulate a lot of delayed processing if the endoint stays down for a longer period. In that case I would start putting the messages onto a queue after the first unsuccessful response and use Timeout nodes to start a delayed process that would browse the first message, test the service and consume the whole queue when the endpoint has started to respond. To implement this kind of a flow is not a very basic task, and there are issues that I have not mentioned in this brief description. So let's hope you have a modest message rate so that you can manage with delayed processing with a simple TimeoutControl/TimeoutNotification pair.
corrected "memory getting flow" ---> "memory getting low"
Last edited by Esa on Tue Jun 26, 2012 4:59 am; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 26, 2012 4:38 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Also note that if you have message affinity, your best plan might be to stop the flow and page somebody to fix the problem... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 26, 2012 5:25 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| smdavies99 wrote: |
| lancelotlinc wrote: |
Another way, if you know how to use the Java programming language (who doesn't?) |
sigh. Not every Broker developer knows or even wants to know Java. There are some of us who'd clearly rather write JCL/Cobol or even Coral-66 |
As a matter of policy, I am technology agnostic. Whatever fits best is what I use. Seeing that the last public domain contribution for Coral-66 code was in 1969, and that many contributions for another unspecified language are on-going, I tend to choose the implementation that has the most on-going community support.
But we still like old dogs. They bark at strangers.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Last edited by lancelotlinc on Tue Jun 26, 2012 5:40 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 26, 2012 5:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are surely a number of interesting patterns and designs for solving this with .NET in Broker v8.
If you're using Broker v8. And on windows. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 26, 2012 5:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| But we still like old dogs. They still bark at strangers. |
And when the revolution comes, the young will be locked in a compound & made to write CORAL-66, COBOL-68 & FORTRAN on 80 column cards which will be processed by stream powered card readers.
We can get the steam by burning all the books on rapid application methodolgies, data warehousing & content driven formatting.
While we all bark at strangers.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sravan |
| Posted: Tue Jun 26, 2012 11:36 am Post subject: |
|
|
Centurion
Joined: 02 Apr 2010
Posts: 104
Location: Charlotte
|
Thanks for your suggestions.
_________________
skr_wmb |
|
| Back to top |
|
|
| sravan |
| Posted: Tue Jun 26, 2012 11:43 am Post subject: |
|
|
Centurion
Joined: 02 Apr 2010
Posts: 104
Location: Charlotte
|
Unsucessful response from the REST webservice provider does not mean the system is down,It may due to delayed processing of FAX servicing of requests which are independent of each other).
I am hoping to use the timeout control for delayed processing after selectively browsing from the queue when there is a unsucessful response.
But this does hold the flow.
_________________
skr_wmb |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Jun 26, 2012 11:24 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| sravan wrote: |
I am hoping to use the timeout control for delayed processing after selectively browsing from the queue when there is a unsucessful response.
But this does hold the flow. |
You are more than a bit unclear, but one could get the impression that you are using MQ for sending the REST messages and an MQGet node for browsing the responses?
If that is the case you could move to asynchronous model and put all requests in a queue after sending them (with expiration and MsgId copied from writtenDestination) and make another flow receive the responses. Then you could get the requests that match unsuccessful responses and feed them back to the request flow via timeout nodes. Provided the REST service follows basic MQ/JMS conventions and copies request MsgId to response correlId, for example. Something in your post makes me think that it may not be the case... Well, that can be made work even if you had to examine the contents of the messages while browsing, it's would just be slower.
That would not "hold the flow", which, I guess, is your expression for synchronous processing. |
|
| Back to top |
|
|
|
|
