[erlang-questions] Restarting processes

[Daniel Ginsburg]

This sounds good. I think I'll give it a try. I just hope that process
registry won't die ;)

I think I'll need to measure performance of lookups in (or folding
through) the registry (if you have any data, please share). Anyway, even
if the lookup is not very fast, I'll be able to repopulate demux lookup
tables from the registry in case demux has to restart.

Ulf Wiger (TN/EAB) пишет:
> I made an extended process registry a while ago,
> called proc:
> 
> http://jungerl.cvs.sourceforge.net/jungerl/jungerl/lib/proc/
> 
> Here's the edoc manual:
> http://jungerl.cvs.sourceforge.net/*checkout*/jungerl/jungerl/lib/proc/d
> oc/proc.html?revision=1.1
> 
> It allows processes to register under several different 
> names, and the names don't have to be atoms. It also 
> allows processes to register "properties", which do 
> not have to be unique.
> 
> 
> Properties can be used for a very simple publish-
> subscribe pattern that would work in your case.
> 
> The subscriber publishes a property, and the publisher 
> folds over a given property and e.g. sends a message to 
> each process.
> 
> Example: 
> 
> demux.erl
> 
> subscribe() ->
>    proc:add_property(property()).
> 
> notify(Event) ->
>     proc:fold_properties(
>         fun({_Prop, Pid}, _Acc) ->
>             Pid ! {self(), ?MODULE, Event}
>         end, [], property()).
> 
> property() -> {?MODULE, subscriber}.
> 
> As the subscriber property is registered with the 
> subscriber process, and not kept by the publisher,
> it remains even if the publisher is restarted.
> 
> An added bonus with the pattern is that properties 
> become sort of a public registry of characteristics
> and dependencies of properties - a process index,
> which can be extremely helpful during debugging.
> 
> We've been using this solution in our products for
> a while, and it has led to a radical simplification
> of the code. It turned out that this was a pervasive
> pattern in our applications, e.g. releasing all 
> calls associated with a given signaling channel; 
> identifying all processes involved in a given 
> call setup; etc.
> 
> BR,
> Ulf W
> 
> 
>> -----Original Message-----
>> From: erlang-questions-bounces@REDACTED 
>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of 
>> Daniel Ginsburg
>> Sent: den 29 mars 2007 11:42
>> To: erlang-questions@REDACTED
>> Subject: [erlang-questions] Restarting processes
>>
>> In my application I have a demultiplexing process and few 
>> worker processes. The workers subscribe to events, the 
>> demultiplexor gets requests from the network, and distributes 
>> them to the workers, which handle them as appropiate.
>>
>> The demultiplexor monitors (erlang:monitor) the workers, so 
>> when a worker terminates without unsubscribing, the 
>> demultiplexor cleans the subscription data.
>>
>> Now, what if the demultiplexor itself die? Ok, 
>> demultiplexor's supervisor will restart it. But what about 
>> the workers? I don't want to terminate and restart them, 
>> because workers carry quite a few state and I don't want that 
>> state to be lost. So, I need my workers to resubscribe to 
>> restarted demux. How can I handle it nicely?
>>
>> I can have workers to monitor the demux. It solves a part of the
>> problem: the workers would be notified if old demux die and 
>> try to resubscribe to new demux getting it's pid via 
>> whereis(demux_registered_name). But what if a worker get 
>> {'DOWN', ...} message and tries to resubscribe, but the demux 
>> isn't restarted yet or haven't finished the init stage? 
>> Cleary a race contidition. I can introduce a small delay 
>> after the {'DOWN, ...} message and attempted resubscription, 
>> but this approach seems to be a bit ugly.
>>
>> What I want to do is to have a some way for demux to announce 
>> "Hey, I've just restarted and forgot all my subscribers. Now 
>> I'm operational again.
>> Whoever interested may resubscribe". Supervisors seem to be a 
>> natural choice to relay that king of messages, since they are 
>> always there. But it appears that OTP supervisors cannot do 
>> that. How do you handle this kind of problems in your applications?
>>
>> --
>> dg
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>


-- 
dg