Dynamic updates and hot reloading of config value changes in config sources

[TFaga]

Often configuration values are stored and retrieved from an external remote resource, server or service in order to better facilitate a central cohesive management of your environment. The result of this is that configuration values for a particular application/service are often changed on the external service.

Right now if an application uses the Configuration API it will not know if or when a particular configuration value was changed or updated. The change would eventually get detected the next time a particular configuration value was queried through the API (if it's not cached). However for values that are typically only read at startup, they may never get updated.

On top of updating the values when queried, we should have a relatively lightweight API to enable ConfigSources to notify the application using the Configuration API of any (or selected) config value changes that occur within the ConfigSource. The notification could be a simple CDI event we define or we can enable applications to register a listener in non CDI environments.

How updates are detected would be left to the ConfigSource implementation (polling, watches on files, ...).

The same API or functionality could be used to notify the application of updates when a config file changes, as discussed in #8 .

[Emily-Jiang]

Can you add your comments on #8, so that we can just discuss on one thread?

[TFaga]

No problem. Added.

[atsticks]

This is more complex as suggested. Letting a ConfigSource triggering an event directly for me makes no sense, because a ConfigSource does not know it a change of a value has any effect on the overall configuration, where a ConfigSource is included. We might think of a mechanism, where a ConfigSource can trigger a ChangeEvent for itself, so a Configuration can listen to the event and react as needed. Though using an SE approach there is nothing such as an event. So this scenario should be discussed as well.

[struberg]

Anatole, that's almost word for word what I wrote ;)

The point is that the ConfigSource must notify the Config itself. The Config then needs to re-evaluate the whole chain and compare it with the previous value. If changed -> send event to the user code.

We might think of a mechanism, where a ConfigSource can trigger a ChangeEvent for itself,
so a Configuration can listen to the event and react as needed.
Though using an SE approach there is nothing such as an event.

Of course there are ways in SE to do it. See my code example in #8.

/**
 * This callback should get invoked if an attribute change got detected
 */
default void setOnAttributeChange(Consumer<Set<String>> reportAttributeChange) {
     // do nothing by default. Just for compat with older ConfigSources.
}

After a ConfigSource gets picked up this method gets called by the Config, providing a callback function. And whenever a ConfigSource detects an attribute change it needs to invoke this very method.

[TFaga]

Yes agree. A ConfigSource itself should not be able to notify the application itself, which should be the responsibility of the main Config.

As was already mentioned and suggested in #8 such a mechanism could be made of two parts or APIs. The internal part or API, which the ConfigSources could use to notify the main Config implementation and the public user/application part or API, which the main Config could use to deliver the final notification. This way each ConfigSource is responsible for watching its config values and notifying the main Config, while the latter would be responsible for delivering the notification to the end user/application (or not) depending on whether its relevant or not. Higher order ConfigSources may override the value that was detected to change.

[struberg]

+1 @TFaga. When re-reading @atsticks mail I think he initially didn't fully get what I tried to express. But I think we are on the right track, given that he also ends up with basically the same approach - at least if I understood his mail correctly ;)

[kazumura]

I would like to know a real use case.

There are roughly three patterns:

(1) I can use the old value, even if the config value is changed.
(2) I want to use always a new value. But I don't care when it was changed.
(3) I want to use a new value immediately after the config value is changed.
This is very emergency. I don't want to miss a chance.

I can imagine (1) and (2), but not (3).

If there is so emergency case, you can use other mechanism such as messaging.
Why does Conig API need so emergency ?

I do not insist to consider about (3), but just want to know the use case.

[hendrikebbers]

@kazumura some use cases:

• You have a Websocket based endpoint on the server and want to integrate a feature toggle. If the feature toggle is active or deactivated should be defined in config. When the flag changes something should be send to a connected client.

• In a Java based client you want to change the font size. The font size is defined in the config. Once the config (like a property file) is changed the font size on the screen should change.

[atsticks]

(1) something where updating is not supported/wanted. Could be everything, normal case. (2) A background color. (3) A feature toggle or when I wan to disable some functionality or users, e.g. in case of frauds. 2017-10-31 11:34 GMT+01:00 Kenji Kazumura <[email protected]>:

…

I would like to know a real use case. There are roughly three patterns: (1) I can use the old value, even if the config value is changed. (2) I want to use always a new value. But I don't care when it was changed. (3) I want to use a new value immediately after the config value is changed. This is very emergency. I don't want to miss a chance. I can imagine (1) and (2), but not (3). If there is so emergency case, you can use other mechanism such as messaging. Why does Conig API need so emergency ? I do not insist to consider about (3), but just want to know the use case. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5sc4-atK4W0iqXeIn4FHBGWE3QEpcXks5sxveYgaJpZM4QJKTA> .

-- *Anatole Tresch* PPMC Member Apache Tamaya JCP Star Spec Lead *Switzerland, Europe Zurich, GMT+1* *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * *Twitter: @atsticks, @tamayaconf* *Speaking at:* [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]

[atsticks]

+1 My answers were dependent on the order of input (=issues) I have read ;-) 2017-10-31 11:17 GMT+01:00 Mark Struberg <[email protected]>:

