support reloading the config dynamically?

[derhuerst]

It would be helpful for development to reload both application.properties and feedproviders.yml upon developer request, e.g. using SIGHUP:

Many daemons (who have no controlling terminal) interpret receipt of this signal as a request to reload their configuration files […] instead of exiting.

https://en.wikipedia.org/wiki/Signal_(IPC)#SIGHUP

Edit: I think this would be useful in either a local development environment (where one often modifies the config/set of feeds), as well as in a production environment (where the set of feeds is managed by/from another service).

What do you think?

After some very naive research (I don't know the Spring ecosystem at all), I stumbled upon a StackOverflow answer that mentions that one should be careful when implementing this.

[testower]

What is the use case for hot reloading application.properties? I seriously doubt we will support it.

As for reloading feedproviders.yml, now that's a feature request I can understand. However, there are some open questions about how the feature should work.

E.g. should the entire file be reread, and all subscriptions be re-established (and if that is the case, we must consider if the added complexity is worth it compared to just restarting the application with a new file).

Alternatively, should we look for changes in the file, and only update those that have changed, removed those that are gone, and add new ones?

It's starting to look like a non-trivial task.

I'm not convinced SIGHUP is the appropriate way to trigger it either. We do have an admin api (behind basic http auth) - we could use that.

[derhuerst]

What is the use case for hot reloading application.properties?

I'd say local development, and production environments where the set of feeds is managed by/from another service.

But yeah, it probably involves a lot of complexity. Your call if it's worth it!

I'm not convinced SIGHUP is the appropriate way to trigger it either. We do have an admin api (behind basic http auth) - we could use that.

Although its original purpose (and its purpose in interactive sessions) is definitely a different one, SIGHUP is supported by many daemons in the Unix ecosystem. The HTTP API is of course technically cleaner, but proprietary.

[testower]

Just to reiterate that reloading of application.properties and feedproviders.yml are completely different topics.

[derhuerst]

Just to reiterate that reloading of application.properties and feedproviders.yml are completely different topics.

True, but if I (re)load a new config that contains a path to a different feedproviders.yml, then the set of feeds needs to be updated as well, right?

[testower]

The point being, we won't support reloading of application.properties, so if ever you want to change the path of the feedproviders.yml, you'll have to restart the application.

[derhuerst]

Does the same apply to feedproviders.yml?

[testower]

I'm open to discussing support for reload feedproviders.yml. Please have a look at my questions above. What is the use case for it? That will lead the discussion of what the feature actually is.

[testower]

where the set of feeds is managed by/from another service

Is this the use case?