| Author |
Message
|
| Christy |
 Posted: Fri Apr 04, 2003 8:40 am Post subject: use Aggregation or not? |
 |
|
Newbie
Joined: 04 Apr 2003
Posts: 5
|
Hi Guys,
I have a question here.
I want to set a timeout of 10 secs between my request and reply message flows.
the message which is send through the request if it does not return back in the response message flow in 10 sec. i need to send a timeout message at the output. if it returns back then to send the message it self.
the request respone message works on MsgID-CorrelationID structure.
so what would you guys suggest ... should i use Aggregation or DB nodes?
which one is more feasible and less CPU overhead.
thanks,
Chris. |
|
| Back to top |
|
 |
| gward123 |
| Posted: Fri Apr 04, 2003 10:53 am Post subject: |
|
|
Novice
Joined: 27 Mar 2003
Posts: 11
Location: Roseland, NJ
|
I was just thinking that you might not have to be that complicated (i.e., using Aggregation or DBs just to get a timer) given what you're trying to achieve.
If this is a single request and single reply, you could store a timestamp as an extra field in your message. How you generate the timestamp depends on where your timer starts and ends.
1. If the 10 seconds starts at the time you get the message in the MQInput node, then add the current timestamp to your message immediately following that node. Do your processing and make sure to carry this "temporary" field through to your Reply flow. When the Reply flow gets the message it can check to see if 10 seconds have elapsed (assuming the request and reply flow are on the same broker, hence the same clock) and do whatever handling based on that. You could do this comparison in a filter node.
2. If the 10 seconds starts from the time the message was put to the queue being read by the request flow, you could set a LARGE fixed Expiry time on the request message. This would be a value known be the flow (say 100000 - which is 10000 seconds). The request flow can check the expiry field on the incoming message to see the remaining time, figure the difference (i.e., the amount of time used thus far), and store that in the same temporary field. Then it's the same process as above the rest of the way.
Not knowing the full context of your situation, I hope this helps!
_________________
Gary J. Ward
Sr. Technical Consultant
ADP |
|
| Back to top |
|
|
| Christy |
| Posted: Fri Apr 04, 2003 1:48 pm Post subject: |
|
|
Newbie
Joined: 04 Apr 2003
Posts: 5
|
thanks Gary,
Does anybody has code for this request-response time monitoring.
thanks,
Chris. |
|
| Back to top |
|
|
| Christy |
| Posted: Mon Apr 07, 2003 10:02 am Post subject: |
|
|
Newbie
Joined: 04 Apr 2003
Posts: 5
|
well the timestamp idea does not work for me as i cannot add an extra field in the message.
also the other problem is that what if the message does not return from the mainframe adapter? and this cud happen because the adapter is designed in such a way that if it is not able to process the message at that time it can process it later and put the message in delayed response Queue.
so is there any other solution to communicate between 2 messageflows to check for timeout and then pass a timeout message.
thanks in adv.
Chris. |
|
| Back to top |
|
|
| lillo |
| Posted: Mon Apr 14, 2003 6:59 am Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
The only solution to your scenario is using Aggregation nodes with a timeout. If you get a reply then you will use the out terminal in the aggregate reply node but if yout don´t get a reply within the timeout interval, you will use the timeout terminal. In this case, if the reply arrives after the timeout the message will be propagate to the unknown terminal.
I hope this help you
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| wmqiguy |
| Posted: Mon Apr 14, 2003 7:49 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
Is there a reason that the sender of the request is not handling this? Since it is a request/reply, it should be checking for the reply. Why doesn't it just programmatically handle the 10 second response?
Todd |
|
| Back to top |
|
|
| lillo |
| Posted: Mon Apr 14, 2003 10:44 pm Post subject: |
|
|
Master
Joined: 11 Sep 2001
Posts: 224
|
What would happen if the requester is down?
How would you handle the timeout situation programmatically?
_________________
Lillo
IBM Certified Specialist - WebSphere MQ |
|
| Back to top |
|
|
| wmqiguy |
| Posted: Tue Apr 15, 2003 7:36 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
Our standard was that the complete request/reply transaction had to be completed within 10 seconds, regardless of where the failure exists.
If the requestor did not receive the response in the required time, it would have to resend the request.
If the requestor became unavailable after sending a request, it had 10 seconds to recover and receive the reply. Otherwise, it would have to resend the request. The original request is handled through expiry.
In our system, we allow the message to expire and try to honor the synchronous nature of request/reply. The interesting twist from Christy's system is that it allows synchronous messages to become asynchronous, if a certain timout has not been met. In an overly simplified world, I would then code the requestor to switch modes from synch to asynch based on the timeout. Unfortunately, the world is never simple. 
How to architect that would depend a lot on what the paradigm was by the requestor. I'm sure there are all kinds of twists and turns that would require some discovery. The aggregate nodes might be the way to go, but I wanted to shoot another possibility out there to keep things fresh.  |
|
| Back to top |
|
|
| Christy |
| Posted: Wed Apr 16, 2003 11:07 am Post subject: |
|
|
Newbie
Joined: 04 Apr 2003
Posts: 5
|
what will happen if the there is no response for more than timeout time.
i tried it and i am unable to generate a response(timeout) from it.
Chris. |
|
| Back to top |
|
|
|
|
