apache/seatunnel · warning

Continuous discovery scheduler does not terminate in 5 secon

Error message

Continuous discovery scheduler does not terminate in 5 seconds.

What it means

During close(), the enumerator shuts down its scheduled continuous-discovery executor and waits up to 5 seconds for termination via awaitTermination. If the scheduler has not terminated within that window, this warning is logged and close() proceeds anyway. It indicates a scan task is still running (possibly blocked on slow filesystem I/O) and may have been interrupted mid-flight by shutdownNow.

Source

Thrown at seatunnel-connectors-v2/connector-file/connector-file-base/src/main/java/org/apache/seatunnel/connectors/seatunnel/file/source/split/ContinuousMultipleTableFileSourceSplitEnumerator.java:226

                this::safeScanOnce,
                0L,
                Math.max(1L, scanInterval.toMillis()),
                TimeUnit.MILLISECONDS);
    }

    @Override
    public void run() {
        // Assign splits on demand via handleSplitRequest.
    }

    @Override
    public void close() throws IOException {
        closed = true;
        if (scheduler != null) {
            scheduler.shutdownNow();
            try {
                if (!scheduler.awaitTermination(5, TimeUnit.SECONDS)) {
                    log.warn("Continuous discovery scheduler does not terminate in 5 seconds.");
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
        for (TableScanContext ctx : tableScanContexts) {
            ctx.close();
        }
    }

    @Override
    public void addSplitsBack(List<FileSourceSplit> splits, int subtaskId) {
        if (splits == null || splits.isEmpty()) {
            return;
        }
        synchronized (lock) {
            for (FileSourceSplit split : splits) {
                inFlightSplits.remove(split);

View on GitHub (pinned to cf67b549a7)

Solutions

1. Investigate why scans are slow: check filesystem/network health and scan interval settings
2. Ensure scanOnce does not block indefinitely (add timeouts to filesystem operations)
3. If the warning recurs at shutdown only and no corruption occurs, it can be treated as benign and ignored

try {
    scheduler.awaitTermination(5, TimeUnit.SECONDS);
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
}
// if awaitTermination returned false, log and continue; check for stuck FS operations

When it happens

Trigger: Calling close() while a scanOnce is running and taking longer than 5 seconds — e.g. a stuck or very slow directory listing against a remote filesystem, or a task ignoring interruption.

Common situations: Job cancellation/restart while a continuous file discovery scan is in progress against slow or hanging HDFS/S3; network stalls making filesystem metadata calls block longer than the 5s grace period.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

• Timed out waiting for http report scheduler to stop
• Scheduler timed out during close; up to {} ringbuffer event(
• WALDisruptor close timeout error
• Failed to close the source reader in {} ms. There are still
• Edge socket receiver executor did not terminate within timeo

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/b1b39c2b7bb7e7e2. Report an issue: GitHub.