…

+1 @TFaga <https://github.com/tfaga>. When re-reading @atsticks <https://github.com/atsticks> mail I think he initially didn't fully get what I tried to express. But I think we are on the right track, given that he also ends up with basically the same approach - at least if *I* understood *his* mail correctly ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5sc9Q3YgNabimJO2uF1pEViiAZ1ZBUks5sxvPHgaJpZM4QJKTA> .

-- *Anatole Tresch* PPMC Member Apache Tamaya JCP Star Spec Lead *Switzerland, Europe Zurich, GMT+1* *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * *Twitter: @atsticks, @tamayaconf* *Speaking at:* [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]

[kazumura]

@atsticks, @hendrikebbers
Thank you for use cases.
I understand these might be the cases.
But my question is using config is a best practice or not to achieve these features.
In case of the font, the usual steps are as follows:
(a) you interact with application to change the font
(b) application write a new value to the config
(c) application fire a paint event
(d) application receive the event, re-read the config, and re-paint.

If Config has the dynamic notification feature,
steps become as follows:
(a) you interact with application to change the font
(b) application write a new value to the config
(c) application are notified by Config, and application fire a paint event
(e) application receive the event, re-read the config, and re-paint.

Is the latter a better way?

[struberg]

I do agree with Kenji that the font example is probably not the best one. The page which requests the change could easily also send the notification. Regarding the socket change example. This is also not a real-time change. Even if you switch ports then it takes a while to get propagated over the cluster (especially in MicroServices). So you have a few seconds where both ports are around. And then it's also a matter of your firewall/router.The sane way to do this would be a ripple-start. 1.) Fire up a few instances with the new port. 2.) Change the port configuration3.) Wait for all the clients to pick this up (time doesn't really matter - could be 10 minutes)4.) shut down the old instances. My gut feeling tells me that here of course _are_ cases where notification is indeed useful. But the question is whether it is justified that we add the complexity right now or whether we can live without it for v1.0. Actually there are 2 questionsa.) do we like provide the active notification in v1.0 ? b.) do we like to provide better support for 'local caching with timeout' like the ConfigValue I posted? LieGrue,strub On Tuesday, 31 October 2017, 12:33:46 GMT+1, Kenji Kazumura <[email protected]> wrote: @atsticks, @hendrikebbers Thank you for use cases. I understand these might be the cases. But my question is using config is a best practice or not to achieve these features. In case of the font, the usual steps are as follows: (a) you interact with application to change the font (b) application write a new value to the config (c) application fire a paint event (d) application receive the event, re-read the config, and re-paint. If Config has the dynamic notification feature, steps become as follows: (a) you interact with application to change the font (b) application write a new value to the config (c) application are notified by Config, and application fire a paint event (e) application receive the event, re-read the config, and re-paint. Is the latter a better way? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[hendrikebbers]

