IBM MQ

Expand all | Collapse all

MQ Programming question about msg retrieval from queue

  • 1.  MQ Programming question about msg retrieval from queue

    Posted 13 days ago

    Hello MQ Community users,
    I have the following question communicated to me from an app developer  at customer site:

    "I had the following rare case in message retrieval from a Windows MQ Queue in my C# program. My program asks a queue every second about its current depth.

    If the depth is bigger than 0 then the program retrieves the messages, the amount of which is the queue depth. The case is that although the queue depth was 1, getting the message caused an exception with code 2033 (no message in queue). Why did this happen?

    How happened that there was not a message to retrieve when the depth was 1? "

    Any advise on the above question will be much appreciated.
    Thanks in advance,
    Rgds, Nick.



    ------------------------------
    NICK DAKORONIAS
    ------------------------------


  • 2.  RE: MQ Programming question about msg retrieval from queue

    Posted 13 days ago
    Nick, maybe the message was not commited:

    https://community.ibm.com/community/user/imwuc/blogs/morag-hughson/2017/03/28/ibm-mq-little-gem-21-uncom

    ------------------------------
    Enio Marques Junior
    ------------------------------



  • 3.  RE: MQ Programming question about msg retrieval from queue

    Posted 12 days ago

    I agree with the answer Enio has posted - likely an uncommitted message.

    I would also like to offer that this is not an appropriate way for an application to operate. An application should not query the current depth of a queue to decide whether or not to attempt to get a message from the queue. The MQGET call already has a way to tell you that there is no message should you issue an MQGET call when the current depth is zero. The way it does this is to return MQRC_NO_MSG_AVAILABLE (2033). It is expected that the application should catch that return code and behave appropriately.

    There are many reasons why an application should not be query the current depth before deciding to attempt to get a message:

    • The current depth will include uncommitted messages (as already noted by Enio)
    • The current depth may change a nano-second after you inquire what it is, resulting in a delay before your application realises it needs to get a message
    • If there is more than one application instance reading from the queue (a very common model) then another instance may get the message before you do
    • You are sending a command to the command server every second - that's at least 2 messages you are causing in the system every second before you even attempt to process your actual message off your queue, instead of just making an MQGET call to get your message

    Your question indicates that you are not handling the reason code MQRC_NO_MSG_AVAILABLE. You should fix that. Once that is done, you should remove the code that inquires the current depth and instead put whatever processing was done if the current depth was zero into the catch for reason code MQRC_NO_MSG_AVAILABLE.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    ------------------------------



  • 4.  RE: MQ Programming question about msg retrieval from queue

    Posted 12 days ago
    Hi Nick

    It is not a good idea for an application asking the queue depth before then getting messages.  This consumes computing cycles, and, as you found, bump into some issues.

    The better idea is to do a "get with wait", say for 30 seconds. This reduces CPU usage, and, it will return a message as soon as it is available on the queue. If you get a 2033 after the wait period, then just issue it again.

    ------------------------------
    Francois van der Merwe
    Hybrid Cloud / Integration Specialist Tech Sales
    IBM
    Johannesburg
    +27825569467
    ------------------------------



  • 5.  RE: MQ Programming question about msg retrieval from queue

    Posted 12 days ago
    ...or , to round up the answer of Francois, use the Asynchronous consumption of IBM MQ messages

    ------------------------------
    Norbert Pfister
    system engineer
    DATEV eG
    Nuremberg
    ------------------------------



  • 6.  RE: MQ Programming question about msg retrieval from queue

    Posted 12 days ago
    I have never seen the need to use asynchronous consumption of MQ messages in my MQ coding.  When I have that type of requirement, I just create another thread in my program and have it do a GET with a wait.  Is the asynchronous consumption functionality provided more for programmers who are not familiar with multi-threaded programming?  Or was it added into MQ more to meet a JMS asynchronous messaging requirement?  Or maybe I am missing some other value it is providing?

    ------------------------------
    Tim Zielke
    ------------------------------



  • 7.  RE: MQ Programming question about msg retrieval from queue

    Posted 12 days ago
    IBM has praised this as more resource-efficient at the server side when it came with V8.0 .
    At the client side i think it keeps you in control instead of being blocked by the GET WAIT.
    Maybe this presentation clarifies.

    ------------------------------
    Norbert Pfister
    system engineer
    DATEV eG
    Nuremberg
    ------------------------------



  • 8.  RE: MQ Programming question about msg retrieval from queue

    Posted 12 days ago
    Thanks for sharing that link!  That link does help to explain the benefits/differences between asynch consume and creating more threads that do an MQGET.  I have never really needed those benefits for asynch consume, but good to know.

    ------------------------------
    Tim Zielke
    ------------------------------



  • 9.  RE: MQ Programming question about msg retrieval from queue

    Posted 11 days ago
    Dear all,

    Many thanks to all, for your responses, pointing out valuable info and tips.
    I will communicate your feedback to app developer at cust. site, looking for his comments (if any)

    Cheers Nick.

    ------------------------------
    NICK DAKORONIAS
    ------------------------------