[
https://issues.apache.org/jira/browse/KNOX-2869?focusedWorklogId=843446&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-843446
]
ASF GitHub Bot logged work on KNOX-2869:
----------------------------------------
Author: ASF GitHub Bot
Created on: 03/Feb/23 10:40
Start Date: 03/Feb/23 10:40
Worklog Time Spent: 10m
Work Description: smolnar82 merged PR #722:
URL: https://github.com/apache/knox/pull/722
Issue Time Tracking
-------------------
Worklog Id: (was: 843446)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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)
