Erlang: using gen_event global for a remote manager

Question

I can start my event framework just fine when I register it locally:

gen_event:start_link({local, foo_event_container}).
gen_event:add_handler(foo_event_container, foo_event_handler, []).

Calling registered() shows foo_event_container, and when I send messages to it, they show up in the handler.

However, when I restart the node and try

gen_event:start_link({global, foo_event_container}).

registered() does NOT show the container, and when I try to add a handler to it I get

** exception exit: noproc
     in function  gen:call/4
     in call from gen_event:rpc/2

Sasl doesn't provide any additional info, and googling this issue produces a guess that the shell running the container has been killed, which is not the case here since I'm trying to access it from the same node!

1) Any ideas what's going on here?
2) Is having a remote container the best design, or would it be better to have each server use local containers that all send out messages to a remote process?

Thanks!

Answer 1

Local registration and global registration are separate namespaces. Items registered locally don't show up as global registrations and vice-versa. (Also, local registration names must be atoms, while global names can be terms)

Your global registration should show up in global:registered_names/0 and you can send to globally registered processes either with global:send/2 or by looking up the pid with global:whereis_name/1 and sending messages to that pid as usual.

You should be able to add a handler by doing something like gen_event:add_handler({global, Name}, Handler, Args). Most gen_* modules contain code to cope with process names like {global, Name} to do the global lookup for you.

Lastly, if you start_link a process from the shell and then evaluate an expression that causes the shell to crash, that process will be terminated - it was just killed by the shell error via the link. Start it without a link, or start_link it under a supervisor if you want to avoid this. It's usually a bad idea to link something to the shell process as typos will then shut down the processes you're working with.