0👍
I am pretty sure your given code comes close to what is already conjured up by the writers of the Logging module itself.
You use a separate thread in your program that listens for configuration requests every time a logging event occurs. The logging server, in turn, holds the configuration file(s) which you can adapt. Changes will be picked up on the next logging event.
The original author of the Logger module might provide you with more insight here, do note that this manual is a bit outdated. The official Python docs for Logging has an example of configuring such a Logging server/client setup: Logging Cookbook.
And, as is always the case when complexity rises, such a setup does have a slight performance impact.
0👍
I wrote an application to solve this problem. the configuration is in the database, and many configurations can be saved, with exactly only one active at a configurable date/time.
to solve the problem of reloading a new config uppon change, I created 3 policy to propagate a new config:
- listen to signal for config model change and update the config (work in mono process env)
- check new config every minutes with thread (like your code)
- listen to signal for config change but propagate the event via a amqp message backend. (this is the most optimised solution).