| Author |
Message
|
| zpat |
 Posted: Tue Mar 25, 2014 4:35 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Now that you have finally told us what the problem is....
Why are you using report messages?
In over 17 years of using MQ I have never seen the need for these.
Report messages should not be relied upon as part of the application in real-time (IMHO).
Why not just use MQGET with wait on the request queue. If the wait interval expires then there is no reply. Allow the reply message to expire a bit later.
Get the request by matching msgid or correlid and the design works fine - either you get a reply or you don't. Any orphaned replies expire off in due course.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| christo |
| Posted: Tue Mar 25, 2014 4:50 am Post subject: |
|
|
Newbie
Joined: 23 Mar 2014
Posts: 8
|
| Vitor wrote: |
If the answer is "because I want to get a report on expiry message with full data" then you've just discovered your design doesn't work. |
Can you pls suggest any other solution for expire these messages in its expiry timings??? |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Mar 25, 2014 5:01 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| christo wrote: |
| I will be sending two request to two external system(Mq),at the same time i will put two msg in expiry q with report option enabled(30 seconds and 10 seconds).So if i didnt get reply from external system with in the time, i should get a report msg in replyto q of the expiry msg ,so i will come know extrenal system not replied with in time.. |
You can use MQGet nodes with 30 seconds timeout, so your flow can continue with or without a response message, which can be handled by your demand. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 25, 2014 5:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| christo wrote: |
| Can you pls suggest any other solution for expire these messages in its expiry timings??? |
I and others have talked about MQGet with wait. We're not going to suggest other solutions until you explain fairly clearly why that doesn't meet your requirements.
If you want help getting your flawed design to work, look up "flawed" in a dictionary & you'll see why we're suggesting other methods.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| christo |
| Posted: Tue Mar 25, 2014 5:18 am Post subject: |
|
|
Newbie
Joined: 23 Mar 2014
Posts: 8
|
| Tibor wrote: |
| You can use MQGet nodes with 30 seconds timeout, so your flow can continue with or without a response message, which can be handled by your demand. |
As per my current design,i have one req flow and one res flow(MQ Input node).The res flow will be triggered when i will get resposne from external system and i have a MQ get node in res flow to remove msg from expiry q if i recive a resposne with in time period.So how can use MQ get node directly in res flow,if i use, i should trigger res flow using some timer nodes.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 25, 2014 5:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| christo wrote: |
| Tibor wrote: |
| You can use MQGet nodes with 30 seconds timeout, so your flow can continue with or without a response message, which can be handled by your demand. |
As per my current design,i have one req flow and one res flow(MQ Input node). |
You're really not getting this "flawed design" concept are you?
So explain, clearly and with short words (because I'm old and a little bit stupid) why you designed a sync request/response pattern (i.e. one where you send a request and wait for a response) in 2 flows and not the more usual pattern we're all suggesting.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 25, 2014 5:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Tibor wrote: |
| PeterPotkay wrote: |
| This process runs periodically. Its not defined how often. Experimentation shows its about every 5 minutes. |
There is a parameter namely "ExpiryInterval" and its default value is 300 sec (=5 min). You can find more info about it on IBM support site:
http://www-01.ibm.com/support/docview.wss?uid=swg21288579 |
Thanks Tibor. I was not aware that ExpiryInterval was possible in the qm.ini file for mid tier systems. The InfoCenters only talk about the QM attribute that only applies to z/OS systems.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Mar 25, 2014 5:40 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
A non-optimal solution:
- request flow:
[MQInput] - [BusinessLogic] - [MQOutput (to app2/app3)] - [MQGet (30sec)] - [MQGet (immediate)] - [Compute*] - [MQOutput (to response flow)]
- response flow:
[MQInput] - [BusinessLogic] - [MQOutput (to app1]
In Compute* you can handle if the message was empty and create a custom response. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 25, 2014 5:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want to asynchronous request/response, you should just use aggregation.
It's perfectly fine to use aggregation for n=1 requests.
It's not at all clear why you want to use asynchronous requst/response. |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Mar 25, 2014 5:54 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
mqjeff: +1
Yes, Aggregation* seems better with its Timeout property. |
|
| Back to top |
|
|
| satya2481 |
| Posted: Tue Mar 25, 2014 9:16 am Post subject: |
|
|
Disciple
Joined: 26 Apr 2007
Posts: 170
Location: Bengaluru
|
The requirement is that before consumer times out, flow has to send a timeout message indicating response is not received from external system or Provide application.
We have to achieve this scenario with MQ Protocol and Async mode. We dont want to hold the transaction during wait interval, otherwise we could have used MQGet node inside main request flow and waited for specified time interval.
If our design itself is wrong to handle such a requirement then what is other best solution? While designing the flow we need to think from below points as well
1. MQ Protocol
2. Asynch call with the external system
3. Internally 3-4 flows orchestration is present so in between the flow also we have to handle timeout scenario
4. If additional instances of the flow are created then the design should not break
- Thank you in advance
Satya |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 25, 2014 10:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| satya2481 wrote: |
| We have to achieve this scenario with MQ Protocol and Async mode. |
Why? What's the technical requirement behind this, especially why you're using an async model to satisfy a sync request (and it must be a sync request or you wouldn't be sending a timeout message).
| satya2481 wrote: |
| We dont want to hold the transaction during wait interval |
Why not? What's bad about that? What problem do you see (or did you see) when implementing this?
| satya2481 wrote: |
While designing the flow we need to think from below points as well
1. MQ Protocol
2. Asynch call with the external system
3. Internally 3-4 flows orchestration is present so in between the flow also we have to handle timeout scenario
4. If additional instances of the flow are created then the design should not break |
Where do this points come from? Accepting that you have WMQ as a transport protocol, it's still not clear why you're mixing async & sync in your design. What's this orchestration you speak of and why does that invalidate what we're proposing?
That the design should not break is not a requirement; it's part of the job!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Tibor |
| Posted: Wed Mar 26, 2014 12:53 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| satya2481 wrote: |
| We dont want to hold the transaction during wait interval |
As Vitor wrote before, there is a confusion in your demand.
But if you are afraid of slow processing (because of 30 sec timeout), you can easily increase the number of instances. |
|
| Back to top |
|
|
| christo |
| Posted: Wed Mar 26, 2014 1:07 am Post subject: |
|
|
Newbie
Joined: 23 Mar 2014
Posts: 8
|
| The problom am seeing when using an MQ Get node, if i didnt get reposne in 30 seconds , i will infrom my consumer that there was a tim eout happend .But after 30 seconds external system respose may come ,if it comes i have to use that resposne and do something .Thats why we are uisng an asynchronus mode communication. |
|
| Back to top |
|
|
| Tibor |
| Posted: Wed Mar 26, 2014 1:25 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| christo wrote: |
| ... if i didnt get reposne in 30 seconds , i will infrom my consumer that there was a tim eout happend .But after 30 seconds external system respose may come ,if it comes i have to use that resposne and do something. |
This is not a message broker problem but a design question. You must decide how to handle the messages with timeout. Logically, if requester defines a timeout, all the late responses should be discarded. |
|
| Back to top |
|
|
|
|
