leizhiyuan opened a new issue, #1471:
URL: https://github.com/apache/rocketmq-clients/issues/1471
### Before Creating the Enhancement Request
- [x] I have confirmed that this should be classified as an enhancement
rather than a bug/feature.
### Programming Language of the Client
Rust
### Summary
Align the log messages and levels of the Rust client with the Java client.
Right now, the Rust client logs things the Java client stays silent about at
`INFO`, and many messages carry neither the endpoints nor the client id.
### Motivation
Users report that a Rust producer floods the application log with:
```
2026-10-31 12:26:07.495 handle setting command success.
2026-10-31 12:26:07.495 handle setting command success.
2026-10-31 12:26:37.490 handle setting command success.
2026-10-31 12:26:37.490 handle setting command success.
2026-10-31 12:27:07.494 handle setting command success.
2026-10-31 12:27:07.494 handle setting command success.
```
This happens because the client syncs its settings every 30 seconds
(`client.rs`, `sync_settings_interval`), the server answers each sync with a
`Settings` command on every session, and `Producer` logs `handle setting
command success.` at `INFO` for each one. That is one line per endpoint every
30 seconds, with no client id or endpoints to tell them apart.
The Java client:
- syncs every 5 minutes (`ClientManagerImpl#SYNC_SETTINGS_PERIOD`);
- logs the receipt once, in `ClientSessionImpl#onNext`, as `Receive settings
from remote, endpoints={}, clientId={}`;
- applies the settings silently (`ClientImpl#onSettingsCommand`,
`PublishingSettings#sync`, `SimpleSubscriptionSettings#sync`,
`LiteSubscriptionManager#sync`).
Other Rust logs share the same problems:
| Rust today | Java |
| --- | --- |
| `SimpleConsumer`: `simple consumer applied server-pushed
long_polling_timeout` at INFO on every settings push | silent |
| `LiteSubscriptionManager`: `Updated lite subscription quota to ...` /
`Updated max lite topic size to ...` at INFO on every settings push | silent |
| FIFO accelerator: `FIFO consume accelerator enabled, ...` at INFO for
**every received batch** | `FifoConsumeService parallel consume, ...` at DEBUG |
| `start consumer worker count: N` at INFO for every queue actor | none |
| `SimpleConsumer::start` logs `start simple consumer success` **twice** |
logged once |
| `create session success`, `starting client success`, `telemetry command
stream closed by server`, `telemetry response error`, `send heartbeat failed:
...`, `sync route failed`, `unimplemented command ...` | same events, with
`endpoints=` and `clientId=` |
| received telemetry commands are only logged at DEBUG as a full `Debug`
dump | one line per command kind, with `endpoints=` and `clientId=` |
| heartbeat failures at ERROR | `Failed to send heartbeat, ...` at WARN |
### Describe the Solution You'd Like
Use Java's wording and levels, and add `endpoints=`/`clientId=` where Java
has them:
- Log each received telemetry command once in the session, as Java's
`ClientSessionImpl#onNext` does. `Settings` stays at DEBUG because the Rust
client syncs 10x more often than Java.
- Stop logging at INFO when settings pushed by the server are applied
(producer, simple consumer, lite subscription manager).
- Use DEBUG for the FIFO accelerator batch log and the per-queue worker
count.
- Log `SimpleConsumer` startup once.
- Rename the session, heartbeat, route and lifecycle messages after their
Java counterparts.
This is a log-only change. It does not touch the protocol, the sync
intervals or the public API.
### Describe Alternatives You've Considered
- Only downgrade `handle setting command success.`. That fixes the reported
line but leaves the other per-sync and per-batch INFO logs, and the missing
client id.
- Change the settings sync interval from 30 seconds to Java's 5 minutes.
That also cuts the volume, but it is a behaviour change: the Rust client
currently relies on this timer to rebuild broken telemetry streams, so it
should be discussed separately.
### Additional Context
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
