Currently, when a connection which has heap subscriptions is closed (for whatever reason), all heap subs are terminated and need to be manually reconstructed by the user of the client.
We want to add the capability to automatically failover to another server. This would necessitate:
Notifying the sub listeners that we're reconnecting
Resending the sub request (possibly the same used in #38) to a new server
Repopulating the heap state based on the new initial state
Notifying the sub listeners that we're reconnected
It would be desirable to be able to perform reconnection on a set of subs at one time, although we need to ensure that the service is given the opportunity to reject these reconnections. We need to ensure that we log the restart of this sub.
There is a danger with a batch reconnect that we overload the server in question since identity resolution will occur for each request and cached identities are perhaps unlikely to exist.
It's perhaps possible that we'd want to maintain a heap with >1 server at all times (in contrast to #38) so that we don't need to receive a new heap at a busy failure point, but only need to worry about the sub creation (on both client and server) - a kind of passive heap that's kept waiting for HA purposes if you will.
Currently, when a connection which has heap subscriptions is closed (for whatever reason), all heap subs are terminated and need to be manually reconstructed by the user of the client.
We want to add the capability to automatically failover to another server. This would necessitate:
It would be desirable to be able to perform reconnection on a set of subs at one time, although we need to ensure that the service is given the opportunity to reject these reconnections. We need to ensure that we log the restart of this sub.
There is a danger with a batch reconnect that we overload the server in question since identity resolution will occur for each request and cached identities are perhaps unlikely to exist.
It's perhaps possible that we'd want to maintain a heap with >1 server at all times (in contrast to #38) so that we don't need to receive a new heap at a busy failure point, but only need to worry about the sub creation (on both client and server) - a kind of passive heap that's kept waiting for HA purposes if you will.