| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to generate TimeOut using MQ Get Node |
« View previous topic :: View next topic » |
| Author |
Message
|
| Partha.Baidya |
 Posted: Thu Dec 06, 2018 1:44 pm Post subject: How to generate TimeOut using MQ Get Node |
 |
|
Voyager
Joined: 05 Nov 2009
Posts: 97
|
I have use case where two application are communicating using Request/Response messaging. Both are communicating over MQ connection. But the consumer requires a synchronous style instead of asynchronous response. So we are making this communication synchronous in ESB layer using MQGet request/ response pattern.
ESB needs to generate timeout if the provider application does not reply within a specified time limit. In order to generate time out I am using MQGet Node's Wait interval.
In order to generate timeout using wait interval, this flow is not scalable as the each request message wait for the response before it allows another request to be propagate to the provider application.
I do not think that this is a best solution.
Could you please let me know is there any way to generate timeout using MQ Get node request/response paradigm? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 06, 2018 7:28 pm Post subject: Re: How to generate TimeOut using MQ Get Node |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Partha.Baidya wrote: |
| I do not think that this is a best solution. |
Using a synchronous model? Probably not.
| Partha.Baidya wrote: |
| Could you please let me know is there any way to generate timeout using MQ Get node request/response paradigm? |
I'm confused. By definition, you don't know the provider is not going to respond within the required SLA until it doesn't respond within required SLA. In MQ, that SLA is determined by the wait interval.
So how could you generate it by any other means than the wait interval?
As to scaling, there's nothing to stop you running additional instances provided that the original message id is returned in the response. If it's not, you're done. If it is, you can tie responses to requests and lack of responses to blanks but that's going to get messy on any sort of volume.
The whole point of MQ is to allow asynchronous communication. This is what happens when you try and bend it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Partha.Baidya |
| Posted: Fri Dec 07, 2018 6:27 am Post subject: |
|
|
Voyager
Joined: 05 Nov 2009
Posts: 97
|
I can design the flow in 2 ways. First way using 2 different flows
Request Flow:- Input Q --> Store the MSG ID --> Request Q
Reply Flow:- Reply Q --> MQ Get --> Response Q
2nd Way using single Flow.
Input Q --> Output Q to Provider --> MQ Get --> Response Q
In the first way of implementation the Reply Flow will start only when there is reply message received in the Reply Q. Because of this Wait Interval will exceed only when there is any issue to get the message from the Store Q. We will not be able to capture whether provider application replied with in the SLA.
Flow is scaleable without additional instances.
In the 2nd way of implementation we are getting the response back in the MQ Get node. In this case we are blocking other message to process until we get a reply or wait interval has been reached.
This flow is not scaleable without additional instances.
But my understanding is MQ Get Node Wait Interval setting does not wait for individual message, whenever it gets a message it reset the flag for wait interval. Let me know if my findings are incorrect and there is no other way of generating timeout using wait interval. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 07, 2018 7:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Partha.Baidya wrote: |
| Let me know if my findings are incorrect |
They are.
The MQGet node can have match options set so it's waiting for a specific message. Multiple instances of the flow can be waiting for different messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
