Resolution: Feedback Received
Affects Version/s: 5.12.0, 5.15.2
Fix Version/s: None
Linux, CentOS 7
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
The default broker behavior for message groups uses a CachedMessageGroupMap with a least-recently-used cache with a capacity of 1024. When more that 1024 group IDs are used messages can be consumed out-of-order.
Configure two consumers for a queue.
Send a message with group ID '0' that requires a long time to consume.
Send 1024 additional messages with group IDs '1' through '1024' that require a short time to consume.
Send a message of group ID '0' that requires a short time to consume.
The second message in group '0' is consumed after the first message in group '0'
The second message in group '0' is consumed before the first message in group '0' has finished.
The LRU cache is evicting the group to consumer mapping for group '0' before the second message arrives, allowing the second message in group '0' to be processed by a different consumer than the first message.
Using the MessageGroupHashBucket or the SimpleMessageGroupMap results in the expected behavior.
Output shows message 1025 finishing before message 0