[
https://issues.apache.org/jira/browse/KNOX-2900?focusedWorklogId=1048532&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1048532
]
ASF GitHub Bot logged work on KNOX-2900:
----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Oct/26 17:17
Start Date: 20/Oct/26 17:17
Worklog Time Spent: 10m
Work Description: bonampak commented on code in PR #1395:
URL: https://github.com/apache/knox/pull/1395#discussion_r4327981269
##########
gateway-discovery-cm/src/main/java/org/apache/knox/gateway/topology/discovery/cm/monitor/PollingConfigurationAnalyzer.java:
##########
@@ -340,25 +344,31 @@ private boolean hasConfigChanged(String address, String
clusterName, List<Releva
// Get the previously-recorded configuration
ServiceConfigurationModel serviceConfig =
serviceConfigurations.get(re.getServiceType());
- if (serviceConfig != null) {
- // Get the current config for the started service, and compare with
the previously-recorded config
- ServiceConfigurationModel currentConfig =
- getCurrentServiceConfiguration(address, clusterName,
re.getService());
-
- if (currentConfig != null) {
- log.analyzingCurrentServiceConfiguration(re.getService());
- try {
- configHasChanged = hasConfigurationChanged(serviceConfig,
currentConfig);
- } catch (Exception e) {
- log.errorAnalyzingCurrentServiceConfiguration(re.getService(),
e);
- }
+ // Get the current (model-derived) config for the started service.
This is null when the service produces no
+ // model (e.g. invalid configuration), just as such a service is
absent from the recorded baseline.
+ ServiceConfigurationModel currentConfig =
+ getCurrentServiceConfiguration(address, clusterName,
re.getService(), re.getServiceType());
+
+ if (serviceConfig == null && currentConfig == null) {
+ // Was and remains in an invalid configuration state (no model
either time): nothing to proxy, no change.
+ log.skippingConfigChangeForInvalidService(re.getService(),
re.getServiceType());
+ } else if (serviceConfig != null && currentConfig != null) {
+ // Valid before and now: compare the recorded and current configs to
detect a change.
+ log.analyzingCurrentServiceConfiguration(re.getService());
+ try {
+ configHasChanged = hasConfigurationChanged(serviceConfig,
currentConfig);
+ } catch (Exception e) {
+ log.errorAnalyzingCurrentServiceConfiguration(re.getService(), e);
}
- } else {
- // A new service (no prior config) represent a config change, since
a descriptor may have referenced
- // the "new" service, but discovery had previously not succeeded
because the service had not been
- // configured (appropriately) at that time.
+ } else if (currentConfig != null) {
+ // No prior config, but the service now produces a model: new /
became valid -> re-discover.
log.serviceEnabled(re.getService());
configHasChanged = true;
+ } else {
+ // Had a prior config but produces no model now: became invalid /
was removed -> re-discover so the
+ // service is dropped from the affected topologies (and the
scoped-replace merge clears its baseline).
+ log.serviceDisabled(re.getService());
+ configHasChanged = true;
Review Comment:
Fixed by
- 4b0c34209 returns a three-state result so an unreachable CM no longer
forces a rediscovery
- 37f71bfdb adds the tests.
One limitation, which also existed on master: after an error the event is
still marked processed,
so a real change that coincides with an outage isn't retried until another
event arrives. It is not a regression.
I'd create a follow-up ticket for that.
Issue Time Tracking
-------------------
Worklog Id: (was: 1048532)
Time Spent: 50m (was: 40m)
> KNOX-2899 followup - reenable service based discovery filter
> ------------------------------------------------------------
>
> Key: KNOX-2900
> URL: https://issues.apache.org/jira/browse/KNOX-2900
> Project: Apache Knox
> Issue Type: Task
> Reporter: Attila Magyar
> Assignee: Tamás Marcinkovics
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In KNOX-2899 the service based discovery filter was temporary disabled
> because it interferes with the polling configurator analyzer.
> * Either a permanent fix is needed that works well with the polling config
> analyizer
> * Or the filter should be permanently removed, if the performance gain would
> be negligible
> cc: [~smolnar]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
