"
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
------------------------------
Original Message:
Sent: Fri May 13, 2022 08:24 AM
From: Jim Creasman
Subject: Help understanding MQRC_PUBLICATION_FAILURE error.
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
Original Message:
Sent: Fri May 13, 2022 06:48 AM
From: Morag Hughson
Subject: Help understanding MQRC_PUBLICATION_FAILURE error.
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
Original Message:
Sent: Thu May 12, 2022 11:35 AM
From: Jim Creasman
Subject: Help understanding MQRC_PUBLICATION_FAILURE error.
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) REPLACEDEFINE SUB('MY_TOPIC_1') TOPICSTR('my-topic') DESTCLAS(PROVIDED) DEST('Q_1') PUBPRTY(ASPUB) REPLACEDEFINE SUB('MY_TOPIC_2') TOPICSTR('my-topic') DESTCLAS(PROVIDED) DEST('Q_2') PUBPRTY(ASPUB) REPLACEDEFINE SUB('MY_TOPIC_3') TOPICSTR('my-topic') DESTCLAS(PROVIDED) DEST('Q_3') PUBPRTY(ASPUB) REPLACEDEFINE 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
------------------------------