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 IndexClusteringSYSTEM.CLUSTER.XMIT.QUEUE a “single point of failure”?

Post new topicReply to topic
SYSTEM.CLUSTER.XMIT.QUEUE a “single point of failure”? View previous topic :: View next topic
Author Message
Jakob_CPH
PostPosted: Wed Apr 20, 2005 1:42 am Post subject: SYSTEM.CLUSTER.XMIT.QUEUE a “single point of failure”? Reply with quote

Apprentice

Joined: 28 Jan 2005
Posts: 26

I have a fundamental question regarding the SYSTEM.CLUSTER.XMIT.QUEUE. I see it as a single point of failure for MQ clustering.
If one receiver A is down and messages for that receiver are piling up and fill the cluster xmit queue then the mq clustering for that queue manager is stopped. No messages can be sent to any receiver via a cluster channel before the receiver A starts to receive messages again.
Of course we can ask receiver A to have two queue managers that can receive his messages but still there is a small possibility that both queue managers are down.

There is a max a page set on Z/OS is 4GB (in version 6 it is 64 GB) and therefore for a queue.

My question: Is the SYSTEM.CLUSTER.XMIT.QUEUE a “single point of failure” or is it possible to have more than one xmit queue for clustering on a queue manager?

Thanks
Jakob
Back to top
View user's profile Send private message
Michael Dag
PostPosted: Wed Apr 20, 2005 2:03 am Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

MQ Clustering is not meant to take care of high availability or avoid single point of failure in that sense. If there is something wrong with the Qmgr or box you need to look for hardware fail over.

from a clustering perspective if you have 2 routes to a destination and one is "down", the other route will be taken, messages already gone the first route can get "stuck".

there is only one system.cluster.xmit.queue

hope this helps.
_________________
Michael



MQSystems Facebook page
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Jakob_CPH
PostPosted: Wed Apr 20, 2005 2:32 am Post subject: Reply with quote

Apprentice

Joined: 28 Jan 2005
Posts: 26

I am using MQ clustering on a message broker and availability is very important for my customer.
Maybe I should use mq clustring for small messages and normal mq channels for very large messages.
If I compare MQ clustering with normal MQ distributing via normal channels and xmit queues I get the following picture:

MQ clustering
Pro: If there are multiple cluster queues in the cluster messages can be rerouted if the connection to one of the cluster queues goes down.
Con: There is only on xmit queue for each queue manager and it is a single point of failure.

Normal MQ distribution:
Pro: For each channel there is a separate xmit queue and other channels will not be influenced if on xmit queue is filled.
Con: There is no automatic reroute mechanism for messages stocked in a xmit where the channel is in “RETRY”.
Back to top
View user's profile Send private message
vennela
PostPosted: Wed Apr 20, 2005 5:59 am Post subject: Reply with quote

Jedi Knight

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

Quote:
Con: There is only on xmit queue for each queue manager and it is a single point of failure.

I don't understand what you mean when you say SCTQ is a single point of failure.

Quote:
If one receiver A is down and messages for that receiver are piling up and fill the cluster xmit queue then the mq clustering for that queue manager is stopped

Not true.

If that queue is hosted by some other QMGR, say receiver B, then the messages will be sent to that QMGR.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Jakob_CPH
PostPosted: Wed Apr 20, 2005 6:21 am Post subject: Reply with quote

Apprentice

Joined: 28 Jan 2005
Posts: 26

Thanks for your reply but I still STCQ is a weak point in MQ clustering.
Quote:

I don't understand what you mean when you say SCTQ is a single point of failure.


I mean that if SCTQ on qmgr A is full (failed) then no messages can be put to a cluster queue from A before SCTQ on A not is full anymore.


Quote:
Not true.

If that queue is hosted by some other QMGR, say receiver B, then the messages will be sent to that QMGR.[


If a queue Q1 is a cluster queue and hosted by qmgr A and B and both are down then messages for Q1 send from qmgr S is piling up in SCTQ on S. If the down time is long enough the SCTQ is eventually filled and no messages can be put to a cluster queue from S and clustering on S is stopped. Clustering will be down until A or B is up and receiving again.

Thanks
Back to top
View user's profile Send private message
Nigelg
PostPosted: Wed Apr 20, 2005 7:10 am Post subject: Reply with quote

Grand Master

Joined: 02 Aug 2004
Posts: 1046

You could set the MAXDEPTH of the cluster xmitq to 99999999. Of course, this is beyond the capacity of any queue to hold, because of other physical constraints, e.g. disk space, shared memory, etc. However, it should be possible for a queue to hold up to about 10 million msgs. Even putting those msgs at 300/second every second, a very respectable rate for persistent msgs, the queue will fill in about 30000 seconds, or 8 hours. That should give you plenty of time to fix the condition causing the problem.
In practice of course, msgs will not be enqueued at anywhere near that rate, so the time before failure would be much longer, long past the time that any reasonably well designed system would need to detect and fix the problem.
Back to top
View user's profile Send private message
Jakob_CPH
PostPosted: Wed Apr 20, 2005 7:47 am Post subject: Reply with quote

Apprentice

Joined: 28 Jan 2005
Posts: 26

Thanks for your reply
My platform is Z/OS and I use vers 5.3 which mean the max disk available for SCTQ is 4 GB. This means it can contain 40 100 MB messages. I know the page set size is increased to 64 GB in vers. 6.0 but still the SCTQ can in vers 6.0.not contain more than 640 100MB messages....
Back to top
View user's profile Send private message
Michael Dag
PostPosted: Wed Apr 20, 2005 8:07 am Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

Jakob_CPH wrote:
My platform is Z/OS

are there other platforms involved?

if not then you could try Queue sharing on 6.0 (up to 100mb messages)?
_________________
Michael



MQSystems Facebook page
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
PeterPotkay
PostPosted: Wed Apr 20, 2005 1:36 pm Post subject: Re: SYSTEM.CLUSTER.XMIT.QUEUE a “single point of failure”? Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Jakob_CPH wrote:

Of course we can ask receiver A to have two queue managers that can receive his messages but still there is a small possibility that both queue managers are down.


Then have receiever A have 3 QMs in the cluster. Or 4 QMs. Or...you get the picture. Its all about $$$$$$$$$. At the end of the day, realize no matter what you do or how much money youe spend, nothing will be 100% bulletproof. You can only hope for 99.9xxx%. How many nines you get is how many $$$ you spend.



I do like your line of thinking though. I never thought of that problem. It doesn't take very many big messages stuck in a SCTQ to fill it on z/OS. Hence have as many reecieving QMs as possible to avoid the problem. And monitor everything.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexClusteringSYSTEM.CLUSTER.XMIT.QUEUE a “single point of failure”?
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.