Other question occurs. If failover is not defined for a CLUSTER that is statically defined, what happens to an HA pair? Seems to me this is entirely different and ought to work. A little reassurance on this point would not go astray. :-)
Actually... got to wondering .... failover of what? connection? application? hornetq instance? If I have a live-backup it must fail over to the backup.... this is confusing. Better be explicit about limitation because I am about to test it. :-)
Tried the static cluster. It connects nicely. Then gives beaucoups exceptions about illegal states. This frustrates the attempt to back out of the cluster definition. I am told I can remove these. If I do and I can't get back to where I was I am in deep poo.
Which is where I apparently am anyway.
I really REALLY would like to know how to persuade HQ to simply give me a clean start. How does one go about wiping the bindings clean so it starts over and rebuilds its internal plumbing?
Would this work?
- Make a bare all-with-hornetq profile.
- Alter the hornetq.sar of the bare profile to match the desired target profile
- Start JBoss aimed at the bare profile.
- Stop JBoss
- copy the data directory of the target profile someplace (just in case).
- copy the data directory of the bare profile over to the target.
Too complicated. Could just copy the data directory from before I start JBoss at all? Would be much simpler if it would work.
This DOES NOT WORK. Nor given the manner of its failing, do I expect any variation, including a standalone HQ installation to do better at changing profiles.
Basically it is a JBoss problem. JBoss takes the installed messaging system (whatever it is) and builds up several internal queues for its "postoffice".
These queues are unique to the profile you just built and if you change your clustering configuration, the hanging postoffice queues are simply not defined anymore. The defined postoffice queues are held in the JBoss DB, not in any local datastore. If there is a place where I can wipe them and I find it, I might answer this question myself, but it is not possible to do through hornetq facilities.
Which makes this process very linear. You must settle on your clustering definitions and your usage before you start putting anything into your Appserver.
...or you are going to have to reinstall everything when you change your mind.
No problem with Hornetq except for the apparent inability to bind discovery to the correct nic or all nics. I see it listening on the right port.
Tested multicast on the target systems. Used simple test program. 126.96.36.199 was blocked. 188.8.131.52 was OK. Used 184.108.40.206.
Test program set NIC to use on both send AND receive as dual-homed system is not well suited for our use.
In JBoss discovery worked but only with command line intervention. Binding to force broadcast to use proper nic is hard to achieve else.
In Hornetq it did NOT work. At no time did it come close with dual-homed environment and eth1 needing to be used ---- Static clustering did work.
The apparent difficulty is that there is no way to set a local-bind-address on the discovery-group as it is set on the broadcast group. If there is I have not found it. I think it is not there.
Hornetq has clustered successfully using discovery in all single-homed tests.
It also clusters successfully statically in this environment.
No problems with either.
Now the nasty part. Once used in a cluster internally in JBoss, there are JBoss queues created for the JBoss postoffice functions. These connections are stored in the DB and are not accessible. Changing the name of the JBoss cluster and altering the configurations does NOT seem to cause them to disappear. They are bound in some way to the clustered profile and at this point have not been capable of being removed or altered. If I find a way I will post it.
This is possibly not true of JBoss-Messaging based solutions for JBoss, though the inference is weak.
The question arises whether an external standalone Hornetq will have the same queues created or whether it will use internal JMS hooks to manage changes and ignore the external messaging (unknown to me at present).
All testing conducted on a JBoss-4.2.3.GA system.