Updating config object when config database is updated

[Heiko Jansen]

Hi *,

we're working on an app with some extensive config data which also needs some preprocessing (merging defaults etc.) to become usable.

We use a plugin ("register" method) to initialise a config object on app start and keep it around, as recreating the config on every incoming request would be to costly.

However, the config data - held in a few MongoDB documents - might be updated anytime via scripts and/or a web admin GUI and it would be expected that these changes take effect immediately (or at least within a short time frame).

On the other hand the number of updates is expected to be fairly low; perhaps 50 times per day.

So we need to find an effective way to trigger a recreation of the config object in all Hypnotoad child processes.

I can see a few options for that; e.g.

- simply restarting the hypnotoad, or

- adding a periodic timer to the IOLoop which checks for an updated config databases or

- starting a MongoDB (Mango) query on app start which uses a tailable cursor and thus returns once the databases is updated.

And there's probably a ton of other options I did not mention, too.

I'm especially interested in recommendations based on real life experience...

Thanks!

Heiko

[Paul Williams]

Using a plugin to populate your config is a sane approach.

Hypnotoad supports zero downtime software upgrades (hot deployment), so I would probably trigger a hot deployment if the config changes (implementation down to you - use a job queue perhaps). This is *probably* the best way to do this because if the config contains database credentials or something that requires reconnecting to, you don't need to add any additional functionality to reconnect in your code.

Cheers.

[Tekki]

There was a similar discussion already on this forum (https://groups.google.com/forum/#!topic/mojolicious/T9uH9a14CHM). I copy from Ben van Staveren's answer: "Consider using memcache or another key/value store that's convenient (redis, perhaps) to store information like that, and fetch it when required."
The other question is, did you measure the impact on your application if you read from the db with every request? It's probably not as big as you think.