Are the remaining messages selectively stored in FIFO (MQ) order?

Question

Using JMS and WebSphere MQ, if I use a message selector to selectively remove from the queue, and there are several messages with the same selection criteria, am I guaranteed to deactivate the first message that matches?

eg. specified message queue

• {color: pink, name: alice}
• {color: blue, name: bob}
• {color: red, name: charlie}
• {color: blue, name: doug}

if I cross out with the color='blue' selector, am I guaranteed to deactivate {color: blue, name: bob} ? Or is there a chance that I could get {color: blue, name: doug} instead, even if it goes farther down the line?

Answer 1

Refer to the RESCANINT properties of the various WMQ Connection Factory implementations. From the manual:

When a message consumer in a point-to-point domain uses a message selector to select which messages it wants to receive, the WebSphere JMS MQ Client looks for the WebSphere MQ queue for matching messages in the sequence defined by the MsgDeliverySequence attribute of the queue. When the client finds a suitable message and delivers it to the consumer, the client resumes the search for the next suitable message from its current position in the queue. The client continues to search the queue this way until it reaches the end of the queue, or until the time interval in milliseconds, determined by the value of this property, has expired. In each case, the client returns to the beginning of the queue to continue the search, and a new time interval begins.

The idea is that in a very busy queue with priority delivery, some messages with a higher priority may be higher in the queue than the current position of the selector. Theoretically, a message with a higher priority should be consumed first, but the consumer will not see it if he is not looking for the chief of the queue. The cursor is reset to the head of the queue either upon reaching the end, or upon reaching RESCANINT. The RESCANINT setting allows you to configure how quickly you want the selector to find these messages with a higher priority.

RESCANINT does not apply to FIFO delivery. Another case where this can happen is the presence of multiple threads with overlapping selection criteria. In this case, one thread may contain a message under the lock, and then release it. Although the message may be entitled to the second thread, if this thread has already passed this position in the queue, then it takes a hit at the end of the queue or RESCANINT to restart the cursor to find the message.

The rescan interval is milliseconds, and the default is 5000. Any positive integer value is accepted, although a value too low causes an interruption because the cursor is constantly reset before any messages can be used.

As a practical matter, you will receive messages if the queue is FIFO, and you only have one reader in the queue for which the messages are allowed, regardless of what RESCANINT is set for. If the message order should be strictly preserved, there are additional considerations described in Sequential message search . They come down to messages that have only one path from the manufacturer to the consumer when considering channels, synchronizing points, etc.

Answer 2

See the chapter " Order of receiving messages from the queue " and the following: " Receiving a specific message ".

To summarize: the only way to get a message that ignores the FIFO order is to get a specific message by its message id or correlation id. The queue can also be configured for delivery in FIFO + priority order, but this is not an option that you consider. Finally, organizing messages makes it difficult if the messages are grouped, but again, this is not your case.