[erlang-questions] how to _cause_ a code_change in a gen_fsm

[Lukas Larsson]

For the code_change callback to be called you have to trigger a real relup
using reltool and friends. What basically happens is that when a system
does a relup it checks which processes are running that are OTP processes
and send a message to them after the new code has been loaded which tells
them that the code has changed. There is no way for a process to know that
it's code has changed so SASL and reltools handle this for you when you do
a relup. If you just load the new code nothing will happen.

For details about how to do a relup I recommend looking at
http://learnyousomeerlang.com/relups

Not sure what support ejabberd has for this kind of thing.

On Sat, Nov 26, 2011 at 6:01 PM, Daniel Dormont <dan@REDACTED>wrote:

> Ok. So what is the "right" way to get my code_change callback to fire?
> I see some reference to "appup" and I have looked over that part of
> the manual but don't really understand how it applies to my case.
> Literally all I have is a .beam file I want to install in a running
> system.
>
> dan
>
> On Sat, Nov 26, 2011 at 10:28 AM, Bob Ippolito <bob@REDACTED> wrote:
> > I don't know how ejabberd likes to do things but l() is the lower level
> > non-OTP way to do things and will immediately purge the old code and load
> > the new code. Nothing else will happen, no magic.
> >
> > On Friday, November 25, 2011, Daniel Dormont <dan@REDACTED>
> > wrote:
> >> This is a follow-up to my earlier question but the topic is a little
> >> different. Having put together a nice piece of code for handling the
> >> change in my gen_fsm's state record, I discovered to my chagrin that
> >> when I loaded the new code (using l() at first and then using the
> >> "update" command that comes with ejabberd) it did not call the
> >> code_change callback; neither immediately nor before processing the
> >> next message sent to that process. I admit that the details of things
> >> like proc_lib and sys are a little opaque to me, but I had understood
> >> that as long as the module implemented a standard OTP behavior, code
> >> upgrades would "just work" in some sense. I suppose I was wrong :)
> >> This module is fairly self-contained, so I'm not too worried about
> >> having to synchronize other modules, notify supervisors or anything
> >> like that. How do I proceed from here?
> >>
> >> thanks,
> >> dan
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Daniel Dormont <dan@REDACTED>
> >> Date: Mon, Nov 21, 2011 at 10:51 AM
> >> Subject: code_change for gen_fsm: how to actually handle a state change
> >> To: erlang-questions <erlang-questions@REDACTED>
> >>
> >>
> >> Hello all,
> >>
> >> I have a gen_fsm module and would like to take advantage of hot code
> >> deploy. The module uses a record (called "state") and the new version
> >> of the module includes some new fields in the record. What is a nice
> >> clean way to code the my_module:code_change function to deal with
> >> this? Are there any good examples out there on the web?
> >>
> >> Note: for my purposes it would be sufficient to detect that the state
> >> record is out of date, and terminate cleanly. BUT the correct
> >> functionality of the terminate/3 function in my module depends on the
> >> state data, and I would need it to complete cleanly and not crash in
> >> this instance because there are other processes that depend on this
> >> one and need to be notified properly of its exit. The issue is that
> >> the state itself contains the data of which processes those are.
> >>
> >> What's the best approach here?
> >>
> >> thanks,
> >> Dan
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >>
> _______________________________________________
> 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/20111126/3b4d861e/attachment.htm>