mindreader
Why is Registry local only?
I am writing an application that uses pub sub between various processes quite heavily. I wrote it at first with the local Registry in elixir and it works great. But eventually I needed processes on a different nodes to subscribe to this data, so I had to look for an alternative.
I looked at gproc and syn and I was not too happy with them. gproc’s api is horrible and barely documented and I can’t even get it to work in global mode. It would be an extremely tough sell to my coworkers. Syn has all sorts of collision detection ability and requires all nodes be connected before it can be initialized, or god knows what happens, and all of that is overkill. All of my registries are on one node, and other nodes just pass a message to them once in awhile. Edit: And after reading it more in depth, I’m not sure process groups are what I’m looking for.
So I started writing my own. After I was about half done I realized I was writing elixir’s local Registry myself but worse, and the only real change that mattered was that I could pass in a name: {:global, :name}, into all of my versions of its functions. Registry makes every possible attempt to prevent you from doing that.
At this point I’m seriously considering copying elixir’s registry and just changing some functions to accept a global name tuple, and the only thing stopping me is that I’m wondering what trouble they were trying to prevent me from causing when they wrote this module in this fashion. So if someone could tell me why what I’m considering doing is a bad idea that’d be great.
Most Liked
josevalim
A very quick rundown of your options:
Registryis local onlygprochas a global mode but the consensus is that it is unreliable. so consider it local only.- you can use
pg(part of OTP) if you need a distributed process group (duplicate keys) - you can use
global(part of OTP) if you need a distributed process registry (unique keys) - you can also use
syn- you seem to already be aware of its pros/cons - you can also use
Phoenix.Tracker, which is part of thephoenix_pubsubproject, as a distributed process group (duplicate keys)
EDIT: Updated in 2023 to mention pg instead of pg2 in Erlang/OTP.
ostinelli
Sorry for the late reply, I’m not active on these forums.
FYI and anyone interested, contrary to what stated here above Syn does not require all nodes to be connected before it can be initialized. The only requirement is that a node joining a cluster first connects to it before calling syn:init/0. This of course does not mean that all nodes need to be connected before syn can be initialized. Example code is in the README.
So yes, it is absolutely possible to add nodes to a running cluster and everything will work fine.
you can also use syn - you seem to already be aware of its cons
@josevalim would you mind expanding? I didn’t understand what cons you are referring to and I’d be happy to take yours and any feedback that could make it better.
Best,
r.
michalmuskala
The simple (and boring) answer is that distributed registry is really, really hard to get right. The OTP team is already working on improving what’s available in Erlang itself, so there’s no need to duplicate efforts.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








