Il giorno ven 6 mag 2022 alle ore 01:50 PengHui Li <peng...@apache.org> ha scritto: > > > 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) > > It looks like different consumers have different metadata that is used by > the entry filter. > How do we handle the case that all the consumers `RESCHEDULE` the message? > Some consumers cannot start normally in a period of time orr user-specified > matching > rules cannot cover all messages. In PIP-105, it introduced > a subscription level entry filter, not the consumer level entry filter. > The main problem is that the filter of the consumer is more complicated. > > Instead of introducing new RESCHEDULE result type, how about create a > separate subscription > for the consumers that with the same filter metadata? and apply the filter > metadata to the subscription. > It doesn't seem like much difference in this case.
The problem is that If I use multiple subscriptions then I am not guaranteed that each message is delivered only to one consumer. It is a weird use case, but it is something that is possible according to the JMS specs. I am mapping a JMS Queue with a Subscription, and everything works well, but you can have multiple Consumers, with different Selectors, that compete on the same Queue (Subscription). You can have two Consumers with overlapping selectors and we have to guarantee that each message is processed only by one of the two consumers. This is why I need consumer level filtering and not only per-subscription filters. It is an edge case and this is why I don't want to build a brand new dispatcher to cover this feature. Currently, without server-side filtering, my implementation uses client side negative acks for a Consumer to reject the message and leave it to the other consumers attached to the subscription. I hope that this helps in understanding better my business requirements Enrico > > Thanks, > Penghui > > On Thu, May 5, 2022 at 8:41 PM Enrico Olivelli <eolive...@gmail.com> 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 > >
