首先我们根据关键字:TIMEOUT_CLEAN_QUEUE 去 RocketMQ 中查询,去探究在什么时候会抛出如上错误。根据全文搜索如下图所示: 该方法是在 BrokerFastFailure 中定义的,通过名称即可以看成其设计目的:Broker端快速失败机制。 Broker 端快速失败其原理图如下: 消息发送者向 Broker 发送消息写入请求,Broker 端在接收到请求...
清理过期请求时,如果请求线程的创建时间到当前系统时间间隔大于 waitTimeMillsInSendQueue(默认 200ms,可以配置)就会清理这个请求,然后给 Producer 返回一个系统繁忙的状态码(code=2,remark="[TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue: %sms, size of queue: %d") 1...
如果大家在网上搜索 TIMEOUT_CLEAN_QUEUE 的解决方法,大家不约而同提出的解决方案是增加 waitTimeMillsInSendQueue 的值,该值默认为 200ms,例如将其设置为 1000s 等等,以前我是反对的,因为我的认知里 Broker 会重试,但现在发现 Broker 不会重试,所以我现在认为该 BUG未解决的情况下适当提高该值能有效的缓解。
错误信息关键点:MQBrokerException:CODE:2DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue:205ms,size of queue:880。 由于项目组并没有对消息发送失败做任何补偿,导致丢失消息发送失败,故需要对这个问题进行深层次的探讨,并加以解决。 问题分析 首先我们根据关键字:TIMEOUT...
首先,broker busy 相关的日志关键字如下: [REJECTREQUEST]system busy too many requests and system thread pool busy [PC_SYNCHRONIZED]broker busy [PCBUSY_CLEAN_QUEUE]broker busy [TIMEOUT_CLEAN_QUEUE]broker busy 上述前面4个关键字在上篇文章中已详细介绍,本文先对出现上述错误进行一个总结,具体的分析过程...
TIMEOUT_CLEAN_QUEUE的由来 RocketMQ为了解决这种由于性能锁带来的频发问题,引入Broker端快速失败机制,即开启一个定时调度线程,每隔10毫秒去检查队列中的第一个排队节点,如果该节点的排队时间已经超过了200ms。就会取消该队列中所有已超过 200ms 的请求,立即向客户端返回失败。
错误信息关键点:MQBrokerException:CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue:205ms,size of queue:880。 由于项目组并没有对消息发送失败做任何补偿,导致丢失消息丢失,故需要对这个问题进行深层次的探讨,并加以解决。
[TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue: 206ms, size of queue: 5 1. 复制 这是因为 RocketMQ 触发了流量控制。今天我们来聊一聊哪些场景下 RocketMQ 会触发流量控制。 如上图,生产者把消息写入 Broker,Consumer 从 Broker 拉取消息。Broker 是 RocketMQ 的...
ROCKETMQ MQBrokerException: CODE: 2 DESC: [TIMEOUT_CLEAN_QUEUE]broker busy 解决方案:以上两种任意一个方式都可以 如果你需要使用大量的线程来处理发送消息,你最好使用useReentrantLockWhenPutMessage = true useReentrantLockWhenPutMessage默认使用自旋锁 当等于true的时候 使用重入锁ReentrantLock...
在对RMQ 做集群压测时,偶现 [TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a whil 异常,对系统正确率有一定影响,所以决定一探究竟。 全局搜索代码 首先,clone 了一波代码,全局搜了一下,在 BrokerFastFailure 这个类里的 cleanExpiredRequestInQueue 方法看到了: ...