Hacker News Reader

Comment by candiddevmike | Hacker News Reader

Somewhat related, how are other gophers handling dynamic configuration in their go apps? Such as if the app is tied to consul or vault to get some config value. How do you handle the propagation of config changes cleanly, especially if it impacts something "big" like your DB pool? Do you have mutexes everywhere you read from the config pointer you pass around?

I noodled on this a while ago and figured it was easier to just restart the app on config changes than try to change things on the fly =D

View on HN

I don't use any of them services, but any config that has multiple readers and a single writer (who updates it when it changes) can just be protected by a sync.RWMutex.

The easiest thing to do would be to add a RWMutex to your Config struct. Then have public accessor methods which RLock the mutex while retrieving a field value.

Then when you want to update the config have something like a `Set(c Config)` method which allows you to overwrite the config stored in pointer. This Locks the RWMutex for writing of course.

viper, which nicely handles env vars, also can watch for config changes: https://github.com/spf13/viper#watching-and-re-reading-confi...

if you're rotating creds or need to open/close the DB, this will typically just add another select case to your main method, where you also block on e.g. signal catching to cleanly shutdown the app

Be aware that viper isn't thread safe. You'd still have to copy config by value and then put a mutex on that, then handle reads and writes separately.

https://github.com/spf13/viper#is-it-safe-to-concurrently-re...

atomic.Value can work pretty well as well, their example docs show how to do it as well: https://golang.org/pkg/sync/atomic/#example_Value_config

DBPool gets a bit more interesting. In Java world you can you providers that give you access to something, which is what middleware tends to do for Go. If you can have your middleware be able to swap the pool config its loading from, that should work just fine. atomic.Value make work here as well.

Just implement methods in your config struct in such a way that they are safe for concurrent access?! Using a mutex for example.

Why would you need it to lock mutexes everywhere?

> I noodled on this a while ago and figured it was easier to just restart the app on config changes than try to change things on the fly =D

I think this is generally the best approach, as it also applies some pressure for your application to be able to quickly shutdown and restart without affecting users - which is a desirable property to have for many other reasons too.

Usually http handlers or a database functions are pointer methods on some larger Service or DB struct type. If the config changes, you'd have a mutex within that struct and a method that safely modifies its state by locking and unlocking the mutex.

Why would you send pointer and not just a copy of a configuration? Configuration are usually simple things like url, threadpool size, strings etc ... there is no problem passing a copy of that.

Edit: not sure why I'm downvoted, I also think that reloading configuration is a bad idea anyway so you should pass immutable config.

Reply on news.ycombinator.com