[fix][client] fix retry topic with exclusive mode.

[thetumbled]

Motivation

• Retry topic relies on the delayed queue feature. Once user call reconsumeLater for a message, this message will be produce as a delayed message to the corresponding retry topic.
• Delayed queue feature can only work with shared/key-shared subscription mode, or the delayed message will be dispatched immediately.
  Based on the analysis above, we can come to the conclusion that the consumer of the retry topic must be shared/key-shared.

Modifications

Demand that the subscription type of the retry topic must be shared.

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository:

[thetumbled]

And i have a question: why delayed message do not support exclusive type? is it a task that can't be implemented? or a pending task?

[lhotari]

And i have a question: why delayed message do not support exclusive type? is it a task that can't be implemented? or a pending task?

@thetumbled This question has been asked multiple times before and I didn't search for previous answers. I think that one of the reasons is that the semantics of delayed messages hasn't been defined and designed with Failover or Exclusive type.
There's also technical reasons from implementation perspective. Naively adding support for delayed messages would result in a lot of code duplication in the dispatcher implementation classes. Avoiding code duplication would require refactoring of the dispatcher code and there's currently a lot of resistance in doing that. I noticed that when working on PIP-379 that there's a preference to minimize refactoring due to the risk of regressions. The state management in dispatchers isn't that great and there are bugs that pop up when a subtle change is made. I'm currently investigating #23845 and that's some of my observations about the dispatcher code. It's fairly hard to grasp it how it works due to the multiple levels of states that impact the execution. Multiple levels of state result in a vast state space, which isn't great. A better approach would be to minimize the state space. That could be achieved with a simpler execution model that addresses the different states that exist due to various hacks that have been added to address issues in the original implementation.

[thetumbled]

And i have a question: why delayed message do not support exclusive type? is it a task that can't be implemented? or a pending task?

@thetumbled This question has been asked multiple times before and I didn't search for previous answers. I think that one of the reasons is that the semantics of delayed messages hasn't been defined and designed with Failover or Exclusive type. There's also technical reasons from implementation perspective. Naively adding support for delayed messages would result in a lot of code duplication in the dispatcher implementation classes. Avoiding code duplication would require refactoring of the dispatcher code and there's currently a lot of resistance in doing that. I noticed that when working on PIP-379 that there's a preference to minimize refactoring due to the risk of regressions. The state management in dispatchers isn't that great and there are bugs that pop up when a subtle change is made. I'm currently investigating #23845 and that's some of my observations about the dispatcher code. It's fairly hard to grasp it how it works due to the multiple levels of states that impact the execution. Multiple levels of state result in a vast state space, which isn't great. A better approach would be to minimize the state space. That could be achieved with a simpler execution model that addresses the different states that exist due to various hacks that have been added to address issues in the original implementation.

I agree with the complexity of the dispatcher. It is too complicate to master this module and it is hard to guarantee that there is nothing wrong when a seemingly good pr is merged.
Not only the dispatcher module, but other modules like consumer/producer in client jdk are also incredibly complex. There are too many features in pulsar, which is a advantage compared to other mq, but also a disadvantage resulting into many issues.