@Rocky starrocks ver 4.1.3 Cannot find constructor for interface org.apache.iceberg.io.FileIO Missing org.apache.iceberg.gcp.gcs.GCSFileIO [java.lang.ClassNotFoundException: org.apache.iceberg.gcp.gcs.GCSFileIO]

The error

java.lang.ClassNotFoundException: org.apache.iceberg.gcp.gcs.GCSFileIO

indicates that the StarRocks Frontend (FE) or Backend (BE) is attempting to use the Apache Iceberg Google Cloud Storage (GCS) implementation, but the required Iceberg GCP library is missing from the classpath. While StarRocks version 4.1.3 includes native support for many cloud storages, certain specific Iceberg IO implementations (like

GCSFileIO

) may not be bundled in the default classpath of every distribution or container image. Recommended Solutions 1. Add the Missing Iceberg GCP JARs You need to provide the

iceberg-gcp

library to StarRocks. * Identify the Library: You need the

iceberg-gcp

JAR (and potentially the

gcs-connector

JAR) compatible with the Iceberg version used in StarRocks 4.1.x (likely Iceberg 1.6.x or newer). * Installation Path: * For FE: Place the JAR in the

$STARROCKS_HOME/fe/lib/

directory. * For BE: Place the JAR in the

$STARROCKS_HOME/be/lib/

directory (or the specific connector plugin directory if using a plugin-based setup). * Restart: You must restart the FE and BE processes after adding the JARs. 2. Check Catalog Properties If you are explicitly setting the

iceberg.catalog.io-impl

property in your

CREATE EXTERNAL CATALOG

statement, StarRocks will try to instantiate that specific class. * Standard Configuration: For GCS, StarRocks typically handles authentication through internal properties. Try creating the catalog using the following standard GCS properties instead of manually setting `io-impl`:

sql
    CREATE EXTERNAL CATALOG iceberg_gcs
    PROPERTIES (
        "type" = "iceberg",
        "iceberg.catalog.type" = "hive", -- or 'rest', 'glue', etc.
        "hive.metastore.uris" = "thrift://<hms_ip>:9083",
        "gcp.gcs.use_compute_engine_service_account" = "true" -- or service account details
    );

* REST Catalogs: If you are using a REST catalog (like Polaris or Nessie) that requires

GCSFileIO

for its data access, the library mentioned in Step 1 is mandatory. 3. Container Load Order Issue In StarRocks version 4.1.0 specifically, there was a known issue regarding unstable load orders in container environments. While you are on 4.1.3, ensure your environment variables (like

JAVA_OPTS

or

CLASSPATH

) aren't accidentally excluding the

lib

directory or causing a conflict. 4. Verification After adding the JARs and restarting, you can verify if the class is loaded by checking the FE log (

fe.log

). If the error persists, ensure that the

gcs-connector-hadoop

JAR is also present, as

GCSFileIO

often depends on it to interact with Google Cloud's APIs. If you are using the official StarRocks Docker image, you can extend it in a Dockerfile:

dockerfile
FROM starrocks/fe-ubuntu:4.1.3
# Example path, adjust to your needs
COPY iceberg-gcp-1.6.1.jar /opt/starrocks/fe/lib/

Note: If you are using StarRocks 4.1 and connecting to a Google BigLake managed Iceberg table via the REST protocol, ensure you are using the new

iceberg.catalog.security = "google"

property if supported by your specific build. References • data_source/catalog/iceberg/iceberg_catalog.md • quick_start/iceberg.md