Release v2.0-alpha

Comparing to v1.0, a few changes are introduced:

1. Bi-directional stream API is used, allowing server to issue
   diagnosing telemetry commands to clients;
2. Server side stream API is employed for receive message API, which
   mitigates costs of serialization/deserialization of large data chunks
3. Error code are re-organized, roughly following HTTP semantics. Each
   code now has five digits, first three of them complies HTTP status
code; The rest two digits are used to specify each exact scenario.
4. A few concepts are renamed to follow RocketMQ 5.x terminologies.
Rename CLIENT_ID_MISSING as CLIENT_ID_REQUIRED (#50)

2 files changed
tree: a911a9a6a1788a520b601420aedd9a7da353dcd5
  1. .github/
  2. apache/
  3. cpp/
  4. java/
  5. .asf.yaml
  6. .bazelrc
  7. .bazelversion
  8. .clang-format
  9. .gitignore
  10. BUILD.bazel
  11. ChangeLog.md
  12. compile.bzl
  13. deps.bzl
  14. plugin.bzl
  15. README.md
  16. status_code.md
  17. StyleGuide.md
  18. WORKSPACE
README.md

Overview

Extension Spec

Message Model

Producer Flow

Consumer Flow

Error handling

This API spec adopts a rich error model developed by Google as described here. This model enables servers to return and clients to consume additional error details expressed as one or more protobuf messages. It further specifies a standard set of error message types to cover the most common needs (such as invalid parameters, quota violations, and stack traces).

The whole set of response codes are listed here, except the offical gRPC error model, please refer to service.proto for more details about the error responses of each RPC service.

Reserved Fields

Messages and enumerations of the API spec reserve the first 64 fields for the evolution of RocketMQ exclusively. Vendor-specific extensions to the protocol are supposed to use fields beyond 64.