I maintain RocketMQ-Rust, an unofficial Rust implementation of Apache RocketMQ’s messaging architecture, licensed under Apache 2.0.
The project includes NameServer routing, a broker and storage implementation, and an async client SDK. Producers and consumers use NameServer to discover broker routes; the broker appends messages to a CommitLog and dispatches them to queues. The implementation uses Tokio for asynchronous I/O.
The client SDK supports batch sending, request/reply, transaction producers, ordered consumption, and push and lite-pull consumers. Lite-pull APIs expose polling, assignment, pause/resume, seek and offset commits. Optional features add OpenTelemetry tracing and metrics.
For a local experiment, the repository quickstart walks through building the workspace, starting NameServer and a broker, then running the consumer and producer examples in separate terminals. It documents the required toolchain and broker runtime directory setup. The examples use TopicTest and a local NameServer endpoint.
Production qualification depends on the specific build and environment. The validation evidence index distinguishes code/system acceptance from performance, soak and recovery evidence. This announcement makes no performance comparison with Java RocketMQ.
Feedback would be useful on two areas:
- How do the producer and consumer APIs fit Rust applications, especially around runtime ownership, cancellation and shutdown?
- When testing against an existing Java RocketMQ deployment, which client/broker versions and messaging patterns expose interoperability gaps?
Please include the version or commit and a small reproducer with any issue report.
Disclosure: This announcement was drafted with AI assistance.