Giters

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

syn_event_handler per process/group

erlmachinedev opened this issue · comments

commented

This discussion shouldn’t be considered as an issue, rather as a feature.

The main point that is Syn can be used by different applications under the common shared release.

{syn, [
    {event_handler, my_custom_event_handler}
]}

This global setup listed above doesn’t meet the criteria:

  1. Each app can share it's own Syn space and manage process creation/exits by independent way;
  2. The root app shouldn’t rewrite the event_handler config by it's own value. The current design cause one way which is top to bottom registry

The solution:

register(Name, Pid, Meta, Handler);
join(GroupName, Pid, Meta, Handler);

Where each interested party can setup their own event_handler within particular called scope. This argument will have the higher priority then env parameter and would provide the users with flexibility to manage their own registry scopes.

P.S. If this feature is considered as useful I may provide appropriate PR as solution, thanks in advance.

commented

Hi @erlmachinedev, this makes sense and is a good suggestion. However, this addition would have to be retro-compatible with what we have now, where the priority would be given to the Handler arg in register/3 and join/3, falling back to the handler specified in config.

Do you feel like providing a PR?

commented

Hi @erlmachinedev, this makes sense and is a good suggestion. However, this addition would have to be retro-compatible with what we have now, where the priority would be given to the Handler arg in register/3 and join/3, falling back to the handler specified in config.

Do you feel like providing a PR?

@ostinelli Hi, sure, nice to see that we at the same ground here. Yep, will send a draft PR soon

commented

If you've not started work, please hold on as I'm currently considering the option of moving to v3. I will update asap.

commented

I'm currently thinking whether it'd be useful to add scopes to syn, so that you'd do something similar to:

Scope = users,
syn:add_node_to_scopes([Scope]),
syn:set_callback_module(Scope, CallbackModule).

This would allow to create "subsets" of clusters to improve scalability, but also to specify different behaviors per Scope.

Then you could:

register(Scope, Name, Process),
syn:join(Scope, GroupName, Pid).

In this case, when a process is registered / unregistered / joined / leaves, the CallbackModule of the Scope will be used. Would this work for you?

For ease of use, there would be a default scope that would allow simpler API such as:

syn:set_callback_module(CallbackModule),
syn:register(Name, Process),
syn:join(GroupName, Pid).

Still thinking about it.

commented

@ostinelli Hi, I agree that it's better to wait when your implementation is ready (sorry about delay with PR, I am a little bit lazy during this summer).

Scopes can make code more structured as well, yep it's better to wait v3

commented

This ask has been one of the reasons for creating syn v3. This new version allows to define scopes, and therefore the callbacks can differentiate action based on those. This should cover your use case.

I'm still working on the new version and it will take me a little while, so thank you for your suggestion and patience.

commented

Syn v3 is now out and includes the discussed Scopes solution.
https://hex.pm/packages/syn

commented

Syn v3 is now out and includes the discussed Scopes solution. https://hex.pm/packages/syn

Great job! Thanks Roberto! We start to switch our platform to v3 ASAP