Issue #1 resolved

Restore pools in emongo process state after crash

Dmitry Belyaev
repo owner created an issue

If emongo process will crash and be restarted by emongo_sup then emongo will not remember what pools are already created.

Comments (4)

  1. Jacob Perkins

    This is because you took out the app config, which is the standard way to maintain persistent app configuration data, such as which pools should exist. I'm curious why you took out the app config? Without it, the best solution I can think of is to use mnesia to store dynamic configuration data.

  2. Dmitry Belyaev reporter

    As I understand, whole erlang application should be placed to /usr/lib/erlang/lib/ folder. So emongo.app will be there. But linux common practice is to have configuration files inside /etc

    My application has it's own config file (in /etc) and my idea was to put emongo pool configuration there. Now my app dynamically configure emongo with "application:start(emongo), [apply(emongo, add_pool, Pool) || Pool <- Pools]".

    This allows some other applications which may be used in the future add their own emongo pools in their configuration files.

  3. Jacob Perkins

    General erlang release practice is to have a self-contained target system for each node. This target system has a global configuration file named sys.config, which can contain app config overrides. So you'd specify all your pools in the emongo section of your sys.config. If you have different apps that use emongo, then I'd either put them in the same target system with a shared sys.config, or have separate target systems on separate logical nodes. It's kinda like having a separate virtualenv for each django installation, if you're familiar with python/django.

    You can deviate from this model if you'd like, but it's not "erlangy", and you lose the sasl release system.

  4. Log in to comment