MQ

 View Only
  • 1.  Help understanding MQRC_PUBLICATION_FAILURE error.

    IBM Champion
    Posted Thu May 12, 2022 11:35 AM
    One of our publisher clients recently reported error, MQRC_PUBLICATION_FAILURE.  This occurred twice and then the problem resolved itself.  After reading about the error (https://www.ibm.com/docs/en/ibm-mq/9.0?topic=codes-2502-09c6-rc2502-mqrc-publication-failure) I see it comes from a failure at one or more of the subscribers. 

    In our case the subscribers are internal MQ administrative subscriptions.  We are using a pattern where a publisher puts a message to a topic that is then copied to four queues by the queue manager.  The definitions look something like this:

    DEFINE TOPIC('MY_TOPIC') TOPICSTR('my-topic') DEFPSIST(YES) REPLACE
    
    DEFINE SUB('MY_TOPIC_1') TOPICSTR('my-topic') DESTCLAS(PROVIDED) DEST('Q_1') PUBPRTY(ASPUB) REPLACE
    DEFINE SUB('MY_TOPIC_2') TOPICSTR('my-topic') DESTCLAS(PROVIDED) DEST('Q_2') PUBPRTY(ASPUB) REPLACE
    DEFINE SUB('MY_TOPIC_3') TOPICSTR('my-topic') DESTCLAS(PROVIDED) DEST('Q_3') PUBPRTY(ASPUB) REPLACE
    DEFINE SUB('MY_TOPIC_4') TOPICSTR('my-topic') DESTCLAS(PROVIDED) DEST('Q_4') PUBPRTY(ASPUB) REPLACE
    ​


    The topic is persistent and the value of PMSGDLV is set ASPARENT, which in our case is ALLDUR.  As I understand the error the publish failed for at least one of the subscribers.  Even though the problem resolved I would like to better understand the issue. 

    What are some possible reasons this would occur with these types of subscriptions?  I did notice that one of the queues had reached its max depth.  Would that condition triggered the failure?

    Thanks,
    Jim  



    ------------------------------
    Jim Creasman
    ------------------------------


  • 2.  RE: Help understanding MQRC_PUBLICATION_FAILURE error.

    IBM Champion
    Posted Fri May 13, 2022 06:41 AM

    Any failure in the pub/sub engine to place a copy of the published message on a subscriber queue can result in MQRC_PUBLICATION_FAILURE if the [N]PMSGDLV setting is such that you get a notification.

    So, yes, MQRC_Q_FULL is one such possibility, and probably the most likely reason for it I think. Remember you can mitigate this with a DLQ and setting USEDLQ(YES) on the topic. A successful put to the DLQ also counts as success in this frame.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 3.  RE: Help understanding MQRC_PUBLICATION_FAILURE error.

    IBM Champion
    Posted Fri May 13, 2022 06:49 AM

    I just noticed something else you said, "the topic is persistent" - no it isn't. This is same as saying "the queue is persistent". That doesn't happen either. What you are referring to is default persistence to be used if an application doesn't explicitly set the persistence itself.

    There was a very recently published IBM Support Doc on this subject (for queues but it applies just as equally for topics). Suggest you have a read.

    Can a Non-Persistent message be put into an IBM MQ Queue that has attribute DEFPSIST equal to YES?

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 4.  RE: Help understanding MQRC_PUBLICATION_FAILURE error.

    IBM Champion
    Posted Fri May 13, 2022 08:25 AM
    Thanks for the clarification, Morag.  I was referring to the default message persistency we have set.  Our approach has been to set the desired persistency/expiration on the queue/topic.  At this time none of our clients override the default behavior (though I realize they could with message options).

    We're thinking through how we want to resolve this.  One solution is assigning a DLQ.  However, that queue likely would have also filled up under the particular circumstances.  We were doing load testing at the time with a high volume of messages, and the team "forgot" to start one of the consumers.  It was a good test, none the less, as it exposed a design issue in the system that we need to think through -- should the publish operation be considered a fail if one subscription fails?  The team is working on that answer.

    ------------------------------
    Jim Creasman
    ------------------------------



  • 5.  RE: Help understanding MQRC_PUBLICATION_FAILURE error.

    IBM Champion
    Posted Fri May 13, 2022 01:28 PM
    "I was referring to the default message persistency we have set.  Our approach has been to set the desired persistency/expiration on the queue/topic. "

    I would avoid this, in my opinion. Who's responsible/accountable for the message's persistence? 

    Option A. If its the app, they should explicitly code Persistence yes or no. Ignoring it (so it picks up q default) or explicitly coding gimmie the q default should be against standards. Make the app decide yes or no, the app owns it. And nothing the MQ Admin does with the queue's setting can over ride it if the app picks yes or no. Clear accountability.
    Or
    Option B. Control it at the queue level. MQ Admins are in charge. Except they are not, because any app can come over the top and explicitly set yes or no overriding the MQ admins choice. 

    Option A is better in my opinion.

    ------------------------------
    Peter Potkay
    ------------------------------