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
As ra nodes require a persistent identity (i.e. be reachable on the same destination after a restart) they currently register themselves with the local process registry which means that the ra_node_id() used in the cluster configuration and all interactions is of the type: {atom(), node()}. This is fine when the ra clusters required are of a fixed number. When starting and stopping ra clusters dynamically this could lead to atom table exhaustion.
To counter this we should consider some alternative means of providing a persistent identity. This means more complexity and failure scenarios to consider.
We'd require some alternative means of mapping, say, a binary name to a pid and keep this pid current for both ra peers and clients.
The text was updated successfully, but these errors were encountered:
One alternative would be to impose a limit on the number of ra clusters an erlang cluster is willing to support. We could then pre-generate a set of dummy atoms (ra000000001 etc...) and when ra cluster with binary or string names is created it is allocated a dummy atom name which is used for all communications.
Dummy atoms could then be re-used rather than risking exhausting the atom table.
This allocation would probably need to be persisted or at least properly managed (yet another consensus problem) but we could delegate the responsibility of this to integrating application rather then the ra library.
As ra nodes require a persistent identity (i.e. be reachable on the same destination after a restart) they currently register themselves with the local process registry which means that the
ra_node_id()
used in the cluster configuration and all interactions is of the type:{atom(), node()}
. This is fine when the ra clusters required are of a fixed number. When starting and stopping ra clusters dynamically this could lead to atom table exhaustion.To counter this we should consider some alternative means of providing a persistent identity. This means more complexity and failure scenarios to consider.
We'd require some alternative means of mapping, say, a binary name to a pid and keep this pid current for both ra peers and clients.
The text was updated successfully, but these errors were encountered: