[erlang-questions] acceptor loops and hot code swapping

[Siri Hansen]

Hi Roberto!

Sorry for the very late answer - maybe you have already solved this and
moved on...
Anyway - for the code swap to actually take effect, you must, as you
suggest, do a fully qualified call to your loop - i.e. put ?MODULE in front
of the call. This will make sure that after a new version of your module
has been loaded, the next call to the loop function will execute the new
code.

If you should use a timeout in your loop or not depends, I guess, on how
often you get incoming TCP connections. You will experience problems if you
happen to purge and load your module twice without the fully qualified call
to the loop function being executed in between. The reason for this is that
your process will be killed by the code server if it is still running old
code at the time of your purge.

Example A - expected flow:
1) start your process with mod vsn 1 => vsn 1 is now 'current'. There is no
'old' code.
2) compile and load mod vsn 2 => vsn 2 is now 'current' and vsn 1 is 'old',
but your process is still running vsn 1
3) force ?MODULE:loop in your process => your process now runs vsn 2, and
vsn 1 is still 'old'
4) purge mod => vsn 1 is removed, your process still running vsn 2.
5) load mod vsn 3 => vsn 3 is now 'current' and vsn 2 is 'old'. process
runs vsn 2.
etc...

Example B - forced purge which kills your process:
1) start your process with mod vsn 1 => vsn 1 is now 'current'. There is no
'old' code.
2) compile and load mod vsn 2 => vsn 2 is now 'current' and vsn 1 is 'old',
but your process is still running vsn 1
3) purge mod (without doing a fully qualified function call first) =>
code_server tries to remove vsn 1, but since it is still running in your
process, your process will be killed!!!
...

So - timing out the acceptor should be to prevent this type of problem...

Regarding system events: If you have your process hanging in a supervisor
tree, you want to use the release_handler (or similar) for upgrading, and
you might want to change the process state in any way during upgrade - then
you should handle the change_code system event, i.e. implement the
system_code_change callback.

I hope this was of some use...
Regards /siri


2011/11/30 Roberto Ostinelli <roberto@REDACTED>

> dear list,
>
> i've got a process that has been started by a supervisor with
> proc_lib:spawn_link/3.
>
> this process is mainly listening on new incoming TCP connections using
> gen_tcp:accept (or the SSL equivalent), with a timeout set to infinity.
> when a new connection gets requested, the acceptor process spawns a new
> process which will handle this new connection, and then it returns to
> listening for new connection requests.
>
> what is the best way to ensure that the listening acceptor process gets
> updated on hot code swapping? do i just need to add a the ?MODULE macro in
> front of the calls that get back to the acceptor loop, i.e.
> ?MODULE:acceptor_loop? should i actually timeout the acceptor? is there any
> particular system event i should be catching?
>
> any input warmly welcome.
>
> thank you,
>
> r.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111206/8b858b0a/attachment.htm>