syhleo commented on PR #8469: URL: https://github.com/apache/rocketmq/pull/8469#issuecomment-2292942981
> > In the following description, the current environment is referred to as the "base environment," to distinguish it from the "gray environment." > > > > 1. The PR requires that the "gray consumer" be started before the "gray producer." If the gray consumer fails to start, it can lead to "gray messages" being sent to the base environment, may causing issues. In other words, the PR assumes that consumers in the base environment have the capability to consume gray messages, but this cannot be guaranteed. > > 2. The plan does not account for scenarios where subscription are different. When gray consumers with different subscription and base consumers are running concurrently, how can we ensure that if client crashes or other exceptions, consumer offset is not skipped? > > 3. The remoting protocol client can be rewrite load balancing rules and select message queue function by users ; it is not a difficult task. Thus, the question arises whether it is necessary to merge this PR. > > 4. This PR handles multiple environments poorly, as each environment must be bound to corresponding queues, thereby limiting the number of environments that can be supported. > > @qianye1001 nice question 1, 2 > > @syhleo > > ### question 1 > no users can guarantee it, this canbe a BIG problem, can we unbind the dependency on producer and consumer? > > ### question 2 > consumers in different-subscriptions, gray and normal consumers could be in-a-mess, how to make sure consume offset's right > > ### my question > how gray consumer change into normal consumer. from the source code to see, it need to update consumer config and restart, can do it in admin tools? Thank you for your feedback. Subscription relationship inconsistency issue: The subscription inconsistency issue is not triggered by the grayscale partitioning scheme of this PR. Even without the grayscale partitioning scheme, the same problem is faced when a grayscale consumer (grayscale pod) has a different subscription relationship than a normal consumer (normal pod). Solving the MQ subscription inconsistency problem requires another PR to deal with, and the commit scheme can be further explored if there is time, so we won't expand on it here. Gray-to-normal bridging issue: When the grayscale validation passes, it triggers the normal downtime of the grayscale service and triggers the rebalancing logic. By way of admin tools, I have not tried this. Either way, it's essentially modifying the client's grayTag, clientId configurations so that all consumer instances under the same consumer group can sense each other's grayscale status. -- 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]
