How do we get transparent failover into the existing jms ha

[starksm64]

So there is a problem with transparent failover in the existing ha/jms scenario. Is there sufficient and accurate state available in the client that could allow for this to be made transparent. Adrian has started a todo for this on the wiki:

http://jboss.org/index.html?module=bb&op=viewtopic&t=46194

[adrian.brock]

Let's keep this specifc issue in this thread:

To make transparent failover work, two features:

1) The client proxy needs to know where the server failed over to
without any work done by the client application writer.

2) The server's client specific state needs to replicated.

[adrian.brock]

1) The client proxy doing automatic failover

The client proxy needs to reget the ServerIL (connection factory) from the new
singleton and reinitialise.

This could be done:
a) Simply, but as not very reliable (Use HAJNDI). The HAJNDI stub would
need regular updates of active cluster locations - which wouldn't happen unless there
are regular invocations over a HA
b) Use the HA mechanism to do JMS communication, i.e. piggy back
changed cluster views on the back of jms invocations.

[adrian.brock]

2) Maintaining client state across the cluster (similar to HTTP/SFSB replication)
This assumes we are not going to do full replication which is a lot more work
and much less performant.

The server maintains a list of messages that each client has received but not
acknowledged yet.
In the event of a singleton failover, this information would need to be on the new
server to make sure recovering the destination messages from the db doesn't
make the messages available again.

Without this processing you get:

On initial server:
Queue: empty
Client1: message1

After failover
Queue: message1
Client1: empty

Again two possible solutions:
1) Update the db on every message receipt to log which client has which message
2) Replicate this state across the cluser.

[adrian.brock]

Two additional comments:

1) Without full replication (including the list of messages in a destination) NON_PERSISTENT messages will be lost at failover

2) There needs to be a mechanism to cope with both the client and server
failing at the same time.
e.g. Before/After server failure
Queue: empty
Client1: message1

But during the failover Client1 fails. This would need some sort of timeout to detect
that Client1 didn't transparently reconnect.