| Author |
Message
|
| bprasana |
 Posted: Thu May 20, 2010 10:28 pm Post subject: Timeout Notifications |
 |
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
Hi Guys,
Problem:
We Send a message to backend(MF) and store original msg and MQMD so that on response from backend we match the message and update one more database and send response back to front end.
I need to implement a timeout notification to front end. If I dont get a message back in say 90 secs.
Can someone suggest a solution for this? Can i use TimeOut Nodes for this to generate a even message?
Thanks
bprasana |
|
| Back to top |
|
 |
| fatherjack |
| Posted: Fri May 21, 2010 12:06 am Post subject: Re: Timeout Notifications |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| bprasana wrote: |
| Can i use TimeOut Nodes for this to generate a even message? |
Not really. The timeout nodes are typically used by applications that require events to occur at particular times, or at regular intervals.
| bprasana wrote: |
| Can someone suggest a solution for this? |
Can you use an MQGet Node and wait for 90 seconds for the response?
Rgds
Jack.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri May 21, 2010 1:41 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
See http://www.ibm.com/developerworks/websphere/library/techarticles/0603_schutz/0603_schutz.html
Your could create a timeout control message with a start time 90 seconds in the future and send that into a TC node when you send your request message. The TN node would then "pop" 90 seconds later and you'd do your MQGET with a specified correlID. The tricky part would be computing <StartDate> and <StartTime> to be 90 seconds in the future, allowing for things like sending the message at 23:59:35.
It'd be easier to use the MQGet with wait. But depending on your volume, you might have a lot of gets sitting out there.
_________________
-wayne |
|
| Back to top |
|
|
| Luke |
| Posted: Fri May 21, 2010 2:31 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
| How are you storing the original message and MQMD? Perhaps if you're storing that on a queue you could set an expiry of 90 seconds and use MQ report options to report on expiry of those messages. The report message could then trigger the timeout notification to the front end? |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri May 21, 2010 3:06 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
IIRC, expiry reports are generated when an MQGET is executed against an expired message (or EXPRYINT interval is reached on zOS). So that might be more than 90 seconds......
_________________
-wayne |
|
| Back to top |
|
|
| Luke |
| Posted: Fri May 21, 2010 3:20 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
| wschutz wrote: |
| IIRC, expiry reports are generated when an MQGET is executed against an expired message (or EXPRYINT interval is reached on zOS). So that might be more than 90 seconds...... |
Yes, I think since MQ V6 there's an expirer (distributed platforms too), which is configurable (ExpiryInterval). So as you say, it may not be absolutely precise to do it this way ... I think it's an option though, depending on how accurate the 90 seconds needs to be. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri May 21, 2010 3:22 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Luke wrote: |
| wschutz wrote: |
| IIRC, expiry reports are generated when an MQGET is executed against an expired message (or EXPRYINT interval is reached on zOS). So that might be more than 90 seconds...... |
Yes, I think since MQ V6 there's an expirer (distributed platforms too), which is configurable (ExpiryInterval). So as you say, it may not be absolutely precise to do it this way ... I think it's an option though, depending on how accurate the 90 seconds needs to be. |
Yup, good to know all the options .....
_________________
-wayne |
|
| Back to top |
|
|
| bprasana |
| Posted: Fri May 21, 2010 8:10 am Post subject: MQ Get |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
Thanks for all the Responses.
Yes I am storing MQMD in a Q.
But I do MQGET in My Response Flow only when i receive a message from MF? But in case of Timeout, I wouldnt do MQGET.
@ wschutz - How does the this work for multiple messages sent to backend ?http://www.ibm.com/developerworks/websphere/library/techarticles/0603_schutz/0603_schutz.html
@Luke - 90s is need not be precise. Do you have more details on this "expirer" in MQ v6 ? |
|
| Back to top |
|
|
| fatherjack |
| Posted: Fri May 21, 2010 8:54 am Post subject: Re: MQ Get |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| bprasana wrote: |
But I do MQGET in My Response Flow only when i receive a message from MF? But in case of Timeout, I wouldnt do MQGET.
|
How do you know you've got a response message from MF without doing a MQGET. If you do the MQGET with a wait of 90 seconds specified when you get the NO_MSG_AVAILABLE return code (aftr 90 seconds) you can send your timeout response message back to the front end.
| bprasana wrote: |
| Do you have more details on this "expirer" in MQ v6 ? |
It's just an MQ process that automatically removes expired messages from queues. Before it existed expired messages could potentially remain on queues forever i.e. expired messages stayed on queues until an application attempted to MQGET them. So in those bygone days we all had to write our own tidyup process to remove expired messages.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| bprasana |
| Posted: Fri May 21, 2010 10:32 am Post subject: I get it |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
Are you suggesting I use MQGET instead of MQInput in my Response Flow?
So here's how it would look
Success path
MQ GET(MF Response)----> MQGET(MQMD Store)--->update local DB--->REPLY TO Q
failure
MQGET(MF Resp)--->Create Timeout error--->MQGET(MQMD Store)---> Reply to Q
Is this correct? |
|
| Back to top |
|
|
| bprasana |
| Posted: Sat May 22, 2010 3:03 pm Post subject: doesnt look right |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
| This doesnt look right. This will not work for multiple messages |
|
| Back to top |
|
|
| fatherjack |
| Posted: Mon May 24, 2010 1:32 pm Post subject: Re: I get it |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| bprasana wrote: |
| Are you suggesting I use MQGET instead of MQInput in my Response Flow? |
No. I didn't quite understand your flow. I think what you're saying is that your request flow and response flow are separate flows. In which case the best place to do the timeout is at the front end client. If they don't get a response in 90 seconds, they timeout. If you set an expiry on both the request message and the mainframe response message of about the same value then if the mainframe doesn't get the request message or does subsequently respond then it doesn't really matter as the messages will expire anyway and the front end will already have timed out.
Jobs a good 'un.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| bprasana |
| Posted: Tue May 25, 2010 7:56 pm Post subject: Sounds good |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
yes you are right.. we have request and response flows separate to increase the throughput. Apparently our MF can pick up msgs faster and process them parallely but it wont provide the response fast enuf. 
I guess there is no way we can send timeout notification.
thanks guys
bprasana |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 25, 2010 8:08 pm Post subject: Re: Sounds good |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bprasana wrote: |
yes you are right.. we have request and response flows separate to increase the throughput. Apparently our MF can pick up msgs faster and process them parallely but it wont provide the response fast enuf.
I guess there is no way we can send timeout notification.
thanks guys
bprasana |
Of course you can. Use the aggregation pattern. Create the appropriate timeout response on the correct aggregation branch...
The aggregation pattern should provide you with a much higher throughput than the MQGET node. Remember to keep fan out and fan in flows separate and if you need the original message, you will have to supply it to the aggregation.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bprasana |
| Posted: Wed May 26, 2010 9:10 am Post subject: Aggregate Node |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
| arent we still waiting for Response from MF in case of Aggregation Framework? |
|
| Back to top |
|
|
|
|
