github-actions[bot] commented on code in PR #69683:
URL: https://github.com/apache/doris/pull/69683#discussion_r4399902706
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/scan/FileQueryScanNode.java:
##########
@@ -418,7 +418,9 @@ public void createScanRangeLocations() throws UserException
{
splitAssignment = new SplitAssignment(backendPolicy, this,
this::splitToScanRange,
locationProperties, pathPartitionKeys, admissionResult,
sessionVariable.getSplitBatchSize(),
sessionVariable.getSplitQueueCapacity());
- splitAssignment.init();
+ // The first split can require a remote read session (for example,
MaxCompute). Keep
+ // the planning wait bounded by the query's effective timeout
instead of a fixed 30 seconds.
+ splitAssignment.init(ConnectContext.get().getExecTimeoutS() *
1000L);
Review Comment:
[P2] Stop the first-split planning wait when the query is cancelled
When a producer is already inside a slow Hive listing or MaxCompute
read-session call, `KILL QUERY` closes its task group but leaves the running
`SplitProducer` untouched: `FairTaskExecutor.Group.close()` only cancels
running `Future` tasks, while this producer is a plain `Runnable`. There is no
coordinator yet, and `this::stop` is registered only for query finish, so
`needMoreSplit()` stays true and `init()` keeps the planning thread waiting
after cancellation. This extends the former 30-second upper bound to the full
query timeout (900 seconds by default). Register scan/assignment stop with the
executor's cancellation callback, or check cancellation during this wait, and
cover cancellation while the first producer is running.
--
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]
