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 » Clustered queue as a subscription destination

Post new topic  Reply to topic Goto page Previous  1, 2
 Clustered queue as a subscription destination « View previous topic :: View next topic » 
Author Message
Adrien
PostPosted: Wed Dec 08, 2010 3:51 am    Post subject: Reply with quote

Novice

Joined: 23 Nov 2009
Posts: 14

Sorry for the very late reply... Below is what I did.

I have a cluster of queue manager A, B and C (+ the full repositories). There is a clustered (global) topic T. Queue manager A and B have each a queue definition Q which is clustered. There is also a cluster alias CA.

I defined the following subscription on queue manager A :
Code:
def sub dest(Q) destqmgr(CA) topicstr(T)


No subscription was defined on queue manager B.

My requirement is that when queue manager goes down, the publications from queue manager C will flow to queue manager B (because the destination of the subscription is clustered). But it is not what happens.
Instead, the subscription made on A is local to A and publication always go to A. If this QM is not available, the publications are not re-routed to the other instance of the same queue (on B for instance)... they simply wait on the publisher until A comes back. There is also no load balancing between the two instance of the destination when A and B are available.

My workaround at the moment is to define the subscription on the publisher. The destination resolution is done at the source and the messages are effectively load balanced. But it is not very clean, not manageable in the long term and not usable if there is more than one publisher for a topic.

Is it normal that it works this way ?
Is there another way to do it (like subscription grouping with a subscription on A and B) ?

Currently it is very disappointing because I cannot combine clustered load balancing with pub/sub. It works beautifully with queues though.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed Dec 08, 2010 4:01 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Define the subscription on qmgr C. Define it to point to a qcluster that lives on both qmgr A and qmgrB.

If qmgr C is down, then no publications are being made.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Dec 08, 2010 3:21 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

mqjeff wrote:
Define the subscription on qmgr C. Define it to point to a qcluster that lives on both qmgr A and qmgrB.

If qmgr C is down, then no publications are being made.

Dynamic subscriptions (even durable ones) do not allow you to specify a blank qmgr name for receiving the data. It gets filled in with the qmgr you are connected to. You can either make an administrative subscription, or you will need to specify a cluster alias as the qmgr for the cluster queue receiving the data.

This will mean that the messages published will be load balanced, and you should have no message affinity.

I have also found that this messes up somewhat the standard SYSTEM.JMS queue entries needed to receive messages to a topic, and it is then easier to read the messages from the destination queue than to try and use a topic. The message read will still display the topic in it's destination.

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Wed Dec 08, 2010 3:46 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

fjb_saper wrote:
mqjeff wrote:
Define the subscription on qmgr C. Define it to point to a qcluster that lives on both qmgr A and qmgrB.

If qmgr C is down, then no publications are being made.

Dynamic subscriptions (even durable ones) do not allow you to specify a blank qmgr name for receiving the data. It gets filled in with the qmgr you are connected to. You can either make an administrative subscription, or you will need to specify a cluster alias as the qmgr for the cluster queue receiving the data.


That may be true, but it has little to do with the issue of a subscription only being defined on a single qmgr.

I suppose one could also do things with v7 client channel reconnect stuff to reregister a programattic subscription when the connection is moved from qmgr a to qmgr b.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Dec 08, 2010 4:01 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

you had already nicely addressed the problem of the single failure on the publishing qmgr.

To have a fully load balanced system, you'd need your publishing qmgr load balanced as well. No need to cluster the topic. Define a local subscription on each of the publishing qmgrs ( local to avoid dups). That local subscription can be load balanced as to its destination as per my post above.

The other alternative is to have a clustered topic. But you need to make sure that the publications are global in their scope. The downside with the global subscription is that if the qmgr the subscription was made to goes down you have a single point of failure.

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Adrien
PostPosted: Wed Dec 08, 2010 4:05 pm    Post subject: Reply with quote

Novice

Joined: 23 Nov 2009
Posts: 14

mqjeff wrote:
Define the subscription on qmgr C. Define it to point to a qcluster that lives on both qmgr A and qmgrB.

If qmgr C is down, then no publications are being made.


Yes it is indeed a good workaround. But if you have multiple publishers for a topic all publications flows through QM C before reaching QM A or B. And the single point of failure reappears.

fjb_saper wrote:
mqjeff wrote:
Define the subscription on qmgr C. Define it to point to a qcluster that lives on both qmgr A and qmgrB.

If qmgr C is down, then no publications are being made.

Dynamic subscriptions (even durable ones) do not allow you to specify a blank qmgr name for receiving the data. It gets filled in with the qmgr you are connected to. You can either make an administrative subscription, or you will need to specify a cluster alias as the qmgr for the cluster queue receiving the data.

This will mean that the messages published will be load balanced, and you should have no message affinity.

I have also found that this messes up somewhat the standard SYSTEM.JMS queue entries needed to receive messages to a topic, and it is then easier to read the messages from the destination queue than to try and use a topic. The message read will still display the topic in it's destination.

Have fun


This is exactly what I don't understand ! I am making an administrative subscription with a cluster alias as the destination qmgr and the clustered queue name as the destination queue. Exactly what you're recommending... but the publisher doesn't care : it will always send the publication where the administrative subscription has been defined.

When examining the automatic proxy sub (which is propagated to the publishers) you clearly see that publications matching this proxy are directed to the system queue SYSTEM.INTER.QMGR.PUBS on the QM where the subscription has been defined, completely ignoring the fact that the destination is also existing on other qmgrs and that I specified a cluster alias in the destination qmgr.

I don't understand the behaviour difference between your setup and mine... but let me tell you that I appreciate a lot the time you take to help me ! Let's discuss a bit more and if we don't find a solution/explanation, I will ask for support to IBM.
Back to top
View user's profile Send private message
Adrien
PostPosted: Wed Dec 08, 2010 4:12 pm    Post subject: Reply with quote

Novice

Joined: 23 Nov 2009
Posts: 14

fjb_saper wrote:
you had already nicely addressed the problem of the single failure on the publishing qmgr.

To have a fully load balanced system, you'd need your publishing qmgr load balanced as well. No need to cluster the topic. Define a local subscription on each of the publishing qmgrs ( local to avoid dups). That local subscription can be load balanced as to its destination as per my post above.

The other alternative is to have a clustered topic. But you need to make sure that the publications are global in their scope. The downside with the global subscription is that if the qmgr the subscription was made to goes down you have a single point of failure.

Have fun



The solution to make the subscription on all the publishers with the scope to local to avoid duplicates is a good one. There is a little more administration since there is several publishers but it is good enough.

Edit : I suggested to have the subscription on two publishers only but then it would need to be a global one. And in that case I would get messages twice... bad idea
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » Clustering » Clustered queue as a subscription destination
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.