apache / apache/eventmesh

[Feature] Support building and running EventMesh on RISC-V 64 (riscv64) platforms

Open
#5,315 1 comment 0 reactions 0 assignees View on GitHub
feature help wanted waiting for contributor
Dominant language
Java
Stars
1.8k
Forks
658
Avg merge
11h 29m
Merged PRs (30d)
52

Description

### Search before asking

- [x] I had searched in the [issues](https://github.com/apache/eventmesh/issues?q=is%3Aissue) and found no similar issues.

### Feature Request

## Background & Motivation

RISC-V is growing rapidly in edge computing and domestic hardware scenarios. EventMesh (master branch) is written in pure Java and is architecturally close to riscv64-ready, but there is no verified build/run path for RISC-V 64 platforms today.

This issue proposes the complete plan to build and run EventMesh (master) on riscv64 Linux distributions (validated target: Bianbu OS, a Debian-based distro from SpacemiT). The outcome enables EventMesh to run as a lightweight, self-contained message mesh on RISC-V edge devices.

## Key Findings (master branch)

- The core is pure Java (`source/target = 1.8`); bytecode is architecture-independent.
- **No RocksDB / JNI-only hard dependency** exists in the runtime path of master.
- `eventmesh-storage-standalone` (Disruptor-based, pure Java, in-memory) ships as the **default** storage (`eventMesh.storage.plugin.type=standalone` in `eventmesh-runtime/conf/eventmesh.properties`) — a zero-external-dependency mode works out of the box.
- `AbstractRemotingServer` uses `Epoll.isAvailable()` and **falls back to NIO automatically** when the Netty native epoll library is unavailable on the arch. Same for `grpc-netty-shaded`.
- Remaining architecture-sensitive artifacts:
- `kafka-clients` (transitive of `cloudevents-kafka:2.5.0` in `eventmesh-storage-kafka`) → `snappy-java` / `zstd-jni` native libs
- Docker base images `openjdk:8-jdk` / `openjdk:11-jdk` (no riscv64 variant, deprecated)
- `eventmesh-sdk-c` makefile (hardcoded `gcc`), Go/Rust SDK toolchains

## Proposed Changes

### 1. Runtime JDK constraint (`bin/start.sh`)

`eventmesh-runtime/bin/start.sh` hard-checks for Java 8 or 11 (`is_java8_or_11`) and aborts otherwise. RISC-V distributions mainly provide OpenJDK 17/21 today.

Options:
- [ ] Preferred: provide/verify a riscv64 build of JDK 8 or 11 (distro packages, vendor JDK such as Xuantie/Alibaba Dragonwell, or OpenJDK riscv ports).
- [ ] Fallback: relax `start.sh` to accept JDK 17+ — add a unified GC logging branch (`-Xlog:gc*:...`) and remove obsolete flags (`-XX:-UseBiasedLocking` was removed in JDK 18). Bytecode level 1.8 is forward-compatible.

### 2. JVM sizing for resource-constrained boards

`bin/start.sh` hardcodes `-XX:MaxDirectMemorySize=8G` and `-XX:+AlwaysPreTouch`, which are too large for typical RISC-V boards (4–16 GB).

- [ ] Make direct-memory size and `AlwaysPreTouch` configurable via `conf/server.env` (or reduce defaults).

### 3. Native library audit

- [ ] Add a build-time/CI check that scans `dist/lib` and `dist/plugin/**/*.jar` for bundled `.so/.dll/.dylib` and reports per-arch coverage.
- [ ] Verify `snappy-java` / `zstd-jni` versions pulled in by `kafka-clients` contain `linux-riscv64` binaries; if not, upgrade or document switching producer compression to `gzip`/`lz4` (lz4-java is pure Java). This item can be skipped entirely when the Kafka storage plugin is not deployed.
- [ ] Verify logs show clean NIO fallback (no fatal `UnsatisfiedLinkError`) for Netty/gRPC on riscv64.

### 4. Docker support

`docker/Dockerfile_jdk8` and `Dockerfile_jdk11` are based on `openjdk:8-jdk` / `openjdk:11-jdk`, which have no riscv64 variant.

- [ ] Add a riscv64-compatible Dockerfile using `debian:trixie` (official riscv64 image) or a vendor base image, installing OpenJDK via apt and reusing the existing build sequence (`generateGrammarSource` → `build dist -x spotlessJava` → `installPlugin`). Bare-metal deployment remains the recommended path for edge devices.

### 5. Documentation

- [ ] Add a RISC-V porting guide to `docs/`, covering: toolchain setup (JDK + Gradle 8.7 + Maven mirror), build commands (`./gradlew clean dist installPlugin -x spotlessJava`), standalone smoke test (ports 10000/10105/10106/10205), JVM tuning, and the native-library audit procedure.

### 6. Multi-language SDKs (optional follow-ups)

- [ ] Go SDK: cross-compile with `GOOS=linux GOARCH=riscv64` (no code change expected).
- [ ] C SDK (`eventmesh-sdks/eventmesh-sdk-c`): parameterize `CC`/`AR`/`RANLIB` in the makefile to allow the `riscv64-linux-gnu` cross toolchain; embedded curl/json-c build from source on-device.
- [ ] Rust SDK: add `riscv64gc-unknown-linux-gnu` target support.

## Verification Plan

1. Build on-device (or qemu for compile-gate only): `./gradlew clean dist installPlugin -x spotlessJava -x test`.
2. Boot with default standalone storage; verify ports 10000 (TCP), 10105 (HTTP), 10106 (admin), 10205 (gRPC).
3. Publish/subscribe a CloudEvent over HTTP end-to-end (can use `eventmesh-examples`).
4. Confirm zero native-library loading failures in logs.
5. Optionally add a self-hosted riscv64 GitHub Actions runner for CI.

## Risks & Caveats

| Risk | Level | Mitigation |
|---|---|---|
| No riscv64 JDK 8/11 available in distro repos | Medium | Vendor JDK (Xuantie) or relax `start.sh` for JDK 17+ |
| Hardcoded `MaxDirectMemorySize=8G` + `AlwaysPreTouch` on small boards | Medium | Make configurable / adjust `server.env` |
| Old `snappy-java`/`zstd-jni` without riscv64 (only when Kafka plugin is used) | Low | Upgrade deps or switch compression codec |
| Build OOM on low-memory boards | Medium | Lower `org.gradle.jvmargs`, skip spotless/tests |
| Network restrictions to services.gradle.org / Maven Central | Medium | Offline Gradle distribution; Aliyun mirror is already configured in root `build.gradle` |

## Notes

- This plan is scoped to the **master** branch; the unified runtime on `develop` has a different risk profile (RocksDB-based offset store) and is tracked separately.
- No breaking changes are expected: all changes are additive (configuration, scripts, docs, optional Dockerfile).

Happy to take this in stages — starting with (1) runtime verification on a riscv64 device with standalone storage, then the documentation and script improvements.

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [ ] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) *

Contributor guide

Open the contributing guide

Research direction

Start with eventmesh-runtime/bin/start.sh, docker/Dockerfile_jdk8, and docker/Dockerfile_jdk11 to map the runtime and image constraints. Run the stated Gradle build and standalone smoke test on riscv64 or qemu, then review the native-library audit and docs/ requirements. Done means a documented, verified build and run path with the listed ports working and no native-library loading failures.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, java
Domain
build-system, devops, documentation, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.