time for QueueBrowser.getEnumeration().nextElement() and Enum.hasMoreElements

[rluktuke]

My question is what data structure that is returned by the queueBrowser.getEnumeration() method and what is its time complexity for Enumeration.nextElement() and Enumeration.hasMoreElements() ?

Test Scenario:

We are doing a test where there are around 1.5 million messages in a swiftmq queue.  The client uses QueueBrowser to get the list of messages and buffers them.  It peeks at each message, processes it and the pops it from the queue.  I see that as time passes, the time taken by the enumeration.nextElement() goes up at the rate of about 5 miliseconds per hour.

Client code is as below:

class JMSConnection {
Enumeration queueBrowserEnum;

MapMessage peekMessage() {
if(queueBrowserEnum == null || !queueBrowserEnum.hasMoreElements())
  queueBrowserEnum = (Enumeration<MapMessage>)queueBrowser.getEnumeration();

if(queueBrowserEnum.hasMoreElements())
  return queueBrowserEnum.nextElement();

return null;
}

}

Caller code:

class Caller {

time1 = getCurrentTime();
MapMessage = JMSconnection.peekmessage();
time2 = getCurrentTime();
system.out.println(time2 - time1); // this time progressively goes up

// do stuff with MapMessage

// pop message from queue
}


Any help regarding how to address the increase in access time will be appreciated.

[IIT Software]

If you consume each browsed message before you call nextElement(), a new index snapshot must be internally created in order to get the next message. That might create the delays.

The way how you work with JMS seems to be suboptimal. Rather to retrieve a message by a browser, process it and at the end consume it, you may just consume regularly (and rollback if you can't process it). That's much, much faster. Further, a message retrieved by a browser is not for processing but for viewing (browsing). It is not locked and while you browse, another consumer can process is and so it will be processed multiple times if you misuse a browser for that.