@Rocky if i'm getting

java.net.SocketException: Connection reset

with stream loads, what should i do

The

java.net.SocketException: Connection reset

error during StarRocks Stream Loads typically indicates that the TCP connection was abruptly closed by the server (FE/BE) or an intermediate proxy (like Nginx, F5, or a NAT gateway). Here is a troubleshooting guide to identify and resolve the cause: 1. Check for Intermediate Proxy Issues If you are accessing StarRocks through a proxy (Nginx, HAProxy, F5), this is the most common cause. * Timeouts: Ensure the proxy’s read/write timeouts are longer than your load time. For Nginx, increase

proxy_read_timeout

,

proxy_send_timeout

, and

keepalive_timeout

. * Body Size: Check if the proxy limits the request body size (e.g.,

client_max_body_size

in Nginx). If the stream load exceeds this, the proxy may reset the connection. * Buffered Uploads: Proxies often try to buffer the entire request before sending it to the backend. For large stream loads, disable buffering (e.g.,

proxy_request_buffering off

in Nginx). 2. Verify BE/FE Connectivity Stream Load involves a two-step redirect: 1. The client sends the request to the FE (HTTP 8030). 2. The FE redirects the client to a BE (HTTP 8040). * Direct Access: Ensure your client machine can reach all BE nodes on their

be_http_port

(default 8040). If a firewall allows access to the FE but not the BEs, the connection will be reset after the redirect. * MTU Mismatch: In Kubernetes or VPC environments, a mismatch in MTU (Maximum Transmission Unit) sizes can cause large packets to be dropped, leading to connection resets. Try lowering the MTU on the client side to 1400 as a test. 3. StarRocks Configuration Limits Check if the load is hitting internal StarRocks limits which might cause the BE to close the connection: *

streaming_load_max_mb

(BE): The default is 10 GB. If your data exceeds this, the BE may reject it. You can adjust this dynamically:

curl -XPOST http://<be_host>:<be_http_port>/api/update_config?streaming_load_max_mb=20480

*

stream_load_default_timeout_second

(FE): The default is 600s (10 mins). If the load takes longer, the FE/BE may terminate it. You can increase this in

fe.conf

or pass a

timeout

header in your request. 4. Client-Side (Java) Tuning If you are using a Java client (like the Flink or Spark connector): * Expect: 100-continue: Ensure your client sends the

Expect: 100-continue

header. This allows the BE to reject a request (e.g., due to permissions or full disks) before the client sends the entire data body, preventing a reset mid-transfer. * Connection Pooling: If using a connection pool, the client might be trying to reuse a "stale" connection that the StarRocks BE has already closed due to idleness. Try reducing the

MaxIdleTime

in your Java HTTP client. 5. Inspect StarRocks Logs To find the exact reason the server closed the connection, check the following logs on the StarRocks nodes at the time of the error: * BE:

log/be.INFO

or

log/be.WARNING

. Look for "exceed max size" or "timeout". * FE:

log/fe.log

or

log/fe.audit.log

. Look for failed jobs with labels matching your load. Quick fix checklist: • ☐ Can the client reach BE port 8040? • ☐ Is

Expect: 100-continue

enabled? • ☐ Is the data size > 10GB? (Increase

streaming_load_max_mb

) • ☐ Is the load taking > 10 mins? (Increase

timeout

header) References • faq/operation_maintenance_faq.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md • faq/loading/Stream_load_faq.md • administration/management/monitoring/metrics.md • loading/StreamLoad.md