-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hot reloading of configuration #103
Comments
I think there are generally 2 approaches to this problem;
It doesn't touch the issue of potentially dropping messages, however there are numerous other cases (reconnects) where that could happen, so I think that could be treated separately. Feedback on the idea and proposed options would be useful! |
This issue has been automatically closed as stale. This mechanism helps to prioritize feature requests which received more support from the community. If you want to open again this issue you have to provide a Pull Request. |
Hi @DamianZaremba, I implemented your proposal n.2 here: #273. It will probably go out with the next release. The status of the application is persisted now. Thanks for your feedback. |
That looks great, thanks for taking care of this @massimocandela! |
Hi Damian, in the end I implemented also a hot reloading in case of changes in prefixes.yml |
That's great. I did notice a side effect of 'restart while persisting alerts' being that the new release notifications are either super spammy (notify on startup) or never triggered (if restarting faster than 5 days)... so this is hopefully a better solution for my setup :) |
Hey Damian, could you elaborate? Thanks Ciao, |
Hey, sure; When you have a configuration with When For my specific use case disabling the Now there is the option of hot reloading I'm trying the current dev branch with Hopefully that makes sense. |
Describe what you would like to achieve
Currently the configuration is only read on startup, changing the monitored prefixes requires restarting the instance.
In an environment which has many prefix monitors, the configuration of which change in a relatively dynamic manner this requires restarting the process very regularly (hourly/daily) interval.
Describe why the current solution (if any) is not satisfactory
Provide an example
Start the instance with a prefixes.yml;
Once running update prefixes.yml;
No new prefixes will be subscribed to, any withdrawals, announcements etc will not be notified.
Your information
@DamianZaremba, Fastly / Infra Bits
The text was updated successfully, but these errors were encountered: