You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: