CODEWITHSUNDEEP
messagingibm-mq
user1735718
user1735718

Reputation: 45

IBM MQ - One to many message flow

My question is about one to many message flow using a single queue in IBM MQ. I am new to MQ.

Scenario - Suppose there are multiple processes reading from a single queue, when they read a message from the queue , do all of them get the same message.

ie - Lets say there are no messages on the queues and two readers are blocked on it (executed the MQGET on it).

  1. 1 messages come on the queue (logically meant for process 1). Will both of them get the message as both were waiting (executed the MQGET on it) or only to one process randomly.

  2. once the message is read is it removed from the queue.

  3. If messages are removed from queue after reading ,suppose process 1 is processing and a new message comes for it and instead process 2 gets it and is deleted. When process 1 tries to get it wont get any message. Is this possible.

basically i want to know how to manage multiple processes on a single queue so that the messages go to right process and no message is missed.

Upvotes: 2

Views: 3429

Answers (1)

T.Rob
T.Rob

Reputation: 31832

Multiple apps reading on a queue compete for messages if no selectors are used. Straight FIFO reads deliver messages to competing apps such that any one message is delivered once to one of the app instances. Assuming the app gets the message outside of syncpoint or issues a COMMIT then no other app will see the message and it will be permanently removed.

Things that change the behavior include:

  • Message selectors. If the apps get messages by MsgID or other selection criteria the QMgr makes only messages that meet the selection available to the app. If multiple app instances use the same selection criteria, they compete for messages within the subset defined by the selector.
  • Rollbacks. If an app rolls back a message it becomes available again and may go to the same or different application instance.
  • Priority delivery. Behaves as for FIFO except that messages are ordered by priority with the highest priority ones being delivered first.
  • Message groups. It is possible to select messages by group ID and to specify that the GET does not succeed until all messages in the group are present. If a partial group lands on the queue it is possible to see depth on the queue but no messages delivered to the application.

Looking at your questions one at a time:

  1. messages come on the queue (logically meant for process 1). Will both of them get the message as both were waiting (executed the MQGET on it) or only to one process randomly.
    Queues are cheap. Don't put messages destined for App1 and App2 on the same queue if the apps are reading FIFO. The only way to share a queue across different apps (or different instances of the same app) is if all things reading from the queue use selectors and that the selectors effectively segregate the messages so they go to the right app. If even one instance is running FIFO then it doesn't work.

  2. once the message is read is it removed from the queue.
    Yes, provided the app issues a GET followed by COMMIT or a GET outside of syncpoint. If the app browses the queue, then the message remains and becomes available to other apps once the browse cursor moves off of it.

  3. If messages are removed from queue after reading ,suppose process 1 is processing and a new message comes for it and instead process 2 gets it and is deleted. When process 1 tries to get it wont get any message. Is this possible.
    Absolutely. As noted earlier, apps or app instances reading the queue in a FIFO mode will compete for messages. If indeed a message arrives "for process 1" then either use selectors that prevent other processes from reading the message or use different queues for each instance.

Upvotes: 2

Related Questions