[Task] Support HugeGraph with RocksDB on RISC-V

[imbajin]

Goal

Make HugeGraph Server with the embedded RocksDB backend:

1. build successfully in a real linux/riscv64 userspace in CI; and
2. pass a basic RocksDB and HugeGraph runtime smoke test.

QEMU and containers may be used as the CI execution environment. They are test
infrastructure only: this task does not require an official RISC-V image, Dockerfile
changes, or image publication.

Scope

In scope

• hugegraph-server and the embedded RocksDB backend
• RISC-V architecture detection in the Maven build
• a working RISC-V Protobuf/gRPC code-generation strategy
• an opt-in Server/RocksDB-only build and packaging path that avoids unrelated backends
• a supported Java 11 runtime path for the CI smoke test
• automatic or explicitly configured libatomic.so.1 support for the packaged RocksDB JNI
• an isolated CI job running in linux/riscv64 userspace, with QEMU acceptable
• basic runtime smoke coverage:
  • RocksDB open, put/get, close, and reopen
  • HugeGraph InitStore and Server startup
  • /versions
  • REST schema and graph CRUD
  • one Gremlin query
  • restart and persistence verification
• confirmation that existing non-RISC-V Java 11 build and test paths remain unchanged
• concise documentation of the tested CI environment, commands, and limitations

Minimal build-only changes to transitive modules such as protobuf/gRPC generation are
allowed when they are required to compile the Server dependency graph. They do not imply
runtime support for those modules on RISC-V.

Out of scope

• official HugeGraph Dockerfile or entrypoint changes
• building or publishing an official linux/riscv64 HugeGraph image
• multi-architecture image manifests or release-image validation
• a standalone local Docker/QEMU helper for contributors
• mandatory full RocksDB core-test or api-test suites on RISC-V
• HugeGraph PD, Store, HStore, or any backend other than RocksDB
• native-hardware or hosted-RISC-V release gates
• production performance, sustained-load, or tuning certification
• 32-bit RISC-V, musl, or Alpine support
• claiming a broad minimum-glibc compatibility range from a single CI environment

Why work is needed

HugeGraph is mostly Java, but the RISC-V path crosses several native and build-tool
boundaries. A successful Java compile or RocksDB.loadLibrary() call alone is not enough.

Area	Confirmed problem	Required outcome
Architecture detection	Older os-maven-plugin versions normalize riscv64 incorrectly	Maven identifies riscv64 and activates the required build path
Protobuf generation	Maven Central does not provide the required linux-riscv64 protoc executable for the pinned version	CI uses a documented compatible native protoc/gRPC generator strategy
RocksDB JNI	rocksdbjni:8.10.2 contains a RISC-V library but real I/O fails with undefined symbol: __atomic_compare_exchange_1 without libatomic	Real open/put/get/reopen succeeds without undocumented manual intervention
Java runtime	JDK 17 starts parts of the Server, but the current TinkerPop/Groovy stack fails Gremlin with Unsupported class file major version 61	Select and validate one Java 11 RISC-V runtime path, including Gremlin
Distribution	The standard distribution depends on unrelated backend modules	Provide an explicit RocksDB-only build/package selection while preserving the default build

The CI environment should record the actual JDK, architecture, and libc used. An ELF
symbol requirement such as GLIBC_2.30 may be documented as technical information, but
must not be presented as a fully tested support range unless that range is actually
validated.

Implementation direction

The intended path is:

RISC-V CI userspace
  -> clean Server/RocksDB-only Maven build
  -> compatible native protobuf generation
  -> RocksDB-only distribution boundary check
  -> RocksDB JNI I/O smoke
  -> HugeGraph REST + Gremlin + restart/persistence smoke

The root/default reactor, existing Dockerfiles, existing image publication, and existing
JDK/build/test paths for other architectures should remain unchanged.

Done when

• CI runs in a real linux/riscv64 userspace and asserts uname -m == riscv64;
  QEMU is acceptable.
• A clean Server/RocksDB-only Maven build succeeds without building or packaging
  unrelated backend implementations.
• The RISC-V protobuf/gRPC generation strategy works in CI and is documented.
• The produced distribution contains the required Server/RocksDB artifacts and
  excludes unrelated backend artifacts.
