How to setup KubeMQ Listener in Spring Boot

Currently, I have two microservices. I want to send message to KubeMQ Queue from first microservice and want it to be received by Second microservice. I am able to send message to a KubeMQ Queue using below code:

Queue queue = new Queue("QueueName", "ClientID", "localhost:50000");
  SendMessageResult resSend = queue.SendQueueMessage(new Message()
          .setBody(Converter.ToByteArray("some-simple_queue-queue-message"))
          .setMetadata("someMeta"));
  if (resSend.getIsError()) {
      System.out.printf("Message enqueue error, error: %s", resSend.getError());
  }

I need Listener in the second microservice in order to receive the message from Queue.
Below is code provided by KubeMQ to receive the message:

 Queue queue = new Queue("QueueName", "ClientID", "localhost:50000");
  ReceiveMessagesResponse resRec = queue.ReceiveQueueMessages(10, 1);
  if (resRec.getIsError()) {
      System.out.printf("Message dequeue error, error: %s", resRec.getError());
      return;
  }
  System.out.printf("Received Messages %s:", resRec.getMessagesReceived());
  for (Message msg : resRec.getMessages()) {
      System.out.printf("MessageID: %s, Body:%s", msg.getMessageID(), Converter.FromByteArray(msg.getBody()));
  }

How to configure it in the second microservice to receive message instantly as they are added into the queue?

Please help.

> I need a Listener in the second microservice in order to receive the message from Queue.

Why polling, when you can be notified through the KubeMQ Pub/Sub pattern?

In the context of message queues, "polling" refers to a process where your application continually checks the queue to see if a new message has arrived. This can be inefficient, as it requires your application to make many requests when there may not be any new messages to process.

On the other hand, a "listener" (also known as a subscriber or a callback) is a function that is automatically called when a new message arrives. This is more efficient because your application does not need to continually check the queue; instead, it can wait and react when a message arrives.

The Publish-Subscribe pattern (or pub/sub) is a messaging pattern supported by KubeMQ, and it differs slightly from the queue-based pattern you are currently using.
In the pub/sub pattern, senders of messages (publishers) do not program the messages to be sent directly to specific receivers (subscribers). Instead, the programmer “publishes” messages (events), without any knowledge of any subscribers there may be. Similarly, subscribers express interest in one or more events and only receive messages that are of interest, without any knowledge of any publishers.

In this pattern, KubeMQ provides two types of event handling, Events and Events Store.

• The Events type is an asynchronous real-time Pub/Sub pattern, meaning that messages are sent and received in real-time but only if the receiver is currently connected to KubeMQ. There is no message persistence available in this pattern.

• The Events Store type, however, is an asynchronous Pub/Sub pattern with persistence. This means that messages are stored and can be replayed by any receiver, even if they were not connected at the time the message was sent.
  The system also supports replaying all events from the first stored event, replaying only the last event, or only sending new events.

However, it is important to note that the uniqueness of a client ID is essential when using Events Store.
At any given time, only one receiver can connect with a unique Client ID.
If two receivers try to connect to KubeMQ with the same Client ID, one of them will be rejected. Messages can only be replayed once per Client ID and Subscription type. If a receiver disconnects and reconnects with any subscription type, only new events will be delivered for this specific receiver with that Client ID. To replay messages, a receiver needs to connect with a different Client ID.

Given these features, if you switch your architecture to a pub/sub pattern using the Events Store type, your second microservice could instantly receive messages as they are added into the channel, and even replay old messages if needed. You would need to ensure each microservice has a unique Client ID and manages its subscriptions appropriately.

However, the pub/sub pattern may require changes in the architecture and coding of your microservices, so you would need to evaluate whether this change is suitable for your use case. It is also important to note that the pub/sub pattern, especially with message persistence, may have different performance characteristics and resource requirements compared to the queue pattern.

Here is a high-level overview of the classes that are present and their usage:

1. Channel.java: This class appears to represent a channel for sending events in a publish-subscribe model.

2. ChannelParameters.java: This class defines the parameters for creating a Channel instance.

3. Event.java: This class represents an event that can be sent via a Channel.

4. EventReceive.java: This class is used to process received events.

5. Result.java: This class contains the result of a sent event.

6. Subscriber.java: This class allows you to subscribe to a channel and handle incoming events.

So here is an example of how you might use the existing classes to publish and subscribe to messages.

import io.kubemq.sdk.Channel;
import io.kubemq.sdk.ChannelParameters;
import io.kubemq.sdk.Result;
import io.kubemq.sdk.event.Event;
import io.kubemq.sdk.event.Subscriber;

public class KubeMQExample {

    public static void main(String[] args) {
        try {
            // Initialize ChannelParameters
            ChannelParameters params = new ChannelParameters();
            params.setChannel("your_channel");
            params.setClient("your_client_id");

            // Initialize a new Channel
            Channel channel = new Channel(params);

            // Create a new Event
            Event event = new Event();
            event.setBody("Your message here".getBytes());

            // Send the Event
            Result sendResult = channel.SendEvent(event);
            System.out.println("Event sent, Result: " + sendResult.getIsError());

            // Initialize a new Subscriber
            Subscriber subscriber = new Subscriber("localhost:5000");

            // Subscribe to the Channel
            subscriber.SubscribeToEvents(params, (eventReceive) -> {
                System.out.println("Received Event: " + new String(eventReceive.getBody()));
            });

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Do note that this code is based on the existing SDK and may not reflect the functionality of the original code. You will need to replace "your_channel" and "your_client_id" with your actual channel name and client ID. The event body can also be replaced with the actual message you want to send.

The Subscriber class is used here to listen for and process incoming events. The SubscribeToEvents method takes a ChannelParameters object and a lambda function that processes received events.

Do also note that the Queue and EventsStore classes seem to have been removed from the SDK. The SDK now seems to primarily use the publish-subscribe model, which differs from queue-based communication in that messages are not stored if no consumer is available to consume them.
Events Store was a hybrid model that allowed for persistence in the pub/sub model, storing events that could be replayed by receivers connecting at a later time.

For your original functionality of reading queue messages and peeking at messages in a queue, unfortunately, it does not seem like the current state of the Kubemq Java SDK on the provided GitHub repository supports these actions.