syhleo commented on PR #8469: URL: https://github.com/apache/rocketmq/pull/8469#issuecomment-2290916852
> 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. > 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. 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. 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. 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. 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. > 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. 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. 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. 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. 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. > 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. -- 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]
