Consumer callback: which queue is empty?

Question

I'm using the MQCB function to add message consumer callback functions for queues that I'm reading from. I'm trying to read from two queues on the same connection, and it seems to work fine when receiving messages: my callback function gets the object handle for the queue that the message was received from.

However, when I get an MQRC_NO_MSG_AVAILABLE event (since I set MQGMO_WAIT on my consumer), the object handle is MQHO_NONE, so I can't tell which queue the event refers to. I could solve that by putting the object handle in the callback context, but is that the way it's supposed to be done? Or am I missing something obvious here?

I'm connecting to a queue manager running version 8.0.0.2 on Linux, using the C client library version 8.0.0.5, likewise on Linux. Here is the output from my sample program, showing object handles being 0:

Opened queue 'AMQ.5A55ED982D616602                            ' with handle 101
Opened queue 'AMQ.5A55ED982D616603                            ' with handle 102
Completion code MQCC_FAILED, reason MQRC_NO_MSG_AVAILABLE, object handle 0
Completion code MQCC_FAILED, reason MQRC_NO_MSG_AVAILABLE, object handle 0

And the program itself:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <cmqc.h>
#include <cmqxc.h>
#include <cmqstrc.h>

void my_message_consumer(MQHCONN, PMQMD, PMQGMO, PMQVOID, PMQCBC);

volatile unsigned events_received = 0;

void
check_fail(const char *action, MQLONG comp_code, MQLONG reason)
{
  if (comp_code != MQCC_OK) {
    fprintf(stderr, "%s failed with %s %s\n",
            action, MQCC_STR(comp_code), MQRC_STR(reason));
    exit(1);
  }
}

int
main()
{
  MQHCONN hconn;
  MQHOBJ hobj1, hobj2;
  MQOD od = {MQOD_DEFAULT};
  char queue_name[MQ_Q_NAME_LENGTH + 1];
  MQLONG c, r;

  MQCONN("", &hconn, &c, &r);
  check_fail("MQCONN", c, r);

  /* Open two dynamic queues */
  strcpy(od.ObjectName, "SYSTEM.DEFAULT.MODEL.QUEUE");
  MQOPEN(hconn, &od, MQOO_INPUT_EXCLUSIVE, &hobj1, &c, &r);
  check_fail("MQOPEN", c, r);

  strncpy(queue_name, od.ObjectName, MQ_Q_NAME_LENGTH);
  queue_name[MQ_Q_NAME_LENGTH] = '\0';
  printf("Opened queue '%48s' with handle %d\n", queue_name, hobj1);

  strcpy(od.ObjectName, "SYSTEM.DEFAULT.MODEL.QUEUE");
  MQOPEN(hconn, &od, MQOO_INPUT_EXCLUSIVE, &hobj2, &c, &r);
  check_fail("MQOPEN", c, r);

  strncpy(queue_name, od.ObjectName, MQ_Q_NAME_LENGTH);
  queue_name[MQ_Q_NAME_LENGTH] = '\0';
  printf("Opened queue '%48s' with handle %d\n", queue_name, hobj2);

  /* Add a callback with zero WaitInterval for both queues */
  MQMD md = {MQMD_DEFAULT};
  MQGMO gmo = {MQGMO_DEFAULT};
  MQCBD cbd = {MQCBD_DEFAULT};
  gmo.Options = MQGMO_NO_SYNCPOINT | MQGMO_WAIT;
  gmo.WaitInterval = 0;
  cbd.CallbackType = MQCBT_MESSAGE_CONSUMER;
  cbd.CallbackFunction = &my_message_consumer;

  MQCB(hconn, MQOP_REGISTER, &cbd, hobj1, &md, &gmo, &c, &r);
  check_fail("MQCB", c, r);
  MQCB(hconn, MQOP_REGISTER, &cbd, hobj2, &md, &gmo, &c, &r);
  check_fail("MQCB", c, r);

  /* Start consuming */
  MQCTLO ctlo = {MQCTLO_DEFAULT};
  MQCTL(hconn, MQOP_START, &ctlo, &c, &r);
  check_fail("MQCTL start", c, r);

  /* Wait until events received */
  while (events_received < 2)
    sleep(1);

  return 0;
}

