u70b3 commented on code in PR #66637: URL: https://github.com/apache/doris/pull/66637#discussion_r3819287366
########## fe/fe-core/src/main/java/org/apache/doris/datasource/lance/LanceMetadataReadExecutor.java: ########## @@ -0,0 +1,139 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +package org.apache.doris.datasource.lance; + +import org.apache.doris.common.ThreadPoolManager; +import org.apache.doris.qe.ConnectContext; + +import com.google.common.annotations.VisibleForTesting; + +import java.util.Locale; +import java.util.concurrent.Callable; +import java.util.concurrent.ExecutionException; +import java.util.concurrent.ExecutorService; +import java.util.concurrent.Future; +import java.util.concurrent.RejectedExecutionException; +import java.util.concurrent.ThreadPoolExecutor; +import java.util.concurrent.TimeUnit; +import java.util.concurrent.TimeoutException; + +/** Runs Lance JNI metadata reads behind a finite FE concurrency and deadline boundary. */ +final class LanceMetadataReadExecutor { + private static final int DEFAULT_TIMEOUT_SECONDS = 60; + private static final int MAX_CONCURRENT_READS = 4; + private static final int MAX_QUEUED_READS = 16; + private static final ThreadPoolExecutor EXECUTOR = ThreadPoolManager.newDaemonFixedThreadPool( + MAX_CONCURRENT_READS, + MAX_QUEUED_READS, + "lance-metadata-read", + false, + new ThreadPoolExecutor.AbortPolicy()); + + private LanceMetadataReadExecutor() { + } + + static <T> T execute(Callable<T> task) throws Exception { + ConnectContext context = ConnectContext.get(); + int queryTimeoutSeconds = context == null + ? DEFAULT_TIMEOUT_SECONDS : context.getQueryTimeoutS(); + int timeoutSeconds = queryTimeoutSeconds > 0 + ? Math.min(queryTimeoutSeconds, DEFAULT_TIMEOUT_SECONDS) : DEFAULT_TIMEOUT_SECONDS; + return execute(task, EXECUTOR, timeoutSeconds, TimeUnit.SECONDS); + } + + @VisibleForTesting + static <T> T execute(Callable<T> task, ExecutorService executor, + long timeout, TimeUnit timeoutUnit) throws Exception { + if (timeout <= 0) { + throw new IllegalArgumentException("Lance metadata read timeout must be positive"); + } + long timeoutNanos = timeoutUnit.toNanos(timeout); + if (timeoutNanos <= 0) { + throw new IllegalArgumentException("Lance metadata read timeout is too small"); + } + + long deadlineNanos = System.nanoTime() + timeoutNanos; + Future<T> future; + try { + future = executor.submit(() -> { + // A request can expire while waiting in the finite queue. Do not enter JNI for a + // result whose caller has already timed out. + if (remainingNanos(deadlineNanos) <= 0) { + throw timeoutFailure(timeout, timeoutUnit); + } + return task.call(); + }); + } catch (RejectedExecutionException e) { + throw new MetadataReadCapacityException( + "Lance metadata read capacity is exhausted"); + } + + try { + long remainingNanos = remainingNanos(deadlineNanos); + if (remainingNanos <= 0) { + throw timeoutFailure(timeout, timeoutUnit); + } + return future.get(remainingNanos, TimeUnit.NANOSECONDS); + } catch (TimeoutException e) { + // Deliberately do not cancel or interrupt the Future. If JNI has started, the worker + // remains the sole owner of its Dataset and allocator until the native call returns. Review Comment: Good question — this boundary is the trade-off the pool is built around. Short answer: temporary exhaustion under pathological storage failure is possible and intentional (bounded fail-fast); permanent exhaustion is not, and cancelling the Future would change neither. **Why cancelling doesn't help.** `cancel(true)` only delivers `Thread.interrupt()`. The worker is blocked inside a synchronous JNI call; the Lance native runtime does not observe Java interrupts, so the thread stays occupied until the native call returns regardless. Cancellation would only flip the Future's state while the worker — the sole owner of the Dataset and its task-scoped 256MB allocator — is still running, re-introducing the ownership race this boundary exists to prevent. It doesn't even free the queue slot: a cancelled FutureTask stays in the queue until a worker dequeues it. **Why the pool still recovers.** A stuck native call is already time-bounded inside the pinned SDK (lance-core 9.1.0-beta.3 → object_store 0.13.2): every S3 attempt terminates via `connect_timeout=5s` / `timeout=30s` defaults, and the retry loop stops at `max_retries=3` or `retry_timeout=180s` elapsed. So one object-store op returns in ≲3.5 min even against an endpoint that hangs every request, and one SHOW INDEX task issues only a bounded number of such ops (describeIndices reads the already-open snapshot's manifest). Worst-case worker occupancy is minutes, not forever; expired queued tasks then fail before entering JNI and the pool drains within one deadline. **What users see during that window.** Submissions beyond 4 running + 16 queued fail immediately with `MetadataReadCapacityException` — deliberate fail-fast backpressure rather than unbounded queuing (each in-flight task owns a 256MB Arrow allocator, so an unbounded pool is a native-memory risk). The waiting caller is bounded by min(query_timeout, 60s), and the blast radius is limited to Lance metadata reads on this FE; query execution and other catalogs never touch this pool. Residual risk I consider acceptable: `file://` datasets on a hung filesystem (NFS hard mount) can pin a worker indefinitely — local disk I/O has no timeout, and no pool design, cancellation included, can reclaim a thread in uninterruptible sleep. If you prefer a tighter bound, we can pass an explicit `client_retry_timeout` (e.g. 30s) with the SHOW INDEX read options as a Doris-side default, so a stuck worker returns within roughly the caller deadline instead of the 180s SDK default. WDYT? -- 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]
