The documentation says

"For AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE modes, the completion of the message is identified by either

• successful returning from the MessageConsumer.receive() methods
• successful returning from the onMessage() call of the MessageListener()"

However, this doesn't work the way it's described, when "DUPS_OK_ACKNOWLEDGE" mode is in use. This is because, the JMS broker buffers message ACKs and ACK them as a batch at once. The default value is 2000, which means JMS provider buffers 2000 ACKs before sending them. And this causes messages to remain stuck when "DUPS_OK_ACKNOWLEDGE" is used with StrictMessageOrdering.

For an example, when you send messages M1 to M10 to the destination queue/A, M2 won't get delivered unless M1 is ACKed. With the default configuration JMS provider won't ACK them unless it buffers 2000 messages, which could lead these messages (M1-M10) to remain stuck.

Therefore, you're required to specify DupsOKBatchSize=1 on the connection factory, when "DUPS_OK_ACKNOWLEDGE" is used with StrictMessageOrdering