ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » IIB: How to wait in-memory for message response on MQ Queue

Post new topic  Reply to topic
 IIB: How to wait in-memory for message response on MQ Queue « View previous topic :: View next topic » 
Author Message
infotainment
PostPosted: Sun Aug 28, 2016 7:19 am    Post subject: IIB: How to wait in-memory for message response on MQ Queue Reply with quote

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
View user's profile Send private message
vishBroker
PostPosted: Sun Aug 28, 2016 8:05 am    Post subject: Reply with quote

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
View user's profile Send private message
adubya
PostPosted: Sun Aug 28, 2016 8:30 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
infotainment
PostPosted: Sun Aug 28, 2016 9:11 am    Post subject: Reply with quote

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
View user's profile Send private message
adubya
PostPosted: Sun Aug 28, 2016 9:18 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
zpat
PostPosted: Sun Aug 28, 2016 11:38 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
infotainment
PostPosted: Mon Aug 29, 2016 6:16 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Mon Aug 29, 2016 6:32 am    Post subject: Reply with quote

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
View user's profile Send private message
vishBroker
PostPosted: Mon Aug 29, 2016 6:49 am    Post subject: Reply with quote

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
View user's profile Send private message
infotainment
PostPosted: Mon Aug 29, 2016 11:02 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Mon Aug 29, 2016 11:09 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Mon Aug 29, 2016 11:11 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » IIB: How to wait in-memory for message response on MQ Queue
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.