Forcing a certain node to become master

[frankthetank]

Hello all,

for a concept I would like to be able to define which node in my cluster shall become the master.

The simple justification is that I'd like to be able to have prepared and predetermined 'fail overs' at certain times.

Is this possible in 4.2.3?

And if so, would it be possible to control which servers are passed back to clients in the cluster?
I basically only want the clients to interact with the master.
(if this is the wrong place or I should create a 2nd topic, pls say so)

thanks

[frankthetank]

Maybe I can extend the justification a little further:

I'd like to have a set-up where I have 2+ nodes, but only one is 'alive-and-kicking' while the others are completely passive.

Any clients using the proxy would only interact with the one master server.

On a regular fail-over, everything moves over to the next system (currently I have no requirements for a specific fail-over scenario) and the proxy simply starts talking with the new master.

Data replication is handled outside of JBoss. Data is NOT time critical.

Nothing shall happen if the failed server rejoins.

Finally I'd like to be able to trigger such a fail-over.
F.i. to force one certain server to become master (again).

Environment considerations:
* As mentioned, data replication is handled outside of JBoss, as both JBoss AS and DB run on the same nodes.

* I have multiple ha-singletons that are needed and can only run once in a productive environment.
This is one of the difficulties I had with other designs, as clustering would bring the required actions (start, stop, etc) with it that I would otherwise have to copy.

* clients should only interact with the master and be as fail-over tolerant as possible. Also something provided by the clustered proxy, though the 'only-connect-to-the-master' might be a step to take.

I have looked into the sources a little bit but have not really found anything yet that indicates if this is even possible.
From what I could tell the cluster takes it's info from the JGroup views.

I would really appreciate any help.

[frankthetank]

Supposing I have to make the modifications myself:

* Use a LoadBalancer like FirstAvailableIdenticalAllProxies but with a 'always use first one' pattern and have the cluster give me the targets in the correct order. (i.e. master first)
setting my new class in the cluster-service.xml
(though the client will need a copy of the class as well)

* HAPartitionImpl.viewAccepted() is looks like the central place where the logic of the cluster view is kept, updated and events sent out.
Though I still need to figure out how I might be able to change this.

Q: is there a config xml somewhere I can use to set this?

I think it would be possible to just sort the view by a certain logic, though I still have to figure out how to share this info on the cluster (prob. something with JGroups.

* anything else I would have to watch out for?

[brian.stansberry]

For sure you have to make modifications yourself.

The actual service topology is controlled by the org.jboss.ha.framework.server.DistributedReplicantManagerImpl, which is a sub-component of the HAPartition.

The JGroups view that's passed into HAPartition.viewAccepted() provides the list of nodes that have connected to the JGroups channel. But JGroups view != service topology, since not all nodes may have a particular service deployed, and there are timing differences during startup/shutdown of a server. That is, HAPartition connects the channel, so a node appears in the view, and then a service that uses HAPartition is deployed on that node, at which time the node appears in the service topology. The DistributedReplicantManagerImpl deals with that stuff.

A lot of AS clustering stuff works by getting notifications from DistributedReplicantManager when the topology for a service changes. For example, the org.jboss.ha.singleton.HASingletonSupport class uses those notifications to trigger election of an HASingleton master. The org.jboss.ha.framework.server.HATarget class uses the notifications to provide the correct topology to server-side interceptors like org.jboss.aspects.remoting.ReplicantsManagerInterceptor and to the clustered invokers like org.jboss.invocation.unified.server.UnifiedInvokerHA. Those classes advise remote clients when the service topology changes. The proxy factories a la org.jboss.proxy.generic.ProxyFactoryHA listen for notifications and respond by publishing a new version of the proxy in JNDI, so clients doing a lookup get a proxy with the current topology.

So what you're trying to do is to get the topology in the desired order. With that many different places receiving notifications, I don't think you want each one ordering the topology. Rather it's more logical to have the DistributedReplicantManagerImpl order things in the way you want before issuing the notifications.

There are no hooks or configuration points to let you plug in how things are ordered. You'd have to customize to add that. If you are able to come up with a solution that is generally useful, let me know, perhaps we could add it to the AS codebase.