I have a setup where messages are sent from one MQ manager (production) to another (test). On the sender side, I created a Remote Queue that points to an Alias Queue on the receiver side. This Alias Queue redirects messages to a topic, allowing distribution on the test side.

However, an issue arises when one of the subscriptions is inactive. If the queue associated with that subscription reaches its Max Queue Depth, all other subscriptions stop receiving messages. When I check the channel status on the sender side, it shows a retrying state. It seems that if a message cannot be delivered to any of the subscriptions on the receiving side, the sender channel continuously retries.

Any help would be appreciated.

I have a setup where messages are sent from one MQ manager (production) to another (test). On the sender side, I created a Remote Queue that points to an Alias Queue on the receiver side. This Alias Queue redirects messages to a topic, allowing distribution on the test side.

However, an issue arises when one of the subscriptions is inactive. If the queue associated with that subscription reaches its Max Queue Depth, all other subscriptions stop receiving messages. When I check the channel status on the sender side, it shows a retrying state. It seems that if a message cannot be delivered to any of the subscriptions on the receiving side, the sender channel continuously retries.

Any help would be appreciated.

• ibm-mq

• Update: After more investigation I found the issue. The original queue is created with properties Default persistence: Persistence. Although the duplicate queue (using storage: streaming queue) is created with Not Persistence, the message received with property persistent. This make the to pile up even though on the remote side it is a queue. – Ashiful Commented Mar 14 at 10:52
• 1 You mention using stream queue, the persistence of messages streamed to the target queue can not be changed by the target queue's default persistence, persistence is determined at PUT time, steam queue will exactly copy the original message persistence. – JoshMc Commented Mar 14 at 14:42

3 Answers 3

It is entirely up to you what the behaviour is when a subscriber queue is full. You have several options.

• Have the channel use a Dead Letter Queue
  The channel can use a dead-letter queue which would result in the message being safely stored and allowing the channel to move onto delivering the next message. Ensure you have a queue named in the QMGR object attribute DEADQ and that the channel has USEDLQ(YES). This would result in no subscribers getting a copy of that one published message until the Dead-Letter Handler retries the put to the alias later on.

• Have the Publish Engine use a Dead Letter Queue
  When the publish to the subscribers happens, the publish engine can use a dead-letter queue which would result in the message being safely stored and allowing the channel to move onto delivering the next message. Ensure you have a queue named in the QMGR object attribute DEADQ and that the topic object has USEDLQ(YES). This would result in some of the subscribers getting a copy of that one published message, and the failing one getting it later when the Dead-Letter Handler retries the put.

• Tell the Publish Engine that it is allowed to Discard messages for any problematic subscriber queues
  Configure the topic object to use PMSGDLV(ALLAVAIL). This setting says that persistent messages are only delivered to available subscriber queues, any unavailable are ignored. There's no chance to deliver the missing publication later if you use this option.

I'm assuming that your messages are persistent given that the channel is unlikely to care about non-persistent messages, but for completeness be aware that there are actually two options on the topic, PMSGDLV (for delivery configuration of persistent messages) and NPMSGDLV (for delivery configuration of non-persistent messages).

To set these using MQ Explorer instead of MQSC, note that the Topic properties Non-persistent message delivery and Persistent message delivery are the equivalents and can be set to the value To all available subscribers to give the same behaviours as ALLAVAIL. These properties are in the General section of a topic.

I'm also assuming that your subscriptions are durable since if the application is not active and the subscription is still collecting messages that sounds like a durable one. For completeness, be aware that the values you can use in both PMSGDLV and NPMSGDLV attributes are:-

• ALL - all subscriptions must get a copy of the message

• ALLDUR - all durable subscriptions must get a copy of the message

• ALLAVAIL - all available subscriptions get a copy of the message

I have a setup where messages are sent from one MQ manager (production) to another (test).

Wow, that's dangerous. I do hope it is a one-way channel (Sender-Receiver) from PROD to TEST and that you did NOT create a Sender-Receiver channel from TEST to PROD.

On the sender side, I created a Remote Queue that points to an Alias Queue on the receiver side. This Alias Queue redirects messages to a topic, allowing distribution on the test side.

Ok, that sounds correct.

However, an issue arises when one of the subscriptions is inactive.

What issue? This is the crux of the problem, and you are missing its description.

1. What is the 'Durable' setting in the subscription?

2. What is the 'Expiry' setting in the subscription?

3. Did the subscriber(s) crash?

4. How many subscribers do you have who are subscribing to the subscription?

When I check the channel status on the sender side, it shows a retrying state. It seems that if a message cannot be delivered to any of the subscriptions on the receiving side, the sender channel continuously retries.

Working as designed. The destination queue is full so no more messages can be delivered to it. Hence, the sender-side MCA will not send more messages until the receiver-side MCA gives the ok and now the messages will pile up in the sender-side XMITQ.

Just to add more what Morag Hughson anserwed. The issue got resolved by modifying the Topic to have propterites Non-persistent message delivery and Persistent message delivery set to value To all available subscribers. These are properties in General section of a topic.