Hot-reload and refresh dependencies on the DataSource section #2323
Assignees
Labels
Milestone
Comments
aaronburtle
added
the
🔥Hot Reload
aaronburtle
added a commit
that referenced
this issue
Oct 11, 2024
## Why make this change? closes #2415 Relates to #67 Relates to #2323 Relates to #1869 This change adds event handling for the dependencies which are set during startup, and refreshing their internal state to match the states that are updated during a hot-reload. In order to help facilitate the final portions of the configuration file which need to be handled in hot-reload scenarios, we need these dependencies to be updated without any stale values from before the hot-reload. And we enforce an order of this update to make sure that if B depends on A, that the refresh happens first with A, then with B. ## What is this change? There are a number of classes which are instantiated and registered with the Service Provider on startup using values that depend on the 'RuntimeConfig'. These are registered as singletons. Therefore, during a hot-reload scenario, we need to update those states because the 'RuntimeConfig' has changed, and the values that those objects were instantiated with are now potentially stale. To handle this updating, when one of these singleton services is constructed, we subscribe an update function with an Event Handler that is provided to the constructor. We also save internally any arguments provided to the constructor that were needed during construction so that they will be available and usable during the updating. The RuntimeConfig Loader then sequentially sends notifications for all of these subscribed events to inform them of the hot-reload process. This happens in a single function with a single thread so that the order of operation is enforced, with the thread executing each update one at a time. Note that we save the handler internally in some of the classes that we will be calling back to do configurations during hot-reload. Generally speaking, this happens in the factory classes when their re-configuration during hot-reload requires them to create other classes that will need to be re-configured during a hot-reload. Those classes then need to have a handler provided to their constructor so that they can properly subscribe to hot-reload events. ## How was this tested? Manually verified the updating process by modifying the config while DAB is running and then verifying that the dependent objects successfully refresh to match the new values in the config, and do so in the desired order. The following issue tracks specifically testing this behavior: #2416 ## Sample Request(s) Any change to the config used on startup will demonstrate the hot-reload functionality added in this PR. --------- Co-authored-by: Sean Leonard <[email protected]>
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We can currently deserialize and store the new values for the DataSource during a hot-reload scenario, however the dependencies that rely on the DataSource section during startup are not being refreshed. This task is to add that refreshing logic for the many components that are configured on startup and depend on the DataSource
The text was updated successfully, but these errors were encountered: