[erlang-questions] Dependencies, included applications and supervision

[Fred Hebert]

On 06/25, Jay Nelson wrote:
> [snip]
> 
> This sequence is enforced in a rest_for_one pattern, so that if the service
> advertising or the implementation of the service becomes unavailable, then
> the service will read as offline. Once rest_for_one has restored everything,
> the last step advertises that the service is available.
> 
> The ets table is created and owned by the first supervisor so that it is not
> lost during transient failure of other components. This is essential because
> the ets holds other services advertised by other nodes and is consulted
> locally.
> 

What I can think of in this case is a bit like this. What you provide is
twofold:

1. Registration of your service to say you're online
2. Caching of external services' presence in ETS.

They're complimentary, but intersect in some way.

What I see for these is therefore:

1. A presence management and registration app, let's call it presencerl;
2. A lightweight self-registration process that contacts presencerl to
   register.

      (MyApp)                        (Presencerl)
     [MyApp_sup]                  [presencerl_sup]---ETS
     /    |   \                      /         \
  [w1]  [w1]  [agent]   [presencerl_local] [presencerl_remote]

Where MyApp_sup can be using a rest_for_one strategy. The 'agent'
process is in charge of calling something like 'presencerl:register(App,
self())', and then it can just hibernate forever.

presencerl_local just monitors any agent that contacted it and matches
it in the ETS table owned by the supervisor (which can be super
resilient and do 100000 MaxR for 1 MaxT for no reason) and broadcasts to
peers. Presencerl_remote listens to peers and populates the table in
ETS.

Using it that way, you decouple your service discovery from your
principal app, and can build multiple apps that all depend on presencerl
independently. You can even have 'sub-services' if you want, and you
just did away with your included applications.

You can also disable specific services during partial upgrades without
needing to shut down other services running on the same node!

> 
> The “lesser alternatives” I referred to resulted in situations where the
> presence subsystem went away but the service was available and running
> just fine, but not receiving traffic because it appeared to be offline.
> 

This doesn't really go away in this case, unless you make the presencerl
app permanent, which can then have it share similar failure thresholds
to your main app, something that is somewhat equivalent to shoving both
under the same supervisor.

Anyway, that's a quick idea of how it could be done, I think.

Regards,
Fred.