Author |
Message
|
ydsk |
Posted: Fri Feb 06, 2009 1:14 pm Post subject: how to wait for a specified time b4 resuming processing |
|
|
Chevalier
Joined: 23 May 2005 Posts: 410
|
Hi,
I am calling a webservice from within a msgflow using HTTPRequest node. If the webservice is down for some reason I want to retry calling it after say 5 minutes ( a specific time interval).
How do I achieve the delay / wait of 5 minutes ?
Can the timer nodes help ? Can someone pls explain a bit.
Thanks in advance.
ydsk. |
|
Back to top |
|
 |
gregop |
Posted: Mon Feb 09, 2009 12:54 am Post subject: |
|
|
Voyager
Joined: 24 Nov 2006 Posts: 81
|
|
Back to top |
|
 |
MQEnthu |
Posted: Mon Feb 09, 2009 1:40 am Post subject: |
|
|
 Partisan
Joined: 06 Oct 2008 Posts: 329 Location: India
|
Yes, you can build a flow using the timer nodes for retry mechanism. Such that your flow can keep retrying after a fixed interval for a specific time. (say after every 5 min for half an hour). You can also do this using the compute nodes (ESQL/Java code). _________________ -----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
Back to top |
|
 |
zpat |
Posted: Mon Feb 09, 2009 2:02 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
What happens if the broker is shutdown or the message flow stopped while you are in this retry loop?
What happens if the web service is down for a long period (e.g. server maintenance)?
Message flows should be as near stateless as possible. Handle errors by routing messages to error queues for intervention and re-processing.
WMB is not WAS, it is not meant for general purpose long-running execution programming techniques. |
|
Back to top |
|
 |
harish_td |
Posted: Mon Feb 09, 2009 2:42 am Post subject: |
|
|
Master
Joined: 13 Feb 2006 Posts: 236
|
Please also go through the
Quote: |
Performance considerations for timeout flows |
topic before you choose this approach. |
|
Back to top |
|
 |
ydsk |
Posted: Tue Feb 10, 2009 12:02 pm Post subject: |
|
|
Chevalier
Joined: 23 May 2005 Posts: 410
|
MQEnthu,
How do we do this using just compute nodes (ESQL), without using the timer nodes ?
Can you provide some sample code ?
Thanks.
ydsk. |
|
Back to top |
|
 |
AkankshA |
Posted: Tue Feb 10, 2009 8:18 pm Post subject: |
|
|
 Grand Master
Joined: 12 Jan 2006 Posts: 1494 Location: Singapore
|
ydsk wrote: |
MQEnthu,
How do we do this using just compute nodes (ESQL), without using the timer nodes ?
Can you provide some sample code ?
Thanks.
ydsk. |
why this constraint... timer nodes are for free.. believe me..
and the TimeOutRequest is created in eSQL only... _________________ Cheers |
|
Back to top |
|
 |
MQEnthu |
Posted: Tue Feb 10, 2009 8:35 pm Post subject: |
|
|
 Partisan
Joined: 06 Oct 2008 Posts: 329 Location: India
|
Yes, as AkankshA mentioned it is better to use timer nodes when they are available for free... it becomes complex to acheive that using ESQL... you may have to loop in ESQL untail the desired interval is lapsed as I know there is no function like wait or sleep in ESQL.. _________________ -----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Feb 11, 2009 12:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
MQEnthu wrote: |
you may have to loop in ESQL untail the desired interval is lapsed as I know there is no function like wait or sleep in ESQL.. |
And if you do this, you will horribly misuse CPU and memory and your broker administrator will give you a trout. DO NOT DO THIS. |
|
Back to top |
|
 |
ydsk |
Posted: Wed Feb 11, 2009 8:53 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005 Posts: 410
|
i think every one knows looping is a bad way of waiting.
i thought MQEnthu had a good trick or two to achieve waiting in esql.
thnx
ydsk. |
|
Back to top |
|
 |
smdavies99 |
Posted: Wed Feb 11, 2009 8:59 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
There is a way to pause for a specified period and not in a loop or using Timeout Nodes.
You could use an MQGet Node on a queue that you know is going to be empty and set the timout on that to your desired wait time. Then wire up the No Message terminal and you should be all set.
It is crude but it should work. _________________ 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 |
|
 |
ydsk |
Posted: Sun Feb 15, 2009 7:58 pm Post subject: |
|
|
Chevalier
Joined: 23 May 2005 Posts: 410
|
The MQGet node trick seems to be good. But the team lead here didn't approve of it as it didn't sound "straight" to him. He wants a different solution to retry calling a webservice if it's down. The source of the msgflow is an MQInput node.
I read the timer nodes but it says TimeoutNotification node should be the first node in the flow, and it triggers the msgflow every x seconds.
We need the msgflow to run every time there is a msg in the MQInput node and use it to call an external webservice, and if the service is down we need to retry calling the webservice every X seconds for Y no. of times and then quit.
Can someone pls post some ideas on how to achieve it using Timer Nodes or otherwise ?
thanks.
ydsk. |
|
Back to top |
|
 |
rekarm01 |
Posted: Mon Feb 16, 2009 5:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
ydsk wrote: |
We need the msgflow to run every time there is a msg in the MQInput node and use it to call an external webservice, and if the service is down we need to retry calling the webservice every X seconds for Y no. of times and then quit.
Can someone pls post some ideas on how to achieve it using Timer Nodes or otherwise? |
One approach using the Timer nodes is to:- set up the message flow to route the message through a TimeoutControl node to an MQOutput "holding" queue, when the web service is unavailable. A separate message flow has a TimeoutNotification node controlled by the TimeoutControl node; after X seconds, it uses the MQGet node to get the message off the "holding" queue, and put it back on the input queue. Either message flow might also create a user-defined header field within the message to keep track of the number of retries.
There are a few other approaches that might work, without using Timer nodes:
- Route messages to a "holding" queue, when the web service is unavailable. Set up an external application to get a message off the "holding" queue, wait X seconds, and then put it back on the input queue. The message flow (or external application) might also create a user-defined header field within the message to keep track of the number of retries.
- Or, set the HTTPRequest node property for "Request Timeout (in seconds)" to X seconds; this may or may not be adequate, depending on why the web service is unavailable. Set up the message flow to backout the message to the input queue, when the web service is unavailable. Configure the input queue backout threshold property to Y. Attach the MQInput failure terminal to something useful, to clear the input message after Y attempts.
- Or, create a static java method (either as part of a java compute node, or somewhere within the broker classpath), that can call Thread.sleep(). Declare an external procedure in the ESQL to call this method from ESQL; (intentionally putting a message flow to sleep probably conflicts with best practices, so use at your own risk.) Set up the message flow to sleep for X seconds, then backout the message to the input queue, when the web service is unavailable. Configure the input queue backout threshold property to Y. Attach the MQInput failure terminal to something useful, to clear the input message after Y attempts.
|
|
Back to top |
|
 |
sjaganna |
Posted: Wed Apr 08, 2009 5:25 pm Post subject: |
|
|
Novice
Joined: 20 Feb 2009 Posts: 16
|
Was this issue resolved if so can you please post the solution.
Thanks
Srikanth |
|
Back to top |
|
 |
|