void
my_message_consumer(MQHCONN hconn, PMQMD md, PMQGMO gmo,
                    PMQVOID buffer, PMQCBC context)
{
  printf("Completion code %s, reason %s, object handle %d\n",
     MQCC_STR(context->CompCode), MQRC_STR(context->Reason),
     context->Hobj);
  events_received++;
}

Compile it with:

gcc -o mq-no-msg mq-no-msg.c -g -Wall -I/opt/mqm/inc -L/opt/mqm/lib64 -lmqic_r -Wl,-rpath=/opt/mqm/lib64

and set the MQSERVER environment variable before running.

Answer 1

I found information from a few sources on this topic that when put together paint the whole picture (unfortunately IBM's MQ KC does not document this very well to say the least).

1. At Capitalware's MQ Technical Conference v2.0.1.3 Morag Hughson gave a presentation WebSphere MQ V7 Enhanced Application Programming which has some useful information.

   On page six it states:

   • Your message consumer can also be called with CallType set to MQCBCT_EVENT_CALL (this is also the only way an Event handler can be called). The message consumer will be given events that are pertinent to the queue it is consuming from, for example, MQRC_GET_INHIBITED whereas the event handler gets connection wide events.

2. In the IBM MQ v8 KC page MQCBC - Callback context > Fields for MQCBC > Hobj (MQHOBJ) it states:

   For an event handler, this value is MQHO_NONE

3. The IBM provided sample amqscbf0.c also demonstrates checking the pContext->CallType in the MessageConsumer, if it is type MQCBCT_EVENT_CALL it prints the Reason, if it is type MQCBCT_MSG_REMOVED it prints the message.

---

Based on the above information it appears the behavior you see is the expected behavior.

---

A suggested work around would be to set the CallbackArea field of each queue's MQCBD with a unique value that you can use to determine the which queue the event refers to.

---

On page four of Morag's presentation "WebSphere MQ V7 Enhanced Application Programming" it states the following:

• MQGMO_WAIT with MQGMO.WaitInterval = 0 operates just like MQGMO_NO_WAIT when one uses on an MQGET, but in the case of asynchronous consumers we wish to avoid the consumer from polling in a busy loop in this case, so it operates more like a backstop marker to show when the end of a batch of messages has been reached.

In the table on the same page it under the Asynchronous Consume column for MQGMO_WAIT with MQGMO.WaitInterval = 0 it states:

Only called with MQRC_NO_MSGS_AVAILABLE if just started or has had a message since last 2033

Your consumer will not continuously get events notifying it that no messages are on the queue. An event is only generated if there are no messages when the call back is first started and/or after each time ALL messages have been read (GET) from the queue. Essentially it lets you know that currently no more messages are available after it had read at least one message. This may be useful if you expect batches of messages and want to perform some action after all messages in a batch have been read off the queue.

• Note that MQGMO_NO_WAIT, and MQGMO_WAIT with a WaitInterval of MQWI_UNLIMITED are quite different when passed to MQGET but with the MQCB call their behaviour is the same. The consumer will only be passed messages and events, it will never be passed the reason code indicating no messages. Effectively MQGMO_NO_WAIT will be treated as an indefinite wait. This is to prevent the consumer from endlessly being called with the no messages reason code.

If you really do not need the MQRC_NO_MSG_AVAILABLE event messages, then MQGMO_NO_WAIT is probably the way to go.

Answer 2

When you got the MQRC_NO_MSG_AVAILABLE as an event, it meant there was no message (matching your criteria, if you specified any criteria) on any of the queues you registered. So there is no need to supply the callback with any particular HObj in this case.