Author |
Message
|
samsansam |
Posted: Sat Aug 13, 2016 12:16 pm Post subject: Send messages to two full repository |
|
|
Apprentice
Joined: 19 Mar 2014 Posts: 41
|
I have MQ cluster with MQ 8.0.0.5 on Linux as following :-
QMGR.A is full repository
QMGR.B is full repository
QMGR.C is partial repository , it has cluster queue called (CB.LOCAL)
QMGR.B is partial repository , it has cluster queue called (CB.LOCAL)
QMGR.Y is outside the cluster
Now , to send message to one of the partial QMGR from QMGR.Y, I have conferred the following :-
on QMGR.Y
sender channel :
def chl (Y.TO.CLUS) chltype (sdr) conname (the share host name for both full repository) xmitq (A.XMITQ)
Trans Queue :
def ql (A.XMITQ) usage (xmitq)
Remote Queue :
def qr (CLUS.REMOTE) RNAME (CB.LOCAL) RQMNAME (QMGR.A) xmitq (A.XMITQ)
It works fine , and the message are going to both partial using the full repository QMGR.A.
My question, is there a way to make the messages go to full repository QMGR.B automatically if full repository QMGR.A goes down.
I tried to configured the remote queue as following :-
Remote Queue :
def qr (CLUS.REMOTE) RNAME (CB.LOCAL) RQMNAME (‘QMGR*’) xmitq (A.XMITQ)
but it did not work , I was not able to put messages. I did some reachers but I am sill having hard time with it. Any help or advice please. |
|
Back to top |
|
 |
PaulClarke |
Posted: Sat Aug 13, 2016 1:42 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Have you given us all the information. Do you have two clusters and you are trying to join them together in some way ? Your note to me reads like you just have a single cluster. If that is the case why are creating any sender channels, transmission queues or remote queue definitions......just let the cluster itself do it.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Aug 13, 2016 2:05 pm Post subject: Re: Send messages to two full repository |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
samsansam wrote: |
My question, is there a way to make the messages go to full repository QMGR.B automatically if full repository QMGR.A goes down. |
Unless I've misunderstood your hypothetical...
Not automatically, no. If the message comes from a non-cluster qmgr over sdr/rcvr channels to cluster QMGR.A, andQMGR.A goes dead, the message will sit in the xmit queue at the sending side of the non-cluster qmgr until QMGR.A comes back to life. _________________ 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 |
|
 |
samsansam |
Posted: Sat Aug 13, 2016 8:03 pm Post subject: |
|
|
Apprentice
Joined: 19 Mar 2014 Posts: 41
|
PaulClarke,
Thank you for respond, I am trying to send a message from Non-Cluster Queue Manager to Cluster Queue Managers. It is single cluster , but QMGR.Y is not part of the cluster. Thats why I need the SDR and RCVR channels.
bruce2359
Thank you for respond, I guess you did understand. I was wondering if there is a way to have another sender channel (pointing to QMGR.B) start automatically if the sender channel (pointing to QMGR.A) goes retrying. |
|
Back to top |
|
 |
PaulClarke |
Posted: Sat Aug 13, 2016 8:57 pm Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
Ah ok, sorry for some reason I missed that crucial line.
The essential answer is 'no'. You can't have an 'alternate' channel start automatically if another channel ends. It has been discussed as a requirement a few times in MQ's history but it never made the cut. To some extent, of course, this is exactly what clusters give you so and that always seemed to be good enough. If you really really wanted to do this then you could potentially write an event monitor which monitored the channel stop events and started the 'other' channel but it is awkward.
However, in your case is there a good reason why you could not just put QMGR.Y in the cluster ? Usually in this case the customer says that they don't want QMGR.Y to have access to all the QMs in that cluster. If that is the case could you not just have another cluster purely for QMGR.Y and the FRs ? Bear in mind that a Queue Manager can be in lots of clusters so having two overlapping clusters is no problem.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
samsansam |
Posted: Sat Aug 13, 2016 9:29 pm Post subject: |
|
|
Apprentice
Joined: 19 Mar 2014 Posts: 41
|
There is no really reason for adding QMGR.Y to the cluster , I just want to avoid adding it for some security reason. Looks like that adding it to the cluster is the only option I have. Thank you for your time |
|
Back to top |
|
 |
samsansam |
Posted: Sat Aug 13, 2016 9:31 pm Post subject: |
|
|
Apprentice
Joined: 19 Mar 2014 Posts: 41
|
Sorry , I meant There is no really reason for NOT adding QMGR.Y to the cluster |
|
Back to top |
|
 |
PeterPotkay |
Posted: Sun Aug 14, 2016 2:29 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
In your topology, QMgr.A is the Gateway Queue Manager into your cluster for traffic originating from queue managers that are not in the cluster.
You need to make this single point of failure (the gateway queue manager) as highly available as possible. Typically that means running this queue manager under some solution that attempts to eliminate points of failure due to the underlying server. So you end up doing a Multi Instance QM, or Veritas Cluster, or MSCS, or HCAMP, or an H.A. Group on a pair of MQ Appliances.
Some will say that making QMgr.A a mainframe QM is H.A. enough (mainframe never goes down, right?)
Some will say making QMgr.A a QM on a virtual server with the highest level of service your virtual environment provides is H.A. enough.
Alternatively you can eliminate the need for the gateway by doing what others have suggested (put QMgr.Y into the cluster). _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
samsansam |
Posted: Mon Aug 15, 2016 6:33 am Post subject: |
|
|
Apprentice
Joined: 19 Mar 2014 Posts: 41
|
Thank you PeterPotkay for responding , looks like I will change the QMGR.A to Multi Instance.. The customer did not like the idea for adding QMGR.Y to the cluster.
Thank you all again |
|
Back to top |
|
 |
|