ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Configuring workload balancing from outside a cluster

Post new topic  Reply to topic
 Configuring workload balancing from outside a cluster « View previous topic :: View next topic » 
Author Message
MQMB&WAS
PostPosted: Thu Aug 13, 2020 10:54 am    Post subject: Configuring workload balancing from outside a cluster Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

Hello experts,

I'm trying to understand the usage of qmgr alias definition in the below example from IBM docs.

https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.con.doc/q017640_.htm


what is the purpose of using qmgr alias in the above case?


without the qmgr alias def on QM1 and with qremote def "DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM1) XMITQ(QM1)" on QM1, why doesn't the routing work? I tried this but the messages are landing in the DLQ of QM1. Could someone explain this please?

Appreciate your time.
"
Back to top
View user's profile Send private message
exerk
PostPosted: Thu Aug 13, 2020 12:18 pm    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

I think there's a 'typo' in that diagram, and for the life of me why couldn't they have QM1 as the external-to-the-cluster-queue-manager, QM2 as the gateway, and QM3 and QM4 as the cluster-queue hosts in the cluster - it would be far less confusing and easier to follow.

I would expect that where it says "Create a queue-manager alias Q3 on QM3.", that queue-manager alias should be in QM1. I'm happy to be corrected but I'm damn sure it's incorrect as logically, how the hell would QM3 know about a cluster it's not in?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
MQMB&WAS
PostPosted: Thu Aug 13, 2020 5:21 pm    Post subject: Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

exerk wrote:
I think there's a 'typo' in that diagram, and for the life of me why couldn't they have QM1 as the external-to-the-cluster-queue-manager, QM2 as the gateway, and QM3 and QM4 as the cluster-queue hosts in the cluster - it would be far less confusing and easier to follow.

I would expect that where it says "Create a queue-manager alias Q3 on QM3.", that queue-manager alias should be in QM1. I'm happy to be corrected but I'm damn sure it's incorrect as logically, how the hell would QM3 know about a cluster it's not in?


Lol I didn't realise this typo until you pointed out here.

I treid the setup with qmgr alias def on the gateway qmgr QM1 and the setup worked.

My question is, why is this qmgr alias on gateway qmgr needed? Why doesn't a qremote def " "DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM1) XMITQ(QM1)" on QM1 work?
Back to top
View user's profile Send private message
exerk
PostPosted: Fri Aug 14, 2020 1:26 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

MQMB&WAS wrote:
...Why doesn't a qremote def " "DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM1) XMITQ(QM1)" on QM1 work?

Let's break this down logically:

    QREMOTE(Q2) RNAME(Q2) which is a remote definition of the 'target' queue you want messages to go to on a remote queue manager...

    RQMNAME(QM1) which is the same queue manager on which you're defining the QREMOTE...

    XMITQ(QM1) using a transmission queue to itself...

And you wonder why it doesn't work?

The alias is required because of the need to resolve the intended target for the messages:

    DEFINE QREMOTE(Q2) RNAME(Q2) which is the name of the 'target' queue you want messages to go to, on a queue manager (or queue managers) somewhere...

    RQMNAME(Q3) that queue manager being Q3...

    XMITQ(QM1) via the connection to an entity known as QM1


And when it gets to QM1, the following occurs:

    QREMOTE(Q3) is an object within QM1, which QM1 'interrogates' the attributes of...

    RNAME(' ') RQMNAME(' ') and 'sees' that these value are blank and therefore deduces that the QREMOTE definition is in fact an alias so 'looks' in the message header for the RNAME value, which in this case can be resolved in the cluster...

Try dropping the alias to DEFINE QREMOTE(Q3) RNAME(' ') RQMNAME(' ') CLUSTER(' ') DEFBIND(OPEN) and see what happens.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
MQMB&WAS
PostPosted: Sun Aug 16, 2020 5:26 pm    Post subject: Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

I'm sorry, there was a typo in my question. I meant to say
"without the qmgr alias def on QM1 and with qremote def "DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM1) XMITQ(QM1)" on QM3, why doesn't the routing work? I tried this but the messages are landing in the DLQ of QM1. Could someone explain this please?
"
Back to top
View user's profile Send private message
hughson
PostPosted: Sun Aug 16, 2020 8:03 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

MQMB&WAS wrote:
I'm sorry, there was a typo in my question. I meant to say
"without the qmgr alias def on QM1 and with qremote def "DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM1) XMITQ(QM1)" on QM3, why doesn't the routing work? I tried this but the messages are landing in the DLQ of QM1. Could someone explain this please?
"

You have explicitly told it to use qmgr QM1 in the above definition.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
MQMB&WAS
PostPosted: Sun Aug 16, 2020 10:38 pm    Post subject: Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

hughson wrote:
MQMB&WAS wrote:
I'm sorry, there was a typo in my question. I meant to say
"without the qmgr alias def on QM1 and with qremote def "DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM1) XMITQ(QM1)" on QM3, why doesn't the routing work? I tried this but the messages are landing in the DLQ of QM1. Could someone explain this please?
"

You have explicitly told it to use qmgr QM1 in the above definition.

Cheers,
Morag



that means it will look for a local definition of Q2 on QM1??
Q2 (which is on QM2 & QM4) is a cluster queue and is advertised to QM1 as well. Don't the messages get routed to the local queue on QM2/QM4 ??
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Aug 17, 2020 4:41 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

MQMB&WAS wrote:
that means it will look for a local definition of Q2 on QM1??
Q2 (which is on QM2 & QM4) is a cluster queue and is advertised to QM1 as
well. Don't the messages get routed to the local queue on QM2/QM4 ??


No, it means it will put the messages on the transmission queue that points to QM1, as instructed by the XMITQ parameter of your command. Thus the messages are delivered to QM1, which will dead letter anything not addressed to it.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Aug 17, 2020 11:10 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Vitor wrote:
...Thus the messages are delivered to QM1, which will dead letter anything not addressed to it.

Or explicitly addressed to a queue object that does not exist within it...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Aug 17, 2020 12:59 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

exerk wrote:
Vitor wrote:
...Thus the messages are delivered to QM1, which will dead letter anything not addressed to it.

Or explicitly addressed to a queue object that does not exist within it...



_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
MQMB&WAS
PostPosted: Mon Aug 17, 2020 4:12 pm    Post subject: Reply with quote

Centurion

Joined: 12 Jun 2016
Posts: 130

Thank you all for your time.

So with this setup, if all the qmgrs involved are on linear logging, and If I want trace a message, on what qmgr are the messages logged? only at the destination qmgr ? or at every qmgr involved in the flow?
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Aug 17, 2020 5:17 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

A persistent message is written to the log on each/every qmgr where it is MQGET and MQPUT, by an app or qmgr component (like a channel end).
_________________
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » Configuring workload balancing from outside a cluster
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.