uwiger / gproc

Extended process registry for Erlang
Apache License 2.0
1.07k stars 232 forks source link

local_only exception error when trying to register Pid golobally #180

Closed alishir closed 4 years ago

alishir commented 4 years ago

Hello,

I created a release project with rebar3 and added gproc as a dependency to it. I also added the gproc to .app.src file. But when I run rebar3 shell and try to register a process globally with gproc:reg({n,g,"test}) I got local_only exception error. I also tried #119 by setting environment variable in my shell, but doesn't work.

would you please help me to register a process golobally?

Regards, Ali

alishir commented 4 years ago

According to documents gproc:reg({n,l,"test"}) will register the current Pid on the local node. But when I call gproc:reg({n,l,"test"}) from two different Pid of current node, it doesn't prevent registering second process.

alishir commented 4 years ago

As I found registration is done, locally for each process. So two different process can register same name.

uwiger commented 4 years ago

Hello,

I created a release project with rebar3 and added gproc as a dependency to it. I also added the gproc to .app.src file. But when I run rebar3 shell and try to register a process globally with gproc:reg({n,g,"test}) I got local_only exception error. I also tried #119 by setting environment variable in my shell, but doesn't work.

would you please help me to register a process golobally?

Regards, Ali

As the README says:

To enable fetching of gen_leader, export the OS environment variableGPROC_DIST=true (this can be done e.g. from a GNU Makefile)

It doesn't state explicitly, perhaps, that the purpose of gen_leader is to support global registration.

alishir commented 4 years ago

Hello @uwiger, Thanks for your reply, I also exported GPROC_DIST=true from my shell and then run rebar3 shell, but it doesn't work. I tested both on fish shell and bash.

uwiger commented 4 years ago

Yes, when you start gproc the application environment variable gproc_dist also needs to be set to e.g. all. See https://github.com/uwiger/gproc/blob/a94e1381309f7d79551be7f938459bcd4048abb1/src/gproc_sup.erl#L60

alishir commented 4 years ago

Thanks for your explanation. I added {gproc, [{gproc_dist, all}]} to the sys.config and I can retrieve gproc_dist value from rebar3 shell. Also I exported GPROC_DIST=true in my shell, But rebar3 compile and rebar3 shell doesn't fetch gen_leader dependency and I got following error:

logs ```log 2020-06-20T11:57:31.680349+04:30 supervisor:report_progress/2:1419 info <0.202.0> supervisor: {local,gproc_sup} started: [{pid,<0.203.0>}, {id,gproc}, {mfargs,{gproc,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] 2020-06-20T11:57:31.683487+04:30 supervisor:start_children/2:357 error <0.202.0> supervisor: {local,gproc_sup} errorContext: start_error reason: {'EXIT', {undef, [{gen_leader,start_link, [gproc_dist, [nonode@nohost], [{bcast_type,all}], gproc_dist,[], [{spawn_opt,[]}]], []}, {supervisor,do_start_child_i,3, [{file,"supervisor.erl"},{line,379}]}, {supervisor,do_start_child,2, [{file,"supervisor.erl"},{line,365}]}, {supervisor,'-start_children/2-fun-0-',3, [{file,"supervisor.erl"},{line,349}]}, {supervisor,children_map,4, [{file,"supervisor.erl"},{line,1157}]}, {supervisor,init_children,2, [{file,"supervisor.erl"},{line,315}]}, {gen_server,init_it,2, [{file,"gen_server.erl"},{line,374}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,342}]}]}} offender: [{pid,undefined}, {id,gproc_dist}, {mfargs,{gproc_dist,start_link,[all]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] 2020-06-20T11:57:31.684044+04:30 proc_lib:crash_report/4:508 error <0.200.0> crasher: initial call: application_master:init/4 pid: <0.200.0> registered_name: [] exception exit: {{shutdown, {failed_to_start_child,gproc_dist, {'EXIT', {undef, [{gen_leader,start_link, [gproc_dist, [nonode@nohost], [{bcast_type,all}], gproc_dist,[], [{spawn_opt,[]}]], []}, {supervisor,do_start_child_i,3, [{file,"supervisor.erl"},{line,379}]}, {supervisor,do_start_child,2, [{file,"supervisor.erl"},{line,365}]}, {supervisor,'-start_children/2-fun-0-',3, [{file,"supervisor.erl"},{line,349}]}, {supervisor,children_map,4, [{file,"supervisor.erl"},{line,1157}]}, {supervisor,init_children,2, [{file,"supervisor.erl"},{line,315}]}, {gen_server,init_it,2, [{file,"gen_server.erl"},{line,374}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,342}]}]}}}}, {gproc_app,start,[normal,[]]}} in function application_master:init/4 (application_master.erl, line 138) ancestors: [<0.199.0>] message_queue_len: 1 messages: [{'EXIT',<0.201.0>,normal}] links: [<0.199.0>,<0.44.0>] dictionary: [] trap_exit: true status: running heap_size: 987 stack_size: 27 reductions: 249 neighbours: 2020-06-20T11:57:31.686260+04:30 application_controller:info_exited/3:1938 notice <0.44.0> application: gproc exited: {{shutdown, {failed_to_start_child,gproc_dist, {'EXIT', {undef, [{gen_leader,start_link, [gproc_dist, [nonode@nohost], [{bcast_type,all}], gproc_dist,[], [{spawn_opt,[]}]], []}, {supervisor,do_start_child_i,3, [{file,"supervisor.erl"},{line,379}]}, {supervisor,do_start_child,2, [{file,"supervisor.erl"},{line,365}]}, {supervisor,'-start_children/2-fun-0-',3, [{file,"supervisor.erl"},{line,349}]}, {supervisor,children_map,4, [{file,"supervisor.erl"},{line,1157}]}, {supervisor,init_children,2, [{file,"supervisor.erl"},{line,315}]}, {gen_server,init_it,2, [{file,"gen_server.erl"},{line,374}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,342}]}]}}}}, {gproc_app,start,[normal,[]]}} type: temporary 2020-06-20T11:57:31.688369+04:30 supervisor:report_progress/2:1419 info <0.208.0> supervisor: {local,sasl_safe_sup} started: [{pid,<0.209.0>}, {id,alarm_handler}, {mfargs,{alarm_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] 2020-06-20T11:57:31.688578+04:30 supervisor:report_progress/2:1419 info <0.207.0> supervisor: {local,sasl_sup} started: [{pid,<0.208.0>}, {id,sasl_safe_sup}, {mfargs,{supervisor,start_link, [{local,sasl_safe_sup},sasl,safe]}}, {restart_type,permanent}, {shutdown,infinity}, {child_type,supervisor}] 2020-06-20T11:57:31.691931+04:30 supervisor:report_progress/2:1419 info <0.207.0> supervisor: {local,sasl_sup} started: [{pid,<0.210.0>}, {id,release_handler}, {mfargs,{release_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] 2020-06-20T11:57:31.692226+04:30 application_controller:info_started/2:1929 info <0.44.0> application: sasl started_at: nonode@nohost ```

info.log

alishir commented 4 years ago

The above problem resolved by manually adding gen_leader dependency to the rebar.config. But still when I call gproc:reg({n,g,"test"}) from cowboy handler I can register under same name twice. I think the expected behavior is first register return true and the second one cause some error.

alishir commented 4 years ago

Sorry for interruption. It seems I found the problem, cowboy creates a process for each request, after first request the process is terminated so the gproc entry deleted, so the next request can create new entry with the same name.