apache / apache/rocketmq-apis

[Feature] Support extensible external configuration for RocketMQ clients, similar to Pulsar's `producer.properties` and `consumer.properties`

Open
#107 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Starlark
Stars
32
Forks
26
PR merge metrics
No merged PRs in 30d

Description

### English

Apache Pulsar supports external producer and consumer configuration through files such as `producer.properties` and `consumer.properties`.

RocketMQ clients currently do not provide a similar standardized and extensible configuration capability.

I would like to propose adding similar support to RocketMQ clients, while making the configuration model extensible across different scopes, for example:

- client scope
- producer scope
- consumer scope

This kind of configuration model has several practical benefits:

- deployment-time configuration can be changed without modifying application code
- producer and consumer settings can be managed in a more uniform way
- environment-specific settings are easier to maintain across development, testing, and production
- operations teams can manage client behavior more conveniently
- new client capabilities can be introduced through clear configuration scopes instead of ad hoc code changes
- cross-language SDKs can evolve toward a more consistent configuration model

---

### 中文

Apache Pulsar 支持通过 `producer.properties`、`consumer.properties` 这类文件对 Producer 和 Consumer 进行外部配置。

RocketMQ 客户端目前还不支持类似的标准化、可扩展配置能力。

我希望 RocketMQ 客户端也能支持类似方式,并让这套配置模型能够按不同维度进行扩展,例如:

- client 维度
- producer 维度
- consumer 维度

这种配置模型有几个比较实际的好处:

- 部署时可以调整配置,而不需要修改应用代码
- Producer 和 Consumer 配置可以用更统一的方式管理
- 开发、测试、生产等不同环境下的配置更容易维护
- 运维侧可以更方便地管理客户端行为
- 后续新增客户端能力时,可以按清晰的配置维度扩展,而不是零散地落到代码中
- 有助于多语言 SDK 逐步形成更一致的配置模型

Contributor guide

No contributing guide indexed for this repository

Research direction

The issue names no files, tests, or entry points. Start by comparing Pulsar's producer.properties and consumer.properties model with the RocketMQ client APIs, then define how client, producer, and consumer scopes should be represented and extended; done requires an agreed configuration design and its implementation across the affected client APIs.

Written by the indexing model from the issue text.

Assessment

Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.