[ https://issues.apache.org/jira/browse/KNOX-2869?focusedWorklogId=843242&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-843242 ]
ASF GitHub Bot logged work on KNOX-2869: ---------------------------------------- Author: ASF GitHub Bot Created on: 02/Feb/23 14:05 Start Date: 02/Feb/23 14:05 Worklog Time Spent: 10m Work Description: smolnar82 opened a new pull request, #722: URL: https://github.com/apache/knox/pull/722 ## What changes were proposed in this pull request? As described in the corresponding JIRA, Knox should handle the situation when a previously stored CM discovery config file exists, but it's empty. This may prevent the Knox Gateway from starting up. ## How was this patch tested? Added new JUnit test cases to cover this event and ran manual testing: - Stopped the Knox GW in a cluster where I had descriptors with CM service discovery enabled - truncted the `$KNOX_GW_DATA_DIR/cm_clusters/xyz.conf` file - restarted the Knox Gateway Prior to my changes, the Knox GW did not start; After my fix, everything is working as expected. Issue Time Tracking ------------------- Worklog Id: (was: 843242) Remaining Estimate: 0h Time Spent: 10m > Possible NPE at CM cluster configuration monitor startup > -------------------------------------------------------- > > Key: KNOX-2869 > URL: https://issues.apache.org/jira/browse/KNOX-2869 > Project: Apache Knox > Issue Type: Bug > Affects Versions: 2.0.0 > Reporter: Sandor Molnar > Assignee: Sandor Molnar > Priority: Major > Fix For: 2.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > In some very rare cases, it could happen that CM service discovery-related > configuration file(s) were wrongly serialized on the file system and the next > time Knox starts the service initialization fails like this: > {noformat} > 2023-01-30 10:39:01,733 FATAL knox.gateway (GatewayServer.java:main(193)) - > Failed to start gateway: java.lang.NullPointerException > java.lang.NullPointerException > at > java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1690) > at > org.apache.knox.gateway.topology.discovery.cm.monitor.ClusterConfigurationCache.addDiscoveryConfig(ClusterConfigurationCache.java:73) > at > org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.loadDiscoveryConfiguration(ClouderaManagerClusterConfigurationMonitor.java:186) > at > org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitor.<init>(ClouderaManagerClusterConfigurationMonitor.java:100) > at > org.apache.knox.gateway.topology.discovery.cm.monitor.ClouderaManagerClusterConfigurationMonitorProvider.newInstance(ClouderaManagerClusterConfigurationMonitorProvider.java:35) > at > org.apache.knox.gateway.services.topology.impl.DefaultClusterConfigurationMonitorService.init(DefaultClusterConfigurationMonitorService.java:44) > at > org.apache.knox.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:137) > at org.apache.knox.gateway.GatewayServer.main(GatewayServer.java:184) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.apache.knox.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:68) > at org.apache.knox.gateway.launcher.Invoker.invoke(Invoker.java:39) > at org.apache.knox.gateway.launcher.Command.run(Command.java:99) > at org.apache.knox.gateway.launcher.Launcher.run(Launcher.java:75) > at > org.apache.knox.gateway.launcher.Launcher.main(Launcher.java:52){noformat} > In this particular case, the > {{$KNOX_DATA_DIR/cm-clusters/hCM_HOST_7183-Cluster_1.conf}} file was empty so > when Knox wanted to load any previously-persisted discovery configuration > data into its own in-memory cache, an NPE was thrown. > Although the chance for this to happen is quite low, Knox should handle this > situation better. -- This message was sent by Atlassian Jira (v8.20.10#820010)