Looks good overall,
Do we need to consider the batch filter since the API is defined as
`Message`, not `Entry`, so parts of the batch need to filter out, does it
should be handled by Filter, or the consumer side, or the producer side?
Thanks,
Penghui
On Fri, Sep 10, 2021 at 11:53 AM Lin Lin <lin...@apache.org> wrote:
>
> > What about:
> >
> > public interface MessageFilter {
> > enum FilterOutcome {
> > ACCEPT, -> deliver to the Consumer
> > REJECT, -> skip the message
> > SYSTEM -> use standard system processing
> > }
> >
> > public FilterOutcome filterMessages(List<MessageWrapper>
> messages,
> > FilterContext context) throws Exception;
> >
> > }
> >
> > interface MessageWrapper {
> > ....allow to access Message payload, metadata, headers...
> > }
> >
> > interface FilterContext {
> > ...isReplayRead,
> > ...access acks
> > ...access ManagedCursor
> > }
> >
> >
> > This way the implementation of the filter will not use internal APIs that
> > evolve in Pulsar sometimes even in point releases.
> >
> > Enrico
>
> Hi Enrico:
> Thank you for your advice.
> I got your point, it works for me.
> More detailed interface implementation, we can discuss it in PR.
>
