Why Use MessageListeners in Apache Pulsar and Not Simply Consumer.receive()?

Question

Apache Pulsar's APIs (https://pulsar.apache.org/api/client/org/apache/pulsar/client/api/Consumer.html) include at least two methods of consuming messages from a Pulsar topic/queue:

1. Using Consumer.receive() (or Consumer.receiveAsync())
2. Using ConsumerBuilder.messageListener(MessageListener messageListener) to add a message listener, which sends a reference to the Consumer and Message to an instance of a MessageListener

Mostly it feels like these are on equal ground, and the event-like methodology of using a MessageListener makes sense, except that the Consumer object has other methods that I find might be useful in a controlled while-loop, such as: isConnected(), receiveAsync(), pause(), resume(), and seek(MessageId messageId).

With these additional features in the Consumer class, even though the Consumer is passed into the MessageListener, why not have a simple loop for the consumer instead of using a single MessageListener?

Is there an advantage or preference to using MessageListener in Pulsar, or is this just an option given to the developer?

In the past I've mostly written consumer loops for JMS and Kafka.

Menis

Answer 1

Listener pattern is generally a better OOP design. It makes the code more concise and most importantly it applies SOLID principle nicely.

Basically you need to execute a business logic based on each message, and manage the consumer/reader infrastructure like threading model. Java Event Listener pattern is an answer to separate the business logic and managing threads. The business logic is implemented in the listener class. It can be added one line with addListener(theClass) with the consumer/reader creation. It is much cleaner.

With addListener, there is still an option to add lambda function with business logic in the same class/file. I think this is for simple processing needs.

In Pulsar client's particular case, the client API technically can manage the listener threads for you. That is another bonus.

Sheelagh