syhleo commented on PR #8469:
URL: https://github.com/apache/rocketmq/pull/8469#issuecomment-2290920186

   > 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.
   
   Thank you very much for your feedback.
   
   1.**Regarding the startup sequence of gray consumers**: Yes, the PR 
recommends that gray consumers be started before gray producers to ensure that 
gray messages are correctly processed.
   
   2.**Regarding the issue of subscription inconsistency**: This PR does not 
address scenarios with inconsistent subscriptions, as this issue is not caused 
by the gray partitioning scheme. Even without the gray scheme, when gray 
consumers (gray pods) and base consumers (base pods) have different 
subscription relationships, the same problem will occur. However, the issue of 
inconsistent subscriptions can be resolved through other means.
   
   3.**Regarding rewriting client logic**: The Remoting Protocol client can 
indeed have its logic rewritten. Apologies, I haven't yet found the entry point 
for this. However, to ensure compatibility with RocketMQ 5.x server-side load 
balancing and to support both Pop and Push consumption modes, the PR introduces 
additional client configurations, providing a simple and flexible way to 
integrate the gray feature.
   
   4.**Multi-environment and gray release**: The gray partitioning scheme and 
binding of different environments to corresponding queues do not conflict; 
rather, they complement each other. This design ensures that each environment 
can carry out gray releases in an orderly and independent manner.


-- 
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]

Reply via email to