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 » destination of messages in cluster transmit queue

Post new topic  Reply to topic
 destination of messages in cluster transmit queue « View previous topic :: View next topic » 
Author Message
vennela
PostPosted: Tue Feb 11, 2003 7:51 am    Post subject: destination of messages in cluster transmit queue Reply with quote

Jedi Knight

Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India

By the time a message reaches cluster transmit queue is it's destination determined?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
bduncan
PostPosted: Tue Feb 11, 2003 9:02 am    Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Yes. In fact, by the time a message reaches any transmission queue, an additional header (MQXQH) is appended which contains the routing information. See this link:
http://www-3.ibm.com/software/ts/mqseries/library/manuals/amqmak/AMQMAK0X.HTM
What's interesting is that you can write an application, which, if it creates the MQXQH object correctly, can put a message directly to a transmission queue, without having to first put to a remote queue definition...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
vennela
PostPosted: Tue Feb 11, 2003 9:16 am    Post subject: Reply with quote

Jedi Knight

Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India

Thanks Brandon:

If the messages(sitting on the transmitq) are destined to a specific QMGR and the QMGR goes down, how do I reroute the messages to another QMGR. Is there any utility or support pack available?

-------
Venny
Back to top
View user's profile Send private message Send e-mail Visit poster's website
nimconsult
PostPosted: Tue Feb 25, 2003 5:31 am    Post subject: Reply with quote

Master

Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium

Venny,

Did you finally get a response to your last question?

I am interested in the response too.

Thank you in advance,

Nicolas
_________________
Nicolas Maréchal
Senior Architect - Partner

NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be
Back to top
View user's profile Send private message Send e-mail Visit poster's website
bduncan
PostPosted: Tue Feb 25, 2003 1:09 pm    Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

From what I've been told (and read, but can't remember where!) the standard cluster workload exit doesn't do anything about messages already on the tranmission queue destined for some queue manager that is unavailable. However, I've heard about people writing custom workload exits that can reroute messages on the fly. I'll have to look into this more to give you a definite answer...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
nimconsult
PostPosted: Tue Feb 25, 2003 11:48 pm    Post subject: Reply with quote

Master

Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium

It would be nice if you or anyone else could provide an answer on this point.

Let me however tell you an experience that I have done yesterday afternoon.

(W2K, MQ5.2)
Create 3 queue managers: QM1, QM2, QM3.
Part of a cluster CLUS123.
Create LQ12 in QM1 and QM2, advertized in CLUS123.
A program connects to QM3, opens LQ12 with BIND_NOT_FIXED and fires messages at maximum speed.

When you look at the messages put on the transmission queue of QM3, there is indeed a transmission queue header in front of the message (MQXQH). However the queue manager name in this header is EMPTY!

Interesting experience 1:

I stop QM1 (immediate), and I see all messages routed to QM2.

I do not have the impression that some messages are stuck in the transmission queue, with a destination QM1.

Interesting experience 2:

(I posted big persistent messages, and because the 3 queue managers run on a single machine with a single disk, there is plenty of backlog on the transmission queue)

After some minutes, I am sure that all messages in the transmission queue were produced when QM1 was down.

I restart QM1.

I see the messages evenly distributed between QM1 and QM2 again. I really have the impression that the workload balancing is done AFTER the message is retrived from the transmission queue and not BEFORE.

I must admit that I only had 15 minutes to perform the test (I needed to answer a question quickly) and honnestly I am not 100% sure of my results.

Any feedback on comment on this experience?

Thank you in advance,
_________________
Nicolas Maréchal
Senior Architect - Partner

NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be
Back to top
View user's profile Send private message Send e-mail Visit poster's website
oz1ccg
PostPosted: Wed Feb 26, 2003 6:08 am    Post subject: Reply with quote

Yatiri

Joined: 10 Feb 2002
Posts: 628
Location: Denmark

Hi,

Up to BATCHSIZE messages might get stuck in the xmitq, if the connection is broken, due to UOW recovery. This can be caused by a network failure or a server kill......

Normally this situation is resolved when the cluster-qmgr that failed returns to work. But in some situations you might the have to manually do a resolve with BACKOUT or COMMIT.

Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
nimconsult
PostPosted: Wed Feb 26, 2003 11:51 pm    Post subject: Reply with quote

Master

Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium

Thank you for you answer, Jørgen.