• RocksDB JNI passes open, put/get, close, and reopen without native linkage errors.
• HugeGraph passes InitStore, startup, /versions, REST schema/graph CRUD, one
  Gremlin query, restart, and persistence checks.
• The smoke test leaves no running Server process or CI container after completion.
• Existing Java 11 and non-RISC-V build/test paths remain unchanged and green.
• Documentation clearly states that this is CI build/runtime validation only, not an
  official RISC-V image, production certification, or support for other backends.

Full RISC-V Core/API suites, a local no-hardware helper, native-machine validation, and
official image publication may be handled as separate follow-up work, but they are not
acceptance criteria for this task.

Related work

• Primary CI/build/runtime implementation: feat(server): support RocksDB on RISC-V #3102
• A standalone local QEMU helper such as HUGEGRAPH-3099: Add RISC-V end-to-end smoke test script #3104 may be evaluated independently, but is not
  required to complete this issue.

References

• RocksDB RISC-V atomic linkage discussion
• RocksDB RISC-V atomic linkage fix
• RocksDB Linux/RISC-V Java build path
• TINKERPOP-2633

[yugaaank]

Hi @imbajin — I'd like to pick up the RocksDB smoke test work item (starter-friendly, no prerequisite). Plan: a small JUnit/Java test that asserts uname -m == riscv64, performs open/put/get/close, and fails with a clear message on the __atomic_compare_exchange_1 linkage problem. I'll link the PR back here. Let me know if anyone's already on it.

[imbajin]

Thanks @yugaaank — no one is assigned to this yet.

For the fastest first step, please do not start with a JUnit test. The main unknown is the real RISC-V runtime integration, not HugeGraph's Java logic.

If you already have SSH access to a glibc-based linux/riscv64 server, that is the simplest and preferred path:

1. Build the HugeGraph Server distribution on a supported x86-64/arm64 host, then copy it to the RISC-V server. A native RISC-V Maven/protoc build is a separate, later task.
2. On the server, verify uname -m reports riscv64, Java is Java 11, and libatomic is available (install libatomic1 if needed).
3. Configure the libatomic preload automatically for this test environment, then verify real RocksDB open/put/get/close. The undefined __atomic_compare_exchange_1 symbol must fail the check; it is not an acceptable final result.
4. Run HugeGraph init/start, /versions, REST schema + CRUD, one Gremlin query, restart, and persistence verification.
5. Capture the environment and results, then remove only the copied test files, process, and data created by the check.

If no native RISC-V server is available, run the same checks in a disposable Docker/QEMU environment and clean up its container/image/volume. QEMU is the fallback, not a requirement when native hardware is available.

Once either end-to-end path works reliably, we can decide which portable checks belong in JUnit/CI. A focused PR for a reusable Java 11 smoke helper that supports both local QEMU and an SSH target would be a great starting point.

[Seanium]

Implemented the minimum HugeGraph Server + RocksDB linux/riscv64 support in #3102.

The final scope is intentionally limited to build/runtime validation:

• an opt-in RocksDB-only distribution build, while the default reactor and distribution
  remain unchanged;
• RISC-V architecture detection plus native system protoc and
  grpc_java_plugin support;
• automatic libatomic.so.1 preload for initialization and Server startup on
  linux/riscv64;
• an isolated RISC-V Server CI job using a checksum-pinned Dragonwell 11 Extended
  Server VM under QEMU;
• real RocksDB JNI put/get/reopen, REST schema and graph CRUD, Gremlin, shutdown,
  restart persistence, and cleanup checks.

The official HugeGraph Dockerfile, image publication, existing architecture JDKs, and
existing Server jobs are not changed by this PR.

Validation on the current head:

• native RISC-V clean build: all 16 selected projects passed; PD and Store entries are
  aggregator POMs only, and no unrelated backend implementation was built or packaged;
• native RISC-V runtime: Dragonwell 11 Server VM, RocksDB JNI, REST/Gremlin, both
  shutdowns, restart persistence, and final process/port cleanup passed;
• org-hosted QEMU job
  89169639441
  passed the same build and runtime boundary in 23m17s;
• the default 43-project Java 11 reactor and existing memory/RocksDB/HBase/macOS,
  PD/Store/HStore checks were retained.

The six Apache workflows for the exact head still require maintainer approval. The org
results above are not represented as Apache workflow results. QEMU and the available
native machine establish functional correctness, not production performance or
sustained-load qualification.