yyj8 commented on PR #23770: URL: https://github.com/apache/pulsar/pull/23770#issuecomment-2563447508
> @yyj8 > > > The default configuration for the client is `replicateSubscriptionState=false`. > > The latest client defaults to `null`, please see #23757. > > > In the scenario of cluster migration, we hope that there is no need for business code modification, and the server will control the replication of the state of all subscriptions in the cluster uniformly. If the configuration priority of the client is the highest, and the client does not display the configuration `replicateSubscriptionState=true`, this goes against our original intention of not requiring business code modification. > > My suggestion is to configure the cluster dimension. If `repliceAllSubscriptState=true` is enabled, it will be a mandatory configuration to overwrite the client. If `repliceAllSubscriptState=false`, then use the client's configuration. > > I understand your idea, this can make all subscriptions replicated when `repliceAllSubscriptState=true`, when true, this equals the consumer with `replicateSubscriptionState=true`, and they have the highest. > > However, this idea conflicts with PIP-398, which assumes that the consumer-level configuration for `replicateSubscriptionState` is not set, and instead, replication behavior is driven by namespace and topic policies. If the `replicateSubscriptionState` is set, it means that the specified subscription will be replicated, namespace and topic levels cannot change this behavior. If changed, it will result in a breaking change. This is worth considering. > > In our case, I don't want to configure the `replicateSubscriptionState` on the consumer, but the user has been configured, I cannot change the user code. We have the same case, so I also want to ignore the `replicateSubscriptionState`. > > ## My idea > To combine your case and my case, I suggest introducing a broker configuration for overwriting the consume configuration, and assuming the namespace and topic level are set, the final result will be so like this: > > * `overwirteConsumerReplicateSubscriptionState=true`: The subscription will be replicated. > * `overwirteConsumerReplicateSubscriptionState=false`: The subscription will be replicated. > * `overwirteConsumerReplicateSubscriptionState=null`: This means the consumer level is null, and then the broker depends on the namespace and topic level to check the subscription replication. > > We can also introduce `replicateSubscriptionsState=true/false/empty` configuration on the broker level, when the namespace/topic/consumer levels are not set, we use the broker level configuration to check if replicates the subscription. @nodece I agree with your suggestion. Before using cluster level configuration, we first check if there are topic and namespace dimensions. If there are none, we apply cluster level configuration; The priority of the three dimensions from high to low is: topic -> namespace -> cluster. Then we can make unified code adjustments on your pip, or you can directly merge my code into your code, or after you submit the code, I can synchronize your code and modify the cluster level configuration before submitting. -- 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]
