| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Multiple XmitQs with Same sender and Receiver |
« View previous topic :: View next topic » |
| Author |
Message
|
| pandeg |
 Posted: Thu Aug 13, 2015 7:54 am Post subject: Multiple XmitQs with Same sender and Receiver |
 |
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Hi, I have a requirement to create multiple XmitQ for checking Queue depth. I want to know if i can use same sender and receiver channel for all these multiple XmitQs. Will it affect the traffic flow from these XmitQs which are using to send messages from different application through Remote Q. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Aug 13, 2015 8:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Is your requirement to create multiple xmitqs?
Or is your requirement to improve the performance of the communication between two queue managers?
Is your requirement to prioritize traffic from some applications over others?
The only type of channel that can share an XMITQ is a cluster channel. every other MCA opens the XMITQ with exclusive access.
So, no, you can't use the same sender channel with more than one xmitq nor more than one send with the same xmitq. |
|
| Back to top |
|
|
| pandeg |
| Posted: Thu Aug 13, 2015 8:16 am Post subject: |
|
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Quote: |
Or is your requirement to improve the performance of the communication between two queue managers?
Is your requirement to prioritize traffic from some applications over others? |
My Requirement for Multiple XmitQs is to check the curdepth and browse and clear messages for sending applications. Since we have so many applications with their own dedicated Queues...I will have to create separate sender and receiver channel for each of them. That's why i though if i can use the same sender and receiver with Multiple XmitQs |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 13, 2015 8:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| pandeg wrote: |
| Quote: |
Or is your requirement to improve the performance of the communication between two queue managers?
Is your requirement to prioritize traffic from some applications over others? |
My Requirement for Multiple XmitQs is to check the curdepth and browse and clear messages for sending applications. Since we have so many applications with their own dedicated Queues...I will have to create separate sender and receiver channel for each of them. That's why i though if i can use the same sender and receiver with Multiple XmitQs |
No.
That's not your requirement.
XMITqs don't have anything to do with checking the current depth of a queue, nor of browsing and clearing messages.
Applications that have their own dedicated queue is perfectly normal for MQ.
There are only a very few good reasons for creating more than one sender/receiver pair (and thus one xmitq) between any two queue managers. Nothing you have said points to any of those good reasons.
Rather than repeating what your requirement is, please tell us what the problem you are trying to solve is. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 13, 2015 8:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| pandeg wrote: |
| Quote: |
Or is your requirement to improve the performance of the communication between two queue managers?
Is your requirement to prioritize traffic from some applications over others? |
My Requirement for Multiple XmitQs is to check the curdepth and browse and clear messages for sending applications. Since we have so many applications with their own dedicated Queues...I will have to create separate sender and receiver channel for each of them. That's why i though if i can use the same sender and receiver with Multiple XmitQs |
No.
That's not your requirement.
XMITqs don't have anything to do with checking the current depth of a queue, nor of browsing and clearing messages.
Applications that have their own dedicated queue is perfectly normal for MQ.
There are only a very few good reasons for creating more than one sender/receiver pair (and thus one xmitq) between any two queue managers. Nothing you have said points to any of those good reasons.
Rather than repeating what your requirement is, please tell us what the problem you are trying to solve is. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pandeg |
| Posted: Thu Aug 13, 2015 11:20 am Post subject: |
|
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Quote: |
There are only a very few good reasons for creating more than one sender/receiver pair (and thus one xmitq) between any two queue managers. Nothing you have said points to any of those good reasons.
Rather than repeating what your requirement is, please tell us what the problem you are trying to solve is. |
This is related to the question I posted previously(http://www.mqseries.net/phpBB2/viewtopic.php?t=70546&postdays=0&postorder=asc&start=15). Since , we have lot many applications, which are connecting to same local Broker input queue through their own Alias queue.I want to find the curdepth specific to each application, and clear one or all messages in production environment where millions of messages transferred through broker common input queue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 13, 2015 11:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pandeg wrote: |
| Quote: |
There are only a very few good reasons for creating more than one sender/receiver pair (and thus one xmitq) between any two queue managers. Nothing you have said points to any of those good reasons.
Rather than repeating what your requirement is, please tell us what the problem you are trying to solve is. |
This is related to the question I posted previously(http://www.mqseries.net/phpBB2/viewtopic.php?t=70546&postdays=0&postorder=asc&start=15). Since , we have lot many applications, which are connecting to same local Broker input queue through their own Alias queue.I want to find the curdepth specific to each application, and clear one or all messages in production environment where millions of messages transferred through broker common input queue. |
And given that topology that you described in that post, how exactly did you decide that xmitqs had any role to play? Do all of the 1500 applications that are putting to the alias queues that resolve to the local queue all use queue manager to queue manager connections? If so, how did you determine that you could make things better by creating multiple xmitqs between the two end points? If, as is more likely, all the applications establish a client connection to the queue manager and put to their alias, where do you think there's a single xmitq? That you could then duplicate?
Explain your topology again. Where do you have a sender and receiver channel between, and where are these applications connected?
Also explain how, assuming you can do what you're asking to do, you would use this to solve your problem.
Note for new readers: the previous post described the throughput as "millions of messages per minute". It's been previously pointed out that, at those speeds, any "curdepth" value will be almost instantly historic and monitoring should be performed with broker resource & event messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pandeg |
| Posted: Thu Aug 13, 2015 12:17 pm Post subject: |
|
|
Disciple
Joined: 21 Oct 2014
Posts: 195
|
| Quote: |
| And given that topology that you described in that post, how exactly did you decide that xmitqs had any role to play? |
XmitQ will be used to troubleshoot in case of any issue and to hold the message if not being received by local broker input queue or sender channel is down. Also , it can be used for draining the message for particular application. Currenlty, All applications are sending the message through aliasQ which don't have "curdepth" feature.
| Quote: |
| Do all of the 1500 applications that are putting to the alias queues that resolve to the local queue all use queue manager to queue manager connections? |
all these 1500 aliasQ's resolve to common broker input Q in Broker Queue Manager. Applications are directly connecting to Broker Queue Manager.
| Quote: |
| If so, how did you determine that you could make things better by creating multiple xmitqs between the two end points? If, as is more likely, all the applications establish a client connection to the queue manager and put to their alias, where do you think there's a single xmitq? That you could then duplicate? |
for Outgoing messages from Application, I am interested to see the "curdepth" to find how many messages are processed by each application, that can be done by using XmitQ. I thought to create local Queue for each application , but then how the message is transferred to Broker Input Queue for processing. Also, If i want to stop the flow to process message for particular application, i can do that using separate sender and receiver channel and message will be hold by XmitQ instead of asking application team to re-trigger the message.
| Quote: |
| Explain your topology again. Where do you have a sender and receiver channel between, and where are these applications connected? |
These sender and Receiver will be created in intermediate Queue Manager which will connect to Broker Queue Manager and will have all the application related queues and their dedicated sender and receiver channel. Broker Input Q and Output Q(for inbound messages) will be there in Broker Queue Manager. All applications will be connected to this intermediate queue manager using Server connection channel and Remote Queue( currently alias Q as they are connecting directly to Broker Queue Manager)
| Quote: |
| Also explain how, assuming you can do what you're asking to do, you would use this to solve your problem. |
I am thinking , what if i can use single sender and receiver channel for all those multiple XmitQ just to avoid creating these many sender and receiver channel for maintenance overhead. I am not sure , whether it is good design specially in term of performance , I am open for any other best solution. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 14, 2015 4:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pandeg wrote: |
| XmitQ will be used to troubleshoot in case of any issue and to hold the message if not being received by local broker input queue or sender channel is down. |
What "sender channel"? Where's that?
| pandeg wrote: |
| Also , it can be used for draining the message for particular application. |
No it can't. That's not what an xmitq holds.
| pandeg wrote: |
| Currenlty, All applications are sending the message through aliasQ which don't have "curdepth" feature. |
Yes, and...
| pandeg wrote: |
| Applications are directly connecting to Broker Queue Manager. |
So there's no sender channels anywhere in this topology, and therefore no xmitqs.
So again I ask:
| Vitor wrote: |
| how exactly did you decide that xmitqs had any role to play? |
There's only 1 queue manager in your topology. No xmitqs.
| pandeg wrote: |
| or Outgoing messages from Application, I am interested to see the "curdepth" to find how many messages are processed by each application, that can be done by using XmitQ. |
No it's can't. Again, that's not what an xmitq holds or how it's used. You really, really need to review the MQ basics if you think anything different.
| pandeg wrote: |
| I thought to create local Queue for each application , but then how the message is transferred to Broker Input Queue for processing. |
It's not. You need the broker to process each of the queues; the discussion on your previous post refers.
| pandeg wrote: |
| Also, If i want to stop the flow to process message for particular application, i can do that using separate sender and receiver channel and message will be hold by XmitQ instead of asking application team to re-trigger the message. |
And suddenly you're talking like you're using multiple queue managers again. Because....
| pandeg wrote: |
| These sender and Receiver will be created in intermediate Queue Manager which will connect to Broker Queue Manager and will have all the application related queues and their dedicated sender and receiver channel. Broker Input Q and Output Q(for inbound messages) will be there in Broker Queue Manager. All applications will be connected to this intermediate queue manager using Server connection channel and Remote Queue( currently alias Q as they are connecting directly to Broker Queue Manager) |
...and bang! There's the new queue manager. Why didn't you start this post with "I'm planning to change the topology"? 
So rather than changing the 1500 alias queues to 1500 local queues, you're planning to create a new queue manager and define 1500 remote queues? This you see as more efficient?
Circling back to your original question, you can't use multiple xmitqs on a single channel because they're not intended to be used the way you're trying to use them. In addition to 1500 remote queues, you'll need 1500 xmitqs on the new queue manager, being serviced by 1500 sender channels, and 1500 receiver channels on the broker queue manager.
| pandeg wrote: |
| I am thinking , what if i can use single sender and receiver channel for all those multiple XmitQ just to avoid creating these many sender and receiver channel for maintenance overhead. |
I'm not sure "thinking" is what you're doing. Even if this plan would work (which it won't), you still have the additional maintenance overhead of a new queue manager and 3000 new queues (1 qremote and 1 xmitq per application).
| pandeg wrote: |
| I am not sure , whether it is good design specially in term of performance |
Well aside from the fact it won't work it's a good plan. 
| pandeg wrote: |
| I am open for any other best solution. |
Aside from the best solution you were given in your other thread? No, nothing else springs to mind.....
_________________
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
|
|
|
|
