| Author |
Message
|
| 16legal |
 Posted: Sat May 03, 2014 9:16 am Post subject: Handling Timeout Scenario in Aggregate node |
 |
|
Novice
Joined: 05 Jun 2013
Posts: 21
|
| I have been facing an issue in timeout Aggregation node.Whenever there is a timeout in Aggregation node , it triggers a blank message in the timeout terminal .Although I can create a custom message to respond back of a timeout ,the issue is that nothing gets populated in the timeout message for me get the reply identifier or the correlation Id to respond back.I have tried to use global cache,MQRFH2 header and environment variables to fetch the identifiers,but nothing seems to propagated ahead.can you please suggest any other solution ? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Sat May 03, 2014 9:37 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
are you saying that once the timeout happens you have lost the context of the original message?
Have you looked at the other posts in this forum on the subject?
_________________
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 |
|
|
| 16legal |
| Posted: Sat May 03, 2014 10:35 am Post subject: Handling Timeout Scenario in Aggregate node |
|
|
Novice
Joined: 05 Jun 2013
Posts: 21
|
| Yes .Only two tags gets populated.One is Properties which contains empty tags and the other is comIbmAggregatereply blank tag.except these fields,nothing gets populated. |
|
| Back to top |
|
|
| 16legal |
| Posted: Sat May 03, 2014 11:19 am Post subject: Handling Timeout Scenario in Aggregate node |
|
|
Novice
Joined: 05 Jun 2013
Posts: 21
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat May 03, 2014 1:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
Working as intended. If you never got even a partial response, why would you expect a correlId? Typically what you do is have a dummy service to which you send the original MQMD and that sends it back into the aggregation... Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| 16legal |
| Posted: Sun May 04, 2014 1:25 am Post subject: Handling Timeout Scenario in Aggregate node |
|
|
Novice
Joined: 05 Jun 2013
Posts: 21
|
| Under what circumstances should i send messages to the dummy service,since the timeout is decided by the aggregate Reply node ? Or Is it that for every transaction,I send the message to the dummy service?This will lead to the piling up of messages even for successful transactions. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun May 04, 2014 7:45 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
IMHO, the question you are asking is answered in other posts in this forum on Aggregation.
To save you the effort, you configure the dummy 'service' so that every aggregation 'Fan-out' uses it. This way the 'fan-in' will always include this dummy message even when there is a timeout because this bit of the aggregation will always return a value. Therefore NO messages will pile up. If they did you could always put an expiry on the message.
As an aside,
Using WMQ Message expiry is a very good idea. I wish you could set tome parameter somewhere in the QMGR that would set a default timeout on Every message. It would save a lot of coding 
_________________
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 |
|
|
| 16legal |
| Posted: Sun May 04, 2014 9:49 pm Post subject: Handling Timeout Scenario in Aggregate node |
|
|
Novice
Joined: 05 Jun 2013
Posts: 21
|
| But the problem is that ,on timeout even the dummy message contents gets lost.I was thinking of putting messages in queue parallel to FAN-OUT aggregation and retrieving the message after AggregateReply node through MQGET node,but the issue here is that how do i decide when to send the timeout message since the timeout gets decided only in the AggregateReply node and everytime the invocation will take place at the MQGET node. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun May 04, 2014 10:18 pm Post subject: Re: Handling Timeout Scenario in Aggregate node |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| 16legal wrote: |
| But the problem is that ,on timeout even the dummy message contents gets lost.I was thinking of putting messages in queue parallel to FAN-OUT aggregation and retrieving the message after AggregateReply node through MQGET node,but the issue here is that how do i decide when to send the timeout message since the timeout gets decided only in the AggregateReply node and everytime the invocation will take place at the MQGET node. |
Wrong - on time out the dummy is in it's folder in the aggregation.
In fact it is the message that should always be in the aggregation folder for any complete or timed out/incomplete aggregation.
Any messages coming after time out are irrelevant and should just be consumed, they do not create an aggregation folder and are propagated through the error/failure terminal in the format received ? (from memory)
Consider those messages orphaned and belonging no longer to any aggregation.
Now if you want to log late messages for SLA and such, you do have a correlid on them. You could then log against time elapsed since correlid with a cut off where you get a correlid not found (expired). However this type of scenario looks more like a collection than an aggregation, as all msgs in a collection would have the same correlid...(presomption)... (or the collection identifier would need to be extracted from the body of the message. The same way if the body holds the time the request was created you could calculate an elapsed time... for SLA comparison).
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
