SqlSegmentsMetadataManager: forceOrWaitOngoingDatabasePoll compares System.nanoTime() against converted System.currentTimeMillis(), always skipping fresh on-demand poll detection

[vivek807]

SqlSegmentsMetadataManager: forceOrWaitOngoingDatabasePoll compares System.nanoTime() against converted System.currentTimeMillis(), always skipping fresh on-demand poll detection

Bug

forceOrWaitOngoingDatabasePoll in SqlSegmentsMetadataManager contains an invalid clock comparison when checking whether a recent OnDemandDatabasePoll makes a new poll unnecessary.

Affected version(s)

Reproducible on current master.

Root cause

OnDemandDatabasePoll.initiationTimeNanos is set via System.nanoTime() — a monotonic clock with an arbitrary JVM-internal reference point. Values are typically in the range of a few seconds to minutes in nanoseconds from JVM startup.

The staleness check constructs its comparison value as:

long checkStartTimeNanos = TimeUnit.MILLISECONDS.toNanos(checkStartTime);
// where checkStartTime = System.currentTimeMillis() 

System.currentTimeMillis() returns milliseconds since the Unix epoch. Converting that to nanoseconds yields many orders of magnitude larger than any value returned by System.nanoTime().

As a result, the condition:

if (latestOnDemandPoll.initiationTimeNanos > checkStartTimeNanos)  

is always false. A concurrent on-demand poll that completed while the calling thread was waiting for the write lock is never recognised as sufficient, so forceOrWaitOngoingDatabasePoll always triggers an additional unnecessary poll.

Impact

Every call to forceOrWaitOngoingDatabasePoll that races with an in-progress OnDemandDatabasePoll performs a redundant full database poll instead of reusing the result of the concurrent one. Under high coordinator leadership-change frequency this can cause extra load on the metadata store.