| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to control the target of the next batch of messages ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| KIT_INC |
 Posted: Thu Mar 21, 2013 5:49 pm Post subject: How to control the target of the next batch of messages ? |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
This is probably not the best use of cluster Workload balancing. Here is my requirement. I am running MQ V701 with 4 QMGRs ( 1 ZOS and 3 AIX). The MQPUT is from ZOS, the receivers are AIX QMGRs. The requirements is initially, we like any one of the 3 AIX QMGRs to handle to workload from ZOS. But once an AIX QMGR gets the work, the subsequent work needs to be sent to the same AIX QMGR.
I can put all 4 QMGRs in a cluster (QMZOS, QM1, QM2, QM3).
TQ is defined as cluster Q on QM1, QM2 and QM3.
QMZOS will MQOPEN TQ with bind_on_open. MQ cluster logic will select TQ on one of the AIX QMgrs and all the messages will be PUT to that Q because of the bind_on_open option. QMZOS will close the queue after doing the PUTs. A little while later QMZOS will MQOPEN TQ again for the next batch of messages. The requirement is that this second batch of messages must be handled by the same AIX QMGR that handles the first batch, Is there a way I can make sure that this next or subsequent MQOPEN will get to the same AIX QMGR selected last time ? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Mar 21, 2013 7:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Either get the resolved q name or keep the queue open between the 2 batches. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Thu Mar 21, 2013 7:21 pm Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
Thanks fjb_saper. We can not keep the queue open between batches. I was hoping that there is something in cluster logic which does not require us to change the application.
We have to put in an application change request asking the application to remember the resolved q name.
I am reading the info center which says
"Resolved queue manager name
When a queue manager name is resolved at MQOPEN time, the resolved name is returned to the application. If the application tries to use this name on a subsequent MQOPEN call, it might find that it is not authorized to access the name."
This looks like the QMGR name is what we need to save. I am just confused on what it says about "If the application tries to use this name on a subsequent MQOPEN call, it might find that it is not authorized to access the name."
Can you help on what it means by not authorised to access the name ? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 21, 2013 7:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If the application has put access to the SYSTEM.CLUSTER.TRANSMIT.QUEUE I would not worry too much. For other options read up on CLUSTER security in the latest infocenter.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 21, 2013 8:21 pm Post subject: Re: How to control the target of the next batch of messages |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| KIT_INC wrote: |
| Is there a way I can make sure that this next or subsequent MQOPEN will get to the same AIX QMGR selected last time ? |
Yes, and no. The 'no' has to do with the destination qmgr not being available (shut down, channel failure, etc.) at the subsequent MQOPEN.
At MQOPEN of a cluster queue, the qname/qmgrname returned to the MQOD are those selected by the qmgr from queue definitions in the repository (or cluster workload exit). As suggested by my worthy colleague, at the first successful MQOPEN, the application will need to retain the qmgr name to use at the next MQOPEN attempt.
From the APR manual:
| Quote: |
v If ObjectName is the name of a cluster queue, and ObjectQMgrName is blank, the destination of messages sent using the queue handle returned by the MQOPEN call is chosen by the queue manager (or cluster workload exit, if one is installed) as follows:
– If MQOO_BIND_ON_OPEN is specified, the queue manager selects a
particular instance of the cluster queue while processing the MQOPEN call,
and all messages put using this queue handle are sent to that instance.
– If MQOO_BIND_NOT_FIXED is specified, the queue manager can choose a
different instance of the destination queue (residing on a different queue
manager in the cluster) for each successive MQPUT call that uses this queue
handle.
If the application needs to send a message to a specific instance of a cluster queue (that is, a queue instance that resides on a particular queue manager in the cluster), the application must specify the name of that queue manager in the ObjectQMgrName field. This forces the local queue manager to send the message to the specified destination queue manager. |
If memory serves, the last sentence in bold above is telling you that if the app specifies qmgrname in the MQOD, there will also be a security check on the qmgrname.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Thu Mar 21, 2013 11:09 pm Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Thanks for the clarification |
|
| 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
|
|
|
|
