ostinelli / syn

A scalable global Process Registry and Process Group manager for Erlang and Elixir.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Not unregistering exited processes

thdxr opened this issue · comments

commented

I'm having an issue where it seems like syn is not unregistering processes when they exit. I'm able to get a pid from syn:whereis_name but if I try to send messages to the result I get a no such process error. I've verified the process indeed does not exist.

Any idea?

Syn is eventually consistent. Even if it's fast, it can still take a little while in a distributed system have a process be unregistered (you can find some benchmarks here). Is this the case?

If not, then I'd need to know more and have a way to reproduce. For instance, I'd need the Syn version you're using and to know something more about your code: there's no no such process error message when sending to a non-existant pid:

1> Pid = list_to_pid("<0.999.0>").
<0.999.0>
2> Pid ! hello.
hello

PS: I assume that you are referring to syn:find_by_key/1,2 method, there is no whereis_name method.

commented

The process actually never ends up being unregistered until I unregister it
manually. I haven't yet been able to reproduce it consistently but I'll
try to dig into it. The scenario it's happening under is a GenServer stops
itself but it doesn't get unregistered

Again: What functions are you using? How do you "manually unregister it"? Without details there isn't much help that I can provide. :)

commented

Sorry for the sparse information I'm going to debug more and come back with better information. I'm on 1.5 but I'm going to try 1.6 and by manually unregister I meant calling syn:unregister

I have the exact same issue and are also using syn:register and syn:find_by_key. It seems to happen when there are multiple processes, each living on different nodes, that is trying to register the same key simultaneously. When it gets into the error state, it can be resolved by calling syn:unregister, just as dax0 explained.
The setup is a three node cluster running syn v1.6 (also tried with 1.5) and OTP 19.1 (also tried with 18.3). When in the error state two of the nodes has registered the same pid and the third has a different pid - none of them alive.
I can reproduce this on my setup by spawning multiple pairs of processes living on two different nodes, competing to register the same key. However, not consistently.

@malmovich mnesia will send a message when it gets inconsistent, which is what you are referring to. When it does, syn gets the message and it resolves the conflicts, see here.

Are you seeing any messages in the logs?

@dax0 and @malmovich did you get a chance to look into this (logs, etc)? Thank you.

Closing due to no activity.