Hi Igniters,
while investigating an issue on Ignite 2.18, I came across what looks
like a bug in TcpDiscoverySharedFsIpFinder.
Our setup uses TcpDiscoverySharedFsIpFinder with a Ceph-backed shared
filesystem. During a temporary Ceph outage, the following exception was
logged:
java.lang.NullPointerException: Cannot read the array length because
"[local2]" is null
at
org.apache.ignite.spi.discovery.tcp.ipfinder.sharedfs.TcpDiscoverySharedFsIpFinder.getRegisteredAddresses(TcpDiscoverySharedFsIpFinder.java:189)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1980)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$IpFinderCleaner.cleanIpFinder(ServerImpl.java:2280)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$IpFinderCleaner.body(ServerImpl.java:2255)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
Looking at the source code, getRegisteredAddresses() iterates over the
result of File.list()without checking for null.
According to the JDK API, this method may return null if an I/O error
occurs (for example, when the shared filesystem is temporarily
unavailable). In this situation, a NullPointerException is thrown
instead of an IgniteSpiException.
My questions are:
1. Is this considered a bug in Ignite?
2. Is the IpFinderCleaner thread expected to terminate permanently
after such an uncaught exception, or is it restarted automatically?
3. Would a simple null check that converts this condition into an
IgniteSpiException be an acceptable fix?
The cluster itself continued to operate after the shared filesystem
became available again, but I am concerned that the IpFinderCleaner may
no longer remove stale entries from the SharedFS IP Finder after this
happens.
Has anyone encountered this before, or is there already a fix or Jira
issue for this?
Thanks in advance!
