| Author |
Message
|
| infotainment |
 Posted: Sun Aug 28, 2016 7:19 am Post subject: IIB: How to wait in-memory for message response on MQ Queue |
 |
|
Apprentice
Joined: 18 Apr 2016
Posts: 41
|
Dear Team,
We are having a situation in which in want to wait for response for a particular message on MQ.
We will send request MQ Message using MQOutput node then after sending, we want to wait in the same flow on MQ Queue till response comes.
As soon as response comes for that particular messageID, we will pick response and proceed for other tasks in same flow.
Please guide for this.
In other tools like TIBCO, this can be done through WaitforJMSQueueNode.
Regards, |
|
| Back to top |
|
 |
| vishBroker |
| Posted: Sun Aug 28, 2016 8:05 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
1. You can make use of MQGet node.
2. Do a MQGet using proper correlId. |
|
| Back to top |
|
|
| adubya |
| Posted: Sun Aug 28, 2016 8:30 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
Is it important to process input messages completely in the order they're received ? Or could you process multiple input messages "simultaneously" ?
How much additional processing is required once you've received your MQ response ? And does that processing need information which was received in the original input message or just from the response message ?
_________________
Independent Middleware Consultant
andy@knownentity.com |
|
| Back to top |
|
|
| infotainment |
| Posted: Sun Aug 28, 2016 9:11 am Post subject: |
|
|
Apprentice
Joined: 18 Apr 2016
Posts: 41
|
There is much processing and mutiple orher calls based on response received.
I need to use same msg flow and wait for response for this request. |
|
| Back to top |
|
|
| adubya |
| Posted: Sun Aug 28, 2016 9:18 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
Why do you have to use the same flow rather than have a separate response processing flow ?
_________________
Independent Middleware Consultant
andy@knownentity.com |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Aug 28, 2016 11:38 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Generally not a good idea to wait in a flow. Especially when MQ is so good at handling messages asynchronously.
But if you must use the MQGET node this way - set a sensible timeout value and make sure reply messages are expiring in case they are left behind.
Think about scalability when doing this. Test for performance.
_________________
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 |
|
|
| infotainment |
| Posted: Mon Aug 29, 2016 6:16 am Post subject: |
|
|
Apprentice
Joined: 18 Apr 2016
Posts: 41
|
| Quote: |
| But if you must use the MQGET node this way - set a sensible timeout value and make sure reply messages are expiring in case they are left behind. |
Okay but this does not seems to be feasible as a Response greater than one second delay to set Timeout value will break the logic.
Is there any Node in IBM which supports in memory wait for this scenario? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 29, 2016 6:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| infotainment wrote: |
| Quote: |
| But if you must use the MQGET node this way - set a sensible timeout value and make sure reply messages are expiring in case they are left behind. |
Okay but this does not seems to be feasible as a Response greater than one second delay to set Timeout value will break the logic. |
Ok, you need to explain that a bit more. How does that "break the logic"? If the business logic "breaks" if a response takes more than 1 second, how will "waiting in memory" help?
| infotainment wrote: |
| Is there any Node in IBM which supports in memory wait for this scenario? |
Yes. The MQGet node is intended for this sort of scenario. Alternatively, you could cache the id you're waiting for, end the flow at the MQOutput node and have another flow with an MQInput node where the first act is to check the cache for the relevant id.
You could also take pity on those of us with limited TIBCO knowledge and explain exactly what this "WaitForJMSQueueNode" does, and specifically what it does differently to the MQGet node.
You could further explain what you need by "wait in memory". IIB threads will remain live in memory as long as there is traffic to process, and for a period after demand has slowed. What exactly do you mean by this, and indeed what problem does it cause you if a new thread has to be spun up? I echo the comments of my associates about leveraging MQ's abilities to process asynchronous messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vishBroker |
| Posted: Mon Aug 29, 2016 6:49 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
As you might have gathered from the other responses - it is always recommended not to use synchronous solution for async usecase.
There are few other ways to implement required logic.
One of the way would be - use Global Cache.
You can store meta data from the request in GC and retrieve that in your response flow.
YOur response flow would be listening on Response Queue. You need to lookup GC to get metadata and do required processing afterwards.
THis is just one of the ways - you need to look into performance aspect of it.
alternatively , You may want to store required metadata in the response message as well - if possible.
Again - this depends on the usecase and performance/scalability needs to be considered. |
|
| Back to top |
|
|
| infotainment |
| Posted: Mon Aug 29, 2016 11:02 am Post subject: |
|
|
Apprentice
Joined: 18 Apr 2016
Posts: 41
|
Dear folks,
I just finished up reading documentation based on your solutions regarding MQGET and global cache.
Happy part is that MGGet will serve us same way (in memory wait) in same msg flow ( i should not say it thread) by using timeout as suggested by someobe here.
So this is actually same as waitForJms in tibco which wait for a msg until it is there with a timout in same flow ofcourse.
Actually we are having a sync call from customer care for telco order which will be spliited into 4 asynch calls one after another (sequentially) and final response to be sent to the waiting agent.
Thanks for feedback.
Global cache solution still needs to be evaluated though. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 29, 2016 11:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| infotainment wrote: |
| Actually we are having a sync call from customer care for telco order which will be spliited into 4 asynch calls one after another (sequentially) and final response to be sent to the waiting agent. |
You might want to look into the Aggregation nodes if there's no actual requirement to make these calls sequentially; it's just that's how it's been implemented currently.
This does a lot of the heavy lifting for you in this kind of requirement.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 29, 2016 11:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| infotainment wrote: |
| Actually we are having a sync call from customer care for telco order which will be spliited into 4 asynch calls one after another (sequentially) and final response to be sent to the waiting agent. |
You might want to look into the Aggregation nodes if there's no actual requirement to make these calls sequentially; it's just that's how it's been implemented currently.
This does a lot of the heavy lifting for you in this kind of requirement. |
Even if you have to make them sequentially, you can still use the aggregation nodes and propagate to each request in the right order.
Then you only have to wait for the slowest response, rather than the whole time for each request/response to finish.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
