How do I limit a jms queue's visibility to only nodes in a cluster?

[robert.greene]

How do I limit a JMS queue's visibility to only nodes in a cluster?

Our application is deployed and installed by the customer; the names of the clusters (partitions) are defined by the customer.

Given n clusters with different names and queue's with the same name, how do I prevent HornetQ discovery and joining of the JMS queues defined in each cluster?

I don't want to have to name the queue's uniquely in each cluster, (But I want the queues to be shared by each node in a unique cluster). I don’t want to have to perform network configuration to prevent multi-cast etc, because that would require extensive network configuration by the customer.

I don't want to have to use selectors. I don’t want any JMS communication between the clusters at all.

I don't want to have to statically identity the nodes in the cluster.

What I really want is the HornetQ discovery process to limit itself to the set of cluster names. (In my case one cluster name, the cluster that each node is a part of)

Is this difficult? I have looked for something like this in the HornetQ documentation and considered something like the following:

   <cluster-connections>

      <cluster-connection name="my-cluster">

         <address>jms.queue.${jboss.partition.name}</address>    

         <connector-ref>netty</connector-ref>

          <discovery-group-ref discovery-group-name="dg-group1"/>

      </cluster-connection>

   </cluster-connections>

And naming the queue's dynamically.

This seems very crude, and client applications will have to connect and aquire the cluster name before connecting to the queue's.

Is this the best I can do?

[ataylor]

you dont need to isolate your queues just make sure each cluster is isolated by broadcasting/discovering on different ports

[robert.greene]

But that means that the customer has to configure a port for every cluster, that is far from ideal.

[ataylor]

But that means that the customer has to configure a port for every cluster, that is far from ideal.

If you have 2 clusters on the same network using the same ports for brodcast/discovery then you dont have 2 clusters you have 1, every node from cluster A would be connected to every node in cluster B regardless of what queues are visible where. Having this topology and trying to have clients pick out certain nodes is actually what makes no sense.

You need to isolate the clusters from one another either by changing the ports or by isolating them using hardware, this would be no different with any clustered technology.

[robert.greene]

Why is there a

HORNETQ-316 Make cluster discovery pluggable

I realize that the original situation is different, but it is stated in the posts that there will be a reference implementation for a Jgroups discovery method.

Not sure that this would solve my issue or not.

[ataylor]

That JIRA has nothing to do with this post, its about using different ways to discover nodes in a cluster.

to be honest there is no issue here, like i say it makes no sense to have multiple clusters on a network all talking to each other, just isolate them the way i described! Unless the customer has a reason for having one huge cluster?

[robert.greene]

I understand what you are saying, and what you are suggesting is both reasonable and understandable, especially from a NOC perspective.

However, we distribute our application on pre-configured servers. Each server has a UI allowing some minimal JBoss configuration necessary for the application, and every configuration item provides another way that the customer can incorrectly configure the Server/Node/Cluster.

Typically our customers range from very knowledgeable to extremely unsophisticated users. I was just looking for a way for the HornetQ to "follow" the JBoss Partition.

I realize that what I am asking for is restrictive, and perhaps unusual, but it would help my situation.

I guess limiting JMS queue’s to a cluster without network or HornetQ configuration is an anti-pattern.

[ataylor]

Funnily enough I think thats a common practice, when I worked in Industry we did something very similar. We found that as long as your UI explains what the user needed to do in very simple terms we didnt have to many issues, so in your case if they needed to change the discovery/broadcast or port so we would do something like:

Please enter an address to use for the cluster, values between 231.7.7.7 and 231.9.9.9 are valid, note that this address must be unique for each cluster on your network.

saying that, I understand why you want to limit how much a customer can configure, we had many cases where simple instructions went awry, It was at this point we sold them consultency .

Regarding partition naming, this could be something we could add, but differently to Jboss this would completely isolate the cluster, feel free to raise a jira and we could investigate.

[robert.greene]

If I can describe the situation succinctly in a JIRA I will.

Thank you very much for your help. I appreciate your patience.

[ataylor]

once you have raised it I will assign it to myself and comment.

alternatively, it should be quite simple to implement if you wanted to do it yourselves, you could patch the version of HornetQ you are using and ship that. we could then apply the patch upstream