rocketmq不支持运行时修改刷盘方式?
- Dominant language
- Java
- Stars
- 22.6k
- Forks
- 12k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 26
Description
### Before Creating the Bug Report
- [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions).
- [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate.
- [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.
### Runtime platform environment
Ubuntu 20.04/Centos 7.9
### RocketMQ version
4.9.7
### JDK Version
Oracle JDK 1.8.0
### Describe the Bug
rocketmq不支持运行时修改刷盘方式
如果MQ启动的时候是同步刷盘策略(FlushDiskType:SYNC_FLUSH),那用API可以随便反复改刷盘方式实时生效; 如果MQ启动的时候是异步刷盘策略(FlushDiskType:ASYNC_FLUSH),用API改成同步刷盘策略,改后不重启就会发送抛异常。
### Steps to Reproduce
1.MQ集群以同步刷盘策略(FlushDiskType:SYNC_FLUSH)启动,在RocketMQ运行过程中,动态修改FlushDiskType为ASYNC_FLUSH,集群收发消息正常,再次动态修改FlushDiskType为SYNC_FLUSH,集群收发消息正常,无论修改多少次,不需要重启集群,收发消息都没问题。
2.MQ集群以异步刷盘策略(FlushDiskType:ASYNC_FLUSH)启动,在RocketMQ运行过程中,动态修改FlushDiskType为SYNC_FLUSH时,发消息抛出异常(但实际会落盘,重启后可以查询)。
java.lang.ClassCastException: org.apache.rocketmq.store.CommitLog$FlushRealTimeService cannot be cast to org.apache.rocketmq.store.CommitLog$GroupCommitService
### What Did You Expect to See?
不管MQ启动的时候是什么刷盘策略,FlushDiskType参数都能够支持运行时修改(不需要重启MQ集群)
### What Did You See Instead?
MQ集群以异步刷盘策略(FlushDiskType:ASYNC_FLUSH)启动,在RocketMQ运行过程中,动态修改FlushDiskType为SYNC_FLUSH时,发消息抛出异常(但实际会落盘,重启后可以查询)。
### Additional Context
_No response_
Contributor guide
Research direction
Start with the CommitLog flush service classes named in the exception, especially FlushRealTimeService and GroupCommitService, and trace the API path that changes FlushDiskType at runtime. Reproduce the transition from ASYNC_FLUSH to SYNC_FLUSH on RocketMQ 4.9.7, then verify that repeated runtime changes send successfully without requiring a restart and that existing persistence behavior remains intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100