-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative to using the local process registry. #12
Comments
One alternative would be to impose a limit on the number of 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 |
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: