| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Retry Mechanism –design |
View previous topic :: View next topic |
| Author |
Message
|
| Dvz |
 Posted: Thu Jul 14, 2011 5:26 pm Post subject: Retry Mechanism –design |
 |
|
Newbie
Joined: 14 Jul 2011
Posts: 2
|
This is my 1st post….Hoping to get response
We have a requirement wherein we check the response from the back end. If it has a particular error code say “X” we must wait for 60 seconds then try again. We need to do this twice then send the response to the from end..
Initially I used the Timeoutcontrol node and TimeoutNotification node to do the retry.But I realized it has a performance bottleneck “You cannot increase the Additional Instances property of the message flow if it starts with aTimeoutNotification node, therefore you cannot apply more threads to increase the capacity of the flow.”
Now I’m trying to use Java Schdular API
I couldn't post link sry
The code in my java compute node looks like
Public class Retry_Java extends MbJavaComputeNode
{
MbMessageAssembly OutAss;
MbOutputTerminal out = getOutputTerminal(“out”)
public class Task extends TimerTask {
public void run()
{
Out.propogate(OutAss) ;
}
}
public void evaluate(MbMessageAssembly contact admin)
{
---------------
------------
Task task1 = new Task();
Integer delay = 10*1000
timer.schedule( task1, delay );
-----
-----------
}
}
Could any1 help me with this .Does any1 have any other idea? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Jul 14, 2011 8:01 pm Post subject: Re: Retry Mechanism –design |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Dvz wrote: |
This is my 1st post….Hoping to get response
We have a requirement wherein we check the response from the back end. If it has a particular error code say “X” we must wait for 60 seconds then try again. We need to do this twice then send the response to the from end..
|
Define here the meaning of retry.
Does this mean that eventually you might get a delayed response on your first request? => just triple the wait time on the MQGet node. You won't wait if you got an early response.
If this means wait some time and retry the whole operation, the question comes up if this is a "synchronous" or "asynchronous" call, as each would most probably be treated differently... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Dvz |
| Posted: Fri Jul 15, 2011 3:03 am Post subject: |
|
|
Newbie
Joined: 14 Jul 2011
Posts: 2
|
Its the second one ,we wait some time and retry the whole operation.
It is asynchronous,the front end isnt waiting,but we need to redo the entire operation 3 times max in case of failure. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Jul 15, 2011 4:41 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
To track state in WMB (which is what you need to do to retry), I use a Java Singleton from a callable Jar via Java Compute Node.
Inside the Singleton, there are multiple threads, and when a timeout happens or other condition needs a retry, the message can be replayed.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
