| Author |
Message
|
| Qadeer_824 |
 Posted: Thu Sep 11, 2008 5:00 pm Post subject: Timeout notification & timeout control nodes for retry l |
 |
|
Acolyte
Joined: 04 Oct 2007
Posts: 59
|
Hi,
I have a requirement where a particular operation (could be a failure in ftp file transfer or failure in invoking web services), needs to be retired at a configurable interval (say 60secs) and any messages after this need to be queued up until this is successful..
To implement this, i could think of the easiest way to use Thread.sleep in a Java Compute node, but it doesnt work out to be that simple. The Java code has unexpected behaviour and moves the broker to inconsistent state.
Second thing i can think of is to use a timeout control and notification node with a TimeoutRequest.Start property of NOW + 60secs. This does seem to work perfectly well.
However, the problem comes in case of scenarios where a restart of broker or the message flow is required. In such cases, if i stop the message flow, i see that a MBTIME message is placed into SYSTEM.BROKER.TIMEOUT.QUEUE (Not Persistent by default, but can be made persistent).
After i restart the message flow, the message is removed from SYSTEM.BROKER.TIMEOUT.QUEUE, but the timeout notification node was not called. Which means that there is a loss of message !
The timeout request has Action, Identifier & Start values set.
Am i doing something wrong here? How can i ensure that after the flow is restarted, the timeout notification node is triggered again and the message which was failing earlier is retried? |
|
| Back to top |
|
 |
| AkankshA |
| Posted: Thu Sep 11, 2008 7:40 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
There's is an attribute in TimeOut request message for this behaviour... dont remember the name exactly.. just check out the format of TimeOutRequest Message
_________________
Cheers |
|
| Back to top |
|
|
| Qadeer_824 |
| Posted: Thu Sep 11, 2008 9:50 pm Post subject: |
|
|
Acolyte
Joined: 04 Oct 2007
Posts: 59
|
There's one property "Request Message Persistence" on timeout control & timeout notification nodes which is already set to "Yes".
As per ibm's documentation, the structure of Timeout Request message is
| Code: |
<TimeoutRequest>
<Action>SET | CANCEL</Action>
<Identifier>String (any alphanumeric string)</Identifier>
<StartDate>String (TODAY | yyyy-mm-dd)</StartDate>
<StartTime>String (NOW | hh:mm:ss)</StartTime>
<Interval>Integer (seconds)</Interval>
<Count>Integer (greater than 0 or -1)</Count>
<IgnoreMissed>TRUE | FALSE</IgnoreMissed>
<AllowOverwrite>TRUE | FALSE</AllowOverwrite>
</TimeoutRequest>
|
and none of these talk about retrying after the flow has restarted. Any pointers please? |
|
| Back to top |
|
|
| AkankshA |
| Posted: Thu Sep 11, 2008 10:19 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
IgnoreMissed
Set this element to TRUE or FALSE to control whether timeouts, that occur while either the broker or the timeout notification flow is stopped, are processed the next time that the broker or timeout notification flow is started. The default value is TRUE, which means that missed timeouts are ignored by the TimeoutNotification node when the broker or message flow is started. If this value is set to FALSE, the missed timeouts are all processed immediately by the TimeoutNotification node when the flow is started.
You must set the Request Persistence property of the TimeoutControl node to Yes or Automatic (with the originating request message being persistent) for the stored timeouts to persist beyond the restart of the broker or the timeout notification flow.
_________________
Cheers |
|
| Back to top |
|
|
| Qadeer_824 |
| Posted: Fri Sep 12, 2008 2:16 am Post subject: |
|
|
Acolyte
Joined: 04 Oct 2007
Posts: 59
|
Thanks Akanksha. It works perfectly well now. This forum really rocks !!
I need another help now.
As i have implemented the retry logic, in case of any failure, the flow automatically moves all following requests to a waiting queue. What i wanna do is once the issue is resolved, i want to move all the data from waiting queue to the input queue of the current message flow.
Can someone please advice if this is possible and how this could be done?
Many thanks,
Qadeer |
|
| Back to top |
|
|
| AkankshA |
| Posted: Fri Sep 12, 2008 3:18 am Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
As i have implemented the retry logic, in case of any failure, the flow automatically moves all following requests to a waiting queue. What i wanna do is once the issue is resolved, i want to move all the data from waiting queue to the input queue of the current message flow.
so you simply want to replay all messages from one speific queue to another specific queue ???
Mb can do that.. most basic feature. isn't it ?
or am i taking it wrongly ??
_________________
Cheers |
|
| Back to top |
|
|
| Qadeer_824 |
| Posted: Fri Sep 12, 2008 4:04 am Post subject: |
|
|
Acolyte
Joined: 04 Oct 2007
Posts: 59
|
Yes, but those should be moved out of the queue only after the issue has been resolved i.e. If suppose there was a failure in the FileOutputNode which was being retried and once it has been resolved, the control would come to the out terminal of FileOutputNode. From this out terminal, i want to move all the data from waiting queue to input queue of current flow.
I would have used MQInput node, but it doesnt have an in terminal ? What is the other way (if any)?
Thanks,
Qadeer |
|
| Back to top |
|
|
| kspranava |
| Posted: Fri Sep 12, 2008 7:03 am Post subject: |
|
|
Centurion
Joined: 27 Apr 2003
Posts: 124
|
Hi,
Why not play with MQGet node? Once all the messages have been moved, control would return to 'No Message' terminal and don't wire this one. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 12, 2008 7:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| AkankshA |
| Posted: Sun Sep 14, 2008 8:01 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
MQGet is agood option..
just remember that your MQInput and MQGet node in a flow can not operate on the same queue
_________________
Cheers |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 15, 2008 1:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| qadeer_824 wrote: |
| I have a requirement where a particular operation (could be a failure in ftp file transfer or failure in invoking web services), needs to be retired at a configurable interval (say 60secs) and any messages after this need to be queued up until this is successful.. |
We have seen this type of request time and time again.
This is a bad design (message affinity) and this way lies many a problem...
You could of course stop the flow using the configmgr proxy and move the message to a different queue to be retried until successful... and then restart the default flow... What happens if you have a poison message???
What of the messages queuing up while you resolve the poison situation???
Again bad, bad design. No scalability.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
