2009/6/23 Robbie Gemmell <robbie.gemm...@gmail.com>: > Hi, just wondered peoples thoughts on this situation? > > The queue mbeans have an operation to view a list of the messages on the > queue, specifying low/high message number of interest: viewMessages(int > fromIndex, int toIndex). These numbers are indexed by position on the queue. > > Using the results of this operation to determine a message's AMQ message ID, > you can then view the contents of a message using viewMessageContent(long > msgID) indexed by the AMQ message ID long value gained from looking at the > results of the viewMessages operation. > > In the new UI for the console I am currently doing the viewMessages() > operation across the entire positive Integer range and displaying a list of > all messages on the queue for users, and when they use the > viewMessageContent() operation the UI is implicitly fetching the AMQ ID from > the selected message to perform the operation. As such, users are no longer > exposed to the difference in indexing (though anyone using JConsole etc > still will be). > > The main issue remaining would be that the viewMessages() operation is > inherantly limited to the first 2^31 undelivered messages on the queue at > any given time. When I originally noticed that viewMessages was using ints > and viewMessageContent was using longs i had thought the situation was worse > than it actually is, because it mentioned in the interface that they are > indexed differently(though becomes obvious after use). However, some of the > other related methods such as getMessageCount() are also limited to int > (getMaximumMessageCount() returns long however) and the implementations of > the methods in SimpleAMQQueue are inherantly limited to int as well through > use of Lists etc. > > Given that it is 2^31 undelivered messages in the queue which can be viewed, > should I still look to add expanding it to Long to the end of the list > following the other UI work or that sufficient and I can just leave it be > since it wont be of any need until such time as the Queue implementation > supports it anyway?
I think you can just leave it as is. You'd need quite a beefy 64Bit machine stocked with RAM to get close to 2^31 messages in memory. When Flow to Disk is implemented in the broker then the potential for more messages will occur but for now I don't think we need worry about it. Martin > Robbie > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
