vivek807 opened a new issue, #19602:
URL: https://github.com/apache/druid/issues/19602
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:
```java
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:
```java
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
