Description of problem:
Browsing messages in a queue slows down exponentially as the number of messages in the queue increases, while maxing out the CPU available.
Version-Release number of selected component (if applicable):
MRG Messaging 1.2
Steps to Reproduce:
1. Create a queue
2. Add a number of messages to the queue (say, 25,000)
3. Read them off the queue in browse mode (ACQUIRE_MODE_NOT_ACQUIRED), i.e. read the messages off the queue but do not acknowledge them (leave them on the queue). Note the time that it takes.
4. Double the number of messages on the queue (to 50,000)
5. Again, read them in browse mode.
It takes about 4 times as long to read twice as many messages. This ratio continues if the queue is made even larger.
Performance degradation should be closer to linear.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
C: reading messages from a queue sequentially without taking them off the queue (browse mode)
C: performance scales poorly as the size of the queue grows
F: change the algorithm for traversing through the messages
R: the next message is found more quickly, even for large queues
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.