| Author |
Message
|
| pandeg |
 Posted: Fri Jul 10, 2015 8:48 am Post subject: Multiple MQGET associated to single MQ Input Node |
 |
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Hi, I want to use a single MQ Input node to retrieve messages from multiple application queues (1000 -1500) at the same time. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Jul 10, 2015 8:53 am Post subject: Re: Multiple MQGET associated to single MQ Input Node |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pandeg wrote: |
| I want to use a single MQ Input node to retrieve messages from multiple application queues (1000 -1500) at the same time. |
That's nice, and thank you for sharing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 10, 2015 8:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Assuming that there was actually a question embedded in that sentence that you couldn't be bothered to articulate:
You can't.
The MQInput node, like all MQ aware applications, issues a get against a single open queue. You couldn't, in a Java app, use a single MQGet to read from 1000-1500 queues but would need an equivalent number of individual MQGet calls. Likewise you'd need an equivalent number of MQInput nodes.
Though what you actually need is a different MQ topology. Any design that has 1000-1500 queues with messages that are all processed the same is seriously flawed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pandeg |
| Posted: Fri Jul 10, 2015 8:59 am Post subject: Re: Multiple MQGET associated to single MQ Input Node |
|
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Vitor wrote: |
| pandeg wrote: |
| I want to use a single MQ Input node to retrieve messages from multiple application queues (1000 -1500) at the same time. |
That's nice, and thank you for sharing. |
I am not sure..whether i can achieve this.. Can we have multiple MQGET instances associated to same MQ Input Node to retrieve messages from different app Q or I need to store the messages in Database and then using MQ input Node ,read them one by one. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 10, 2015 9:07 am Post subject: Re: Multiple MQGET associated to single MQ Input Node |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pandeg wrote: |
| Can we have multiple MQGET instances associated to same MQ Input Node to retrieve messages from different app Q |
See above. And your topology still sucks.
| pandeg wrote: |
| I need to store the messages in Database and then using MQ input Node ,read them one by one. |
Well you're not going to read them from a Database one by one with an MQ Input node and that's for sure. You might read them with a Database Input node, but that's not "one by one".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 10, 2015 9:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Are you really trying to read from 1000 to 1500 queues?
Or are you trying to read 1000 to 1500 messages?
You can tell an MQGet node to use a specific queue each time you call it, based on the message you pass to it.
So you could use a single message to trigger an MQInput node, that then ran a loop over an MQGet node that read from lots and lots of different queues.
This is a terrible design. |
|
| Back to top |
|
|
| pandeg |
| Posted: Fri Jul 10, 2015 10:00 am Post subject: |
|
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| mqjeff wrote: |
Are you really trying to read from 1000 to 1500 queues?
Or are you trying to read 1000 to 1500 messages?
You can tell an MQGet node to use a specific queue each time you call it, based on the message you pass to it.
So you could use a single message to trigger an MQInput node, that then ran a loop over an MQGet node that read from lots and lots of different queues.
This is a terrible design. |
This could be one of the approach for me..but not sure how easy it would be to design and as you mentioned it as terrible design...I feel like I should look for some other approach. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 10, 2015 10:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Start by explaining what you really are trying to do. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 10, 2015 10:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pandeg wrote: |
| I feel like I should look for some other approach. |
You think? 
You either need to redesign the topology or, as my most worthy associate says, explain more clearly what's happening here? Is it actually the case that you have over 1000 separate and distinct local queues from which you must read messages and pass them to a common process (because you're reading them with a single process, they're all passed to a single process)? Because that's an insane and horrible design on a number of levels.
If instead you're simply trying to read 1000 messages as a block then that's still a stupid idea (why not one by one?) but that's achievable with an MQInput & Collector node combination.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pandeg |
| Posted: Fri Jul 10, 2015 11:07 am Post subject: |
|
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Vitor wrote: |
| pandeg wrote: |
| I feel like I should look for some other approach. |
You think?
You either need to redesign the topology or, as my most worthy associate says, explain more clearly what's happening here? Is it actually the case that you have over 1000 separate and distinct local queues from which you must read messages and pass them to a common process (because you're reading them with a single process, they're all passed to a single process)? Because that's an insane and horrible design on a number of levels.
If instead you're simply trying to read 1000 messages as a block then that's still a stupid idea (why not one by one?) but that's achievable with an MQInput & Collector node combination. |
So , here is the explanation -- We have around 1500 Apps which are putting message to their Alias Q which puts the message to Common Broker Input Q .MQInput Node get these messages and send to other different queues using MQOutNode and database lookup based on destination list. I am unable to find the curdepth for these application specific messages as there is no curdepth attribute for Alias Q and can't stop the flow without doing "Put" disable for Alias Q or stopping the Sending Application itself.I wanted to Create an additional Local Q for each application to hold their own messages so that I can check Q depth and using the message flow ,put those messages from each application to MQInput Node.Although, this will solve one part of the problem, I can still stop the message traffic by stopping the outgoing program of the app. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 10, 2015 11:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pandeg wrote: |
| I am unable to find the curdepth for these application specific messages as there is no curdepth attribute for Alias Q and can't stop the flow without doing "Put" disable for Alias Q or stopping the Sending Application itself. |
There is no requirement for a broker flow to know the current depth of any queue.
There is no requirement for any application to know the current depth of any queue.
Why do you think you need to know this?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pandeg |
| Posted: Fri Jul 10, 2015 12:02 pm Post subject: |
|
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Vitor wrote: |
| pandeg wrote: |
| I am unable to find the curdepth for these application specific messages as there is no curdepth attribute for Alias Q and can't stop the flow without doing "Put" disable for Alias Q or stopping the Sending Application itself. |
There is no requirement for a broker flow to know the current depth of any queue.
There is no requirement for any application to know the current depth of any queue.
Why do you think you need to know this? |
This is required for monitoring purpose in Production environment to identify the transfer rate and message volume over a certain interval. Also, If i there is any issue with specific message for any application, we can pop out that message only and the rest other messages can be flow from Common Broker Input Q |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 10, 2015 12:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pandeg wrote: |
| This is required for monitoring purpose in Production environment to identify the transfer rate and message volume over a certain interval. |
The MQInput node can tell you that using the inbuilt event monitoring.
| pandeg wrote: |
| Also, If i there is any issue with specific message for any application, we can pop out that message only and the rest other messages can be flow from Common Broker Input Q |
If there is any issue with specific message for any application, it should go into the back out queue that you've got defined for the input queue. Broker does this automatically, using the queue manager dead letter queue if you've not bothered to define a back out queue. If you've not bothered to define a dead letter queue either, you're in a trap of your own making and again need to review your MQ topology.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 10, 2015 10:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
 with Vitor. Excellent analysis! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| pandeg |
| Posted: Mon Jul 13, 2015 6:13 am Post subject: |
|
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Quote: |
The MQInput node can tell you that using the inbuilt event monitoring.
|
Can I find the count of application specific messages too based on applic ID if defined in Message header from Broker Input Q using MQInput Node, though it handles millions of messages per Mins. Also, would it be efficient to query for specific messages for particular application. |
|
| Back to top |
|
|
|
|
