QMSTR / broker-test

RabbitMQ as a message broker on Kubernetes
0 stars 0 forks source link

KubeMQ's event fetcher call is non-blocking #4

Closed marcomicera closed 3 years ago

marcomicera commented 3 years ago

Such a call:

res, err := client.NewReceiveQueueMessagesRequest()
      .SetChannel("a-new-channel-that-has-never-been-used")
      .SetMaxNumberOfMessages(1)
      //SetWaitTimeSeconds(10) // I want this to be blocking
      .Send(ctx)

Returns immediately with:

 Received 0 Messages:

This is not the behavior we want in Quartermaster: modules should start and block on the queue until their message has been inserted in the queue by the master.

marcomicera commented 3 years ago

We could use KubeMQ's "long polling" feature with a timeout (e.g., 60 seconds) in a for loop, kinda like it's done in Java with wait() to handle spurious wakeups.

So it'd be something like:

for {
   res, err := client.NewReceiveQueueMessagesRequest().
      SetChannel(channel).
      SetMaxNumberOfMessages(1).
      SetWaitTimeSeconds(60).
      Send(ctx)
   if err != nil {
      log.Fatal(err)
   }

   if res != nil && res.MessagesReceived != 0 {
      break
   }
}

But the name suggests that it's polling anyway, so not that great.

marcomicera commented 3 years ago

Closing, as we're not gonna be using KubeMQ anymore.