About font: not in JFX ;) in Swing you can work with repaint, yes Von meinem iPhone gesendet

…

Am 31.10.2017 um 12:55 schrieb Mark Struberg ***@***.***>: I do agree with Kenji that the font example is probably not the best one. The page which requests the change could easily also send the notification. Regarding the socket change example. This is also not a real-time change. Even if you switch ports then it takes a while to get propagated over the cluster (especially in MicroServices). So you have a few seconds where both ports are around. And then it's also a matter of your firewall/router.The sane way to do this would be a ripple-start. 1.) Fire up a few instances with the new port. 2.) Change the port configuration3.) Wait for all the clients to pick this up (time doesn't really matter - could be 10 minutes)4.) shut down the old instances. My gut feeling tells me that here of course _are_ cases where notification is indeed useful. But the question is whether it is justified that we add the complexity right now or whether we can live without it for v1.0. Actually there are 2 questionsa.) do we like provide the active notification in v1.0 ? b.) do we like to provide better support for 'local caching with timeout' like the ConfigValue I posted? LieGrue,strub On Tuesday, 31 October 2017, 12:33:46 GMT+1, Kenji Kazumura ***@***.***> wrote: @atsticks, @hendrikebbers Thank you for use cases. I understand these might be the cases. But my question is using config is a best practice or not to achieve these features. In case of the font, the usual steps are as follows: (a) you interact with application to change the font (b) application write a new value to the config (c) application fire a paint event (d) application receive the event, re-read the config, and re-paint. If Config has the dynamic notification feature, steps become as follows: (a) you interact with application to change the font (b) application write a new value to the config (c) application are notified by Config, and application fire a paint event (e) application receive the event, re-read the config, and re-paint. Is the latter a better way? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Emily-Jiang]

Trying to catch up with the discussion. I think @kazumura listed the three situations:
(1) I can use the old value, even if the config value is changed.
(2) I want to use always a new value. But I don't care when it was changed.
(3) I want to use a new value immediately after the config value is changed.

for (3) basically not much waiting time is needed. In this case, reduce cache time might do the trick.
I can even think another scenario;
(4) I want to use the old value if the new value is not what I want. Basically you can choose what new value you want.
In this use case, maybe the configured value is not valid etc. I can continue functioning with the old value until a better value is provided.

I have been thinking about the event notification solution.

1. We need to compute the config and then cache it.
2. For a pre-configured time period, go back to check the config sources again
3. calculate the value again.
4. Compare this value with old value and then fire events.

Let's not prebake any solution as yet. We might come up with a simple solution.

[atsticks]

+1 the proposal for caching and comparing configs regularly exactly matches what Tamaya does in its event module... Am 31.10.2017 15:58 schrieb "Emily Jiang" <[email protected]>: Trying to catch up with the discussion. I think @kazumura <https://github.com/kazumura> listed the three situations: (1) I can use the old value, even if the config value is changed. (2) I want to use always a new value. But I don't care when it was changed. (3) I want to use a new value immediately after the config value is changed. for (3) basically not much waiting time is needed. In this case, reduce cache time might do the trick. I can even think another scenario; (4) I want to use the old value if the new value is not what I want. Basically you can choose what new value you want. In this use case, maybe the configured value is not valid etc. I can continue functioning with the old value until a better value is provided. I have been thinking about the event notification solution. 1. We need to compute the config and then cache it. 2. For a pre-configured time period, go back to check the config sources again 3. calculate the value again. 4. Compare this value with old value and then fire events. Let's not prebake any solution as yet. We might come up with a simple solution. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5sc7fkevL64sIKZ52UjUMI7OMQgHfLks5sxzWegaJpZM4QJKTA> .

[lilian-benoit]

Sorry but for me toggle feature and background aren't good use case.

