Problem with the configuration reloading
PumpkinSeed opened this issue · 4 comments
There is an option (keepReloading) in the config/factory.go which is not working. If it is enabled it is create a go routine which reload the configuration, but this function called only once for me. So if I change the configuration and the application don't know its happened. You should create a channel for that which is listening for configuration changes and add this as a parameter for the NewConfig function.
Anyway, thank you for the nice tool.
It should be working, there is a test for this (and I have it running in prod).
What version of etcd are you using?
Just migrated the config factory to etcd v3 API.
I rewrote it to getting data from file, because currently we don't use etcd, but I am using the same for the keepReloading. What I missed the database configuration reload. (Frankly it is not so necessary for me, just noticed it is not working.)
When I start the service with runserver option it is call the cnf, db, err := initConfigDB(true, true) and with this data initialize the database. So the initConfigDB will return a db what the whole application are using. If I change the DB host in the config file, it won't affect to the application, because the db initialized when I started the service.
Please correct me if I misunderstood the code, and it is not a real issue, because I can make a systemctl restart service when changing the configuration. It will be problem when we start to use etcd., but I will figure out something.
Basically my solution, is opening the file every 10 second and read the configuration then load it into the struct.
@PumpkinSeed Nice work. I know that many people don't use etcd so I was thinking about making the config package more abstract to allow loading configuration from different sources (file, etcd etc). Feel free to submit your code as PR.
The point about database is correct. The database connection will only be started once. So that will not be updated if you update config on the fly. It would be probably a good idea to come up with some refactoring / different structure which would allow recreating a database connection if the configuration changes.