Changing the cluster-connection on JBoss

[bjchip]

When it was discovered that we had a problem with UDP connectivity I attempted to change the cluster connection settings to avoid the discovery groups (as it needs specific connections over TCP to get where it needs to go).

The applications had already been deployed and the queues and topics established. I have had the system set up to do a cluster by default, but it has never (due to the UDP problem) been connected.

I reckoned the discovery groups and broadcast groups were no longer relevant, as they use UDP but leaving them in.

Changing the cluster connection however, led to problems connecting to existing queues and topics.  Putting a netty connector in place of the DG should not cause breakage as it is the connector the DG would hand over anyway.  Nope. 

?This changes the cluster definition (if thinking in terms of JBoss).  It is a "different" partition?

So when I start with the DG in place it is fine.  Just works.

However, if I substitute the netty-10_1_2_3 connector or the netty connector (per the information in section 38.5.2)  for the discover-group-ref, it goes belly up looking for queues which have been made unique.   Queues with a hash appended  IE    jms.queue.Q.WEB2WAS.PS2INPUTd871552-3252-11dj-a8ba-005040b52.

The applications (or something) can't connect to queues they THOUGHT they had.

The DG syntax continues to work locally despite the lack of UDP.  It is of course available internally on the machine, just broken across the net.

Why won't it build new queues and use them.   What is looking for these specific queues?  

I don't mind trashing the development journals etc, and starting fresh, (we are still testing) but whatever is looking for these appears to think they can't be changed.

As there are a number of firewalls to traverse it will be a little while before files that are relevant are available -

BJ

[bjchip]

At the moment this appears to be an artifact of the not-successfully-clustered jboss being connected through the DB connections and there being junk in the DB from the other server.  Maybe.  I am waiting on further results.

The owner of the network says no problem with UDP, but no hornetq standalone discovery, no jboss discovery and as soon as TCP is configured I have a cluster.   Have to hope I have the internal configs right.  Never did that before.

At least being inside JBoss I don't have to worry about JNDI.... :-) 

Still not sure what will happen when I alter the configs to try to get it to go live-backup in those two environments.

Have to say thanks to all who have helped here.  This is a good community.    inside

[bjchip]

Nope -  I was wrong, it was not an artifact. 

Basically what it is, is that if you've created the cluster and defined it and started it, you cannot then change its composition but retain its name. 

That is, you can't go from a discovery group to a statically defined set of the same servers... or vice-versa.

You have to create a NEW cluster with the composition you want.    New name.  No problem.

You can't re-use the olde name.   The specific queues created are hashed with the cluster definition in some way and then can no longer be used, retrieved, connected....   broken big-time.

respectfully

BJ

[timfox]

This is not quite true.

When you create a cluster, the system forms various "store and forward" queues between the nodes of the cluster. These are where messages are put prior to forwarding them from one node to another.

They are necessary, so the messages can be put somewhere if, for example, the target node is temporarily down. When the target node becomes available again the message can be forwarded with no loss of messages.

If you remove your cluster definition from your config, those store and forward queues will remain. The system can't just delete them, they might contain messages, and it doesn't know you don't want that cluster any more. E.g. you might have just temporarily commented it out in your config.

If you really don't want that cluster any more. You can just delete those queues, just like any other queue (they're just normal queues) via the management api, i.e. programmatically, or using a jmx-client e.g. jconsole. Or using the management console (in the next release).

[bjchip]

Thanks.

So I can re-use the name if I am happy to delete the queues.    That's good, because I didn't know what they were and that  I was allowed to delete them. 

Changing the composition of the cluster just leaves things dangling though, which is as true with your description as mine. 

With what you say, it seems to me that it is  best to delete all such queues before creating any  new cluster, because they are going to be more esasily identifiable in the jms console if you haven't created a bunch of new ones (which will have different hash "tails").

Is there any manual way to simply wipe out all of it and start fresh?  I tried wiping the data and binding directories but it did not seem to matter.

BJ