It looks like we can add something like `EntryDispatcher` before the EntryFilter. Mixing entry filtering and consumer selecting seems a little confusing.
The `EntryDispatcher` could works as a consumer selector in `PersistentDispatcherMultipleConsumers`. It accepts an entry and a consumer list, returns the consumer this entry should dispatch to. The implementation could be provided by user like EntryDispatcher. Thanks, Haiting On 2022/05/05 12:41:10 Enrico Olivelli wrote: > Hello, > I am trying to use PIP-105 and I found out that we are missing a few > little things to cover my user case. > In my case I have two consumers who compete on the same SHARED > subscription with a "message filter". > The filter is passed as Consumer metadata. > > When you have two Consumers connected on the Subscription the > dispatcher prepares to send the message to one consumer at a time. > > The Message goes through the EntryFilter that decides if the Entry > matches the requirements of the Consumer. > - if the message matches the consumer then it returns ACCEPT > - if the message does not match the consumer then it has to be > rescheduled (RESCHEDULE) > > With this small extension to PIP-105 we can cover this simple scenario > without the need to introduce a new Dispatcher policy > > I sent out a patch with the implementation and a test case that shows my > usecase > https://github.com/apache/pulsar/pull/15391 > > Introducing RESCHEDULE needs some level of discussion here. > > With PIP-105 we are anticipating in the broker a decision that the > Consumer would take when the Message is already dispatched to the > application: > A) ignore the message: acknowledge immediately, without processing. (REJECT) > B) postpone the message (or let it be processed from another > consumer): negatively acknowledge immediately, without processing. > (RESCHEDULE) > > With the initial implementation of PIP-105 we are covering case A, and > with my proposal I want to give the opportunity to implement case B. > > The only point that is not covered by my proposal is that the NACK on > the client happens only after a delay on the client, and this has some > side effects. > In fact that "delay" from the client allows the dispatcher to read > more entries because it thinks that the message has been dispatched > successfully, and it is allowed to move forward. > I would prefer to start a separate discussion for this "problem", that > is in part related to how we deal with messages to be replayed and it > is not strictly related to my PR. > > > Cheers > Enrico >
