Create an OTP service to allow for hot code reloading #4
Labels
Milestone
Comments
aszlig
changed the title
aszlig
added a commit
that referenced
this issue
Aug 27, 2015
We want to make sure that the MongooseIM service doesn't *restart* on changes, but only reloads the code + configuration. This is implemented by a small test network consisting of a client with escalus and a server with MongooseIM. On the client, we run a small "testclient" Erlang server, which is controlled using erl_call and it's more or less just a gen_server which accepts atoms as messages and runs the tests in question. After we've done some initialization (creating two test users and let them communicate), we activate the new configuration on the server, which disallows the use of C2S for all users. Of course, if the server is *restarted*, the clients get disconnected, so we check for disconnection shortly after the activation of the new server configuration. With the activation, we also *shouldn't* be able login anymore and we'll check that plus the uptime of the server before and shortly after the activation. As we currently don't have hot code reloading this test obviously fails, but the next step is to tackle issue #4 properly so we need that test. Signed-off-by: aszlig <[email protected]>
|
Hydra test case is at https://headcounter.org/hydra/job/headcounter/deployment/tests.code-reload. |
aszlig
added a commit
that referenced
this issue
Aug 30, 2015
This currently makes the code-reload test happy, because we're only supplying a new configuration file over there. But it won't solve #4 because whenever the store path of MongooseIM itself changes, we don't have a way to upgrade the release yet. Right now, we're creating a gcroot to the currently running store path, so we have everything in place to check the differences between the store path. Turns out that we might want to write our own release handler, because reltool only works with version numbers. Unfortunately, this won't work on our side, because we'd need to increment a version number whenever we have any changes. In theory this could work if we'd create a Nix environment, so that we have a generation number we can increment. But that will only work in practice if we don't have any patches for mongooseim and all applications we depend on. To conclude: We currently exit with code 1 if the store paths differ until we have either found a good way to deal with it using reltool or we have our own implementation in place. Signed-off-by: aszlig <[email protected]>
|
Investigate this stacktrace on [{ejabberd_config,is_not_host_specific,
[{domain_certfile,"jabber.headcounter.org"}],
[{file,"src/ejabberd_config.erl"},{line,1225}]},
{lists,'-filter/2-lc$^0/1-0-',2,[{file,"lists.erl"},{line,1284}]},
{lists,'-filter/2-lc$^0/1-0-',2,[{file,"lists.erl"},{line,1284}]},
{ejabberd_config,get_local_config,0,
[{file,"src/ejabberd_config.erl"},{line,1214}]},
{ejabberd_config,get_config_diff,1,
[{file,"src/ejabberd_config.erl"},{line,891}]},
{ejabberd_config,reload_cluster,0,
[{file,"src/ejabberd_config.erl"},{line,826}]},
{ejabberd_ctl,call_command,3,
[{file,"src/ejabberd_ctl.erl"},{line,323}]},
{ejabberd_ctl,try_call_command,3,
[{file,"src/ejabberd_ctl.erl"},{line,295}]}] |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We already use
reltoolfor release handling, but everything still boils down tomongooseim.service. This has the downside that we need to restart the XMPP server on every single change, even though we don't have to if we would have an OTP service which just runs the Erlang VM. The latter needs to be restarted only whenever there is a new Erlang release and themongooseim.servicejust reloads its code using therelupfile.The text was updated successfully, but these errors were encountered: