[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover on Shutdown

[timfox]

The main problem with the suggestion is the following:

In JBM each node maintains its own set of "partial queues". So if you have a distributed queue A, for example, deployed across the cluster, then A is actually made up of a set of n queues (n = number of nodes in cluster), each node maintaining its own queue.

So, in normal cluster operation, each partial queue will have its own set of messages in it.

On failover, another node in the cluster takes over the partial queues of the failed node and merges them into its own set of queues. We need to do this so the client can transparently carry on its session on the new node, e.g. it needs to know about messages it has consumed but not acked so they can subsequently be acked on the new node.

Shutting down a node in the cluster is quite different from failing over. With a shutdown, it is likely the sys admin is just taking the node down temporarily and will restart it again shortly. In this case we *do not* want another node to take over and merge the queues of the node that is being taken down.

Imagine the pathological case where the sysadmin takes every node in the cluster down one by one. By the time the sysadmin takes down the last node in the cluster, that node will have merged in *all* the queues from the other nodes! Not only will this be slow, but it means that when the cluster is brought back up, only one of the nodes (the last one to be taken down) will have all the messages.

This is obviously not something we want.

Another question we should ask is "is it possible to trigger the client side failover without triggering the server side failover?" - i.e. could we fail over the clients on shutdown without failing over the server side (i.e. merging queues)?

The answer to this is also no, since we would then lose transparent failover, since if we failed over a client which has unacked messages in its session then it would fail to ack them on the failover node since the queues hadn't been merged.

So in summary, it seems pretty clear to me that forcing failover on shutdown is not going to work with transparent failover.

However, nne thing we could maybe do is introduce a "JBoss MQ style mode", where we disable automatic failover on the server side - so if a server node fails then its queues are *not* merged into another nodes queues.

Client side automatic failover can already be disabled by setting "supportsFailover" to false on the connection factory.

By doing so, a client application could just catch the exception thrown to a connection ExceptionListener and re-lookup the connection factory using HAJNDI and recreate the connection etc, a la JBoss MQ. This would work but is it means none of the automatic failover functionality would be used, which seems a shame to me.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053193#4053193

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053193