• Toggle feature is more complex than active / deactivate a feature.
• Background is more concept of preference that configuration.

I prefer Mark's use case with changing port.

Also, this use case show that event should fire when config changed.

Any more, what happens if we have two modified properties? for example hostname and port number.
We have two events ?

[Emily-Jiang]

Each property will trigger a event. The event body should be the property name and value.

[TFaga]

+1 for aiming towards a simple solution.

Notifications would mostly be used when the end user/application would need to explicitly react to a config value change. I've had a case where multiple microservices logger configuration was stored on an external service (consul in my case, which natively supports watches, so we didn't want to do custom polling). And we needed to trigger logger reconfiguration in the code as part of the config updating. These kind of use cases, however, are usually not so common, so if we add watches/notifications they should probably be on an opt-in basis per value, as well as try to keep them simple from the API perspective.

Other config value changes would most likely be sufficiently resolved the next time the application queries the config value as was already mentioned. A configurable cache policy would help to fine tune the rate of refreshes.

[jmesnil]

Is there an actual use case for (3)?

If I want to use the value immediately after it is changed, I'd better not cache it at all and call Config.getValue() every time I need to know its value.

[jmesnil]

I am not a CDI expert so sorry in advance if I'm proposing something stupid but isn't the CDI API we have enough for application to be notified of config value changes?
If I annotate a Consumer<T> function with a @ConfigProperty parameter, couldn't the implementation calls the consumer whenever the value is changed? For example:

 void myFunction(@ConfigProperty(name = "foo", defaultValue = "bar") String foo) {
  // called when the value of the "foo" property is changed
 }

If I want to get an initial value when my app is deployed and be notified of any change, I just need to annotate a property and a parameter:

// injected at deployment time, provide an initial value
@Inject
@ConfigProperty(name = "foo", defaultValue = "bar")
String foo;

// called whenver the foo property is changed
void observeFoo(@ConfigProperty(name = "foo") String foo) {
}

That's for the CDI use case.

For the plain Config API, we coud add a getValue(String, Consumer<T>) that is called whenever the config detects a change in the configuration value. It would then be used like:

config.getValue("foo", (Consumer<String>) prop -> {
   System.out.println("prop = " + prop);
 });

[struberg]

we will need a CDI observer plus a SE way to register an Observer.

[jmesnil]

@struberg right. my comment was focusing on the Config API that the user is facing.

We will need to have observers for the SPI so that ConfigSource can notify the Config of some events but I don't see the need to include an Observer pattern in the user API.

[struberg]

@jmesnil was talking about the user facing Config part as well.

[atsticks]

@struberg Regarding useConverter, my point was adding something like the following to the Config interface:
<T> T getValue(String key, Converter<T> converter);
<T> Optional<T> getOptionalValue(String key, Converter<T> converter);

Despite adding another method to the API, why this should be an issue?

[atsticks]

From my original point the following I think is the most important:

I think it would be more logical to define the lookup chain, when accessing the ConfigValue from the Config, instead of creating another ConfigValue with a different lookup chain from a ConfigValue.

[atsticks]

+1 for adding a latest changed timestamp to the Config interface. It would make it easy to detect changes from (ConfigValue, Config) instance implementations, by simply polling and checking for value changes. When a change has been detected, the values can be read and listeners be informed.

[OndroMih]

Here are fixed links from @struberg:

https://github.com/apache/deltaspike/blob/11e1cf724a0e40949882ab09bd5f57ad50a509c2/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/ConfigImpl.java#L49
https://github.com/apache/deltaspike/blob/11e1cf724a0e40949882ab09bd5f57ad50a509c2/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/ConfigImpl.java#L202

https://github.com/apache/deltaspike/blob/04cf7acd667d27ed8faebb6c1668a98ca7aa92a8/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/TypedResolverImpl.java#L220

[struberg]

I think we can consider this as closed, right?

Smallish improvements as separate tickets please!