For my education, what makes these rolled back messages different from the others? Why aren't they picked up and transmitted to another queue manager, just like all subsequent messages?

I have seen that the queue manager name is NOT written in the XQH, am I missing something?


Thank you in advance,
_________________
Nicolas Maréchal
Senior Architect - Partner

NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be
Back to top
View user's profile Send private message Send e-mail Visit poster's website
oz1ccg
PostPosted: Thu Feb 27, 2003 10:09 am    Post subject: Reply with quote

Yatiri

Joined: 10 Feb 2002
Posts: 628
Location: Denmark

Nicolas,

the way it works (to my knowledge), it's similar to a normal channel on this topic. Why they don't have a QMGR specified in the QXH ??, I supose that the channel does it in the same UOW as it send it, and therefore you will not be able to see any indoubt messages in the queue. The only was you will get an indication is by looking on queue depth.

As you know MQ will try to assure message delivery, and therefore will MQ not rey to send a message, that are in a undefined status (indoubt).

To clear this status the queue manager wille require that the partner come back in business..... Some time ago we had a similar debate here, where some automation was done, to get out of this situation, by forcing the failed channel to do backout.... But this requres that the receiving application ís able to deal with duplicate received messages.

Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT.
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
PeterPotkay
PostPosted: Thu Feb 27, 2003 10:31 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

When does Workload balancing occur?

The following is a quote from the handout for a session from the IBM Tech Conferance 2003 called M29 Administrating MQ Clusters. This is a new seesion and had some neat stuff as fasr as explaining what was going on underneath the covers.

Quote:

When does workload balancing occur?
In a typical setup, where a message is put to a queue manager in the cluster, destined for a backend
server queue manager also in the cluster, there are three places at which workload balancing may
occur.
The first of these is at either MQOPEN or MQPUT time depending on the bind options associated with
message affinity. If bind_on_open is specified, then this means all messages will go to the same
destination, so once the destination is chosen at MQOPEN time, no more workload balancing will
occur on the message. If bind_not_fixed is specified, the messages can be sent to any of the available
destinations. The decision where to send the message is made at MQPUT time, however this may
change whilst the message is in transit.
If a channel from a queue manager to a backend server goes into retry, then any bind_not_fixed
messages waiting to be sent down that channel will go through workload balancing again to see if there
is a different destination that is available.
Once a message is sent down a channel, at the far end the channel code issues an MQPUT to put the
message to the target queue. Once again, if the message is bind_not_fixed, the workload algorithm
will be called at MQPUT time. If you are using the internal workload algorithm, then that algorithm will
always pick the queue on the local queue manager, unless that queue has been put inhibited, so once
a message is sent down a channel to the backend server where the queue is local, the internal
workload balancing will not usually send it elsewhere. However if you decide to implement your own
workload balancing algorithm, then this is something you should take into consideration to avoid
messages looping around the network.


Here is some info on the actual algorithim:
Quote:

Cluster Workload Algorithm
The internal cluster workload algorithm is passed a list of instances of a cluster queue and a
corresponding list of channels to servers that host the cluster queue. It performs a set of tests on
each queue and channel pair to determine the best one to send the messages too. Each test is
assigned a weighting:- the higher the weighting, the more important the test is considered to be. If a
test is passed, its weighting is added to the overall weighting for the queue and channel pair.
Once each queue and channel pair has an overall weighting, the one with the highest weighting is
picked. If there is more than one with the same highest weighting, then a round-robin algorithm is
used to choose which one to send the message too.
You can implement your own workload exit to override the choice made by the internal workload
algorithm.



And here is the actual weightings:
Quote:

Test Weighting
Queue Put Enabled '01000000'x
Local Queue '00100000'x
Qmgr not suspended '00010000'x
Channel running/inactive '00004000'x
Channel starting '00003000'x
Channel retrying '00002000'x
Channel stopped '00001000'x
If > 1 destination with same highest overall
weighting then round-robin between them

_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bduncan
PostPosted: Thu Feb 27, 2003 1:35 pm    Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Right, that would agree with what I've experienced, because when I mentioned that the messages were NOT rerouted once they were already in the transmission queue, I was using bind on open rather than bind not fixed. Had I used the latter option, presumably the queue manager would have dynamically rerouted the messages already in the transmission queue...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » destination of messages in cluster transmit queue
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.