Provide a way for verticles to reload configuration upon changes

[cut-to-the-cheese]

As per documentation for config retriever listening for changes, the retriever reloads the configuration every 5 seconds. Issue is that there is no way provide that new configuration to the verticle without first undeploying and redeploying it with the new configuration or doing a app/pod restart. The reason for that is the config JsonObject that holds the configuration for the verticle is created via new constructor and there is no reference to this config object available. This functionality will be really helpful where API keys and certs are being rotated out and live traffic is being taken by the app.

[vietj]

can you provide an example of how this would ideally be achieved ?

[cescoffier]

I have recently extended the documentation to explain how the new configuration can be sent on the event bus and so let individual verticles "apply" the new configuration (section Propagating configuration changes to the event bus in the doc). I strongly recommend using the event bus to notify the interested verticles with the new configuration. Then, each verticle is on its own and do what's need to be done.

Notice that dynamically applying a new configuration may introduce downtime. For instance, changing the HTTP port of a server requires stopping the first one and restarting it.

[vietj]

thanks for the explanation @cescoffier

[cut-to-the-cheese]

Hi thank you for quick responses. I am unable to find Propagating configuration changes to the event bus anywhere. Can you please link to that? Thank you

[rodolfodpk]

While I understand using ConfigRetriever.listen can be used to propagate config changes to many verticles and other components (and it is probably the right way), it would be nice to inform the ConfigRetriever to simply relaunch the main verticle / full application. I usually have this in my main verticle:
public static void main(String[] args) { Launcher.executeCommand("run", MyMainVerticle.class.getName()); }
and I wonder if it could work. Between some downtime on config changes and a simpler immutable app model I do prefer the latter. And if it could work with native apps (Quarkus and Graal), the downtime would be almost invisible.