http://starrocks.io logo
Join Slack
Powered by
z
I have error
@Rocky java.lang.NullPointerException: Cannot invoke "java.util.List.iterator()" because the return value of "com.starrocks.qe.scheduler.dag.JobSpec.getScanNodes()" is null at com.starrocks.qe.DefaultCoordinator.clearExternalResources(DefaultCoordinator.java:1057) ~[starrocks-fe.jar:?] at com.starrocks.qe.DefaultCoordinator.cancelInternal(DefaultCoordinator.java:1029) ~[starrocks-fe.jar:?] at com.starrocks.qe.DefaultCoordinator.updateStatus(DefaultCoordinator.java:889) ~[starrocks-fe.jar:?] at com.starrocks.qe.DefaultCoordinator.updateRuntimeProfile(DefaultCoordinator.java:1199) ~[starrocks-fe.jar:?] at com.starrocks.qe.DefaultCoordinator.lambda$updateFragmentExecStatus$7(DefaultCoordinator.java:1130) ~[starrocks-fe.jar:?] at java.util.concurrent.CompletableFuture.uniRunNow(CompletableFuture.java:819) ~[?:?] at java.util.concurrent.CompletableFuture.uniRunStage(CompletableFuture.java:803) ~[?:?] at java.util.concurrent.CompletableFuture.thenRun(CompletableFuture.java:2195) ~[?:?] at com.starrocks.qe.DefaultCoordinator.updateFragmentExecStatus(DefaultCoordinator.java:1128) ~[starrocks-fe.jar:?] at com.starrocks.qe.QeProcessorImpl.reportExecStatus(QeProcessorImpl.java:215) ~[starrocks-fe.jar:?] at com.starrocks.service.FrontendServiceImpl.reportExecStatus(FrontendServiceImpl.java:1061) ~[starrocks-fe.jar:?] at com.starrocks.thrift.FrontendService$Processor$reportExecStatus.getResult(FrontendService.java:5637) ~[starrocks-fe.jar:?] at com.starrocks.thrift.FrontendService$Processor$reportExecStatus.getResult(FrontendService.java:5614) ~[starrocks-fe.jar:?] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:40) ~[libthrift-0.20.0.jar:0.20.0] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:40) ~[libthrift-0.20.0.jar:0.20.0] at com.starrocks.common.SRTThreadPoolServer$WorkerProcess.run(SRTThreadPoolServer.java:313) ~[starrocks-fe.jar:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:840) ~[?:?]
r
The 
java.lang.NullPointerException
you are seeing is a known issue in certain StarRocks versions (likely 3.3.x or 3.4.x, specifically around 3.4.3) related to the new pipeline scheduler logic. Cause The error occurs in 
DefaultCoordinator.clearExternalResources
when it attempts to iterate over the list of scan nodes from a 
JobSpec
object. In certain scenarios—most commonly with Routine Load or *Stream Load*—the 
JobSpec
may not have its 
scanNodes
list initialized, leading to 
getScanNodes()
returning 
null
and triggering the NPE during cleanup or status reporting. This issue is often accompanied by "FE RPC failure" or "No more data to read" errors in the BE logs, as the FE's internal thread crashes while processing the execution status report. Recommended Actions 1. Check your StarRocks Version: This bug was prominently reported in version 3.4.3. 2. Upgrade to a Patch Release: This issue has been addressed in newer maintenance releases. * If you are on the 3.4.x branch, upgrade to 3.4.4 or later. * If you are on the 3.3.x branch, ensure you are on the latest patch (e.g., 3.3.8+). 3. Related Issues: You can track similar reports and fixes in the StarRocks GitHub repository, specifically under issues/PRs related to 
DefaultCoordinator
and 
JobSpec
(e.g., Issue #59361 or PRs like #59536). If you are already on a newer version and still seeing this, please provide your exact StarRocks version and the type of load/query being executed (e.g., Routine Load via Kafka) to help narrow it down further. References • administration/Meta_recovery.md • unloading/Spark_connector.md • release_notes/release-2.0.md
z
@Rocky I use 3.5.16
r
Based on the stack trace, you are encountering a known NullPointerException (NPE) in the StarRocks Frontend (FE) within the 
DefaultCoordinator
. This issue occurs when the 
JobSpec
(part of the newer DAG-based scheduler) has not yet initialized its scan nodes list, but a status update or cancellation request (often triggered by an early error or timeout) attempts to iterate over them for cleanup. Cause In StarRocks 3.5.x, this error typically happens during Stream Load, Routine Load, or Insert Into operations when: 1. The job fails or is cancelled before the execution plan is fully distributed. 2. The Backend (BE) reports an execution status (
reportExecStatus
) back to the FE while the FE is still in the middle of a cleanup or initialization phase. 3. The code in 
clearExternalResources
tries to call 
.iterator()
on a null list returned by 
getScanNodes()
. Solution While version 3.5.16 included several NPE fixes related to Stream Load (e.g., Issue #60755), this specific crash in 
DefaultCoordinator.java:1057
has been further addressed in the most recent stable releases. 1. Upgrade to 3.5.17 or later: This version is the current stable patch in the 3.5 branch (as of June 2026) and includes more robust null checks in the coordinator cleanup logic to prevent this crash. 2. Check for "No more data to read" or RPC failures: Often, this NPE is the result of an underlying network or BE failure. Check your 
fe.warn.log
and 
<http://be.INFO|be.INFO>
logs for errors preceding the NPE. Resolving the root cause of the query failure (e.g., increasing 
thrift_rpc_timeout_ms
or checking BE health) may stop the coordinator from entering this buggy cleanup state. 3. Temporary Mitigation: If you cannot upgrade immediately, you can try disabling the new pipeline scheduler features if you suspect a regression, though this is generally not recommended for 3.5.x performance.
Copy code
sql
    -- Check if this environment variable/configuration is active and try toggling if the issue persists
    SET GLOBAL enable_dag_scheduler = false;
(Note: The availability of this specific toggle may vary; check your version's 
SHOW VARIABLES
first.) If the issue persists on 3.5.17+, it is recommended to provide the full 
fe.log
context (including the events just before the crash) to the StarRocks community on Slack or GitHub for further investigation of a potential regression. References • knowledge/usage/best-practice.md • administration/Meta_recovery.md
2 Views
Open in Slack
PreviousNext
Powered by