lizhanhui commented on issue #4533: URL: https://github.com/apache/rocketmq/issues/4533#issuecomment-1171878588
@Oliverwqcwrw The crux here is can we afford dropping events in case there are too many netty events... From design perspective, we should not drop events here, otherwise, we have to compensate logic by way to schedule scanning wherever relies on channel state... This is why ClientHouseKeepingService has a scheduled thread: https://github.com/apache/rocketmq/blob/a62b70bc25423c1d7e18043e32af427d29ef9ac4/broker/src/main/java/org/apache/rocketmq/broker/client/ClientHousekeepingService.java#L43 Obviously, it is a trade-off...when there are a massive number of events to handle and the ChannelEventListener implementation cannot process them timely...drop those events and let the schedule scanning to maintain eventual consistency. To be honest, it's pretty error-prone when implementing new features that may rely on channel state. They are very likely to forget to implement the compensation logic. A better alternative is to ensure every netty event is handled. -- 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]
