Returning to this... :) I have widened the viewMessages(int from, int to) method to viewMessages(long from, long to), so it now supports viewing all messages on queues with > 2^31 messages on it. The queues themselves however only partially support having that many messages.
The underlying SimpleQueueEntryList is obviosuly ok, but the message count is store in an AtomicInteger and will wrap, and many of the ancillary methods which are part of the queue implementation use List's in their return types, which use ints for index and size and so again are limited. These things could of course be changed(but will divert quite a bit from the actual console in the coding run-in...), but the stickier point is the " Integer getMessageCount() " method which is exposed through the queue mbeans as an attribute of the mbean. Changing this to a Long will break compatibility with the existing JMX CLI, as it expects Integer return types and uses the method in quite a number of places in its implementation, and will throw a wobbly if presented with a Long. The RCP management console wouldnt care, as it currently only exposes the method through Attributes tabs using introspection (though i had considered doing something just the other day which would have involved me calling it). I just wrote a little test that stuffed null Object's into various types of List. On a 4GB machine with 2GB of swap, I hit between 100 and 200 million entries before OOM, depending on the List type used. Broker + actual messages would obviously reduce that considerably, meaning it isnt likely to be an immediate problem unless someone builds a really nice machine with intent of operating entirely out of one queue. As a a result, I think it would be best to leave this attribute the way it is for now and save such a change for future, timing it with another general break in management compatibility. Thoughts? Robbie 2009/6/24 Aidan Skinner <aidan.skin...@gmail.com>: > On Wed, Jun 24, 2009 at 11:24 AM, Robbie > Gemmell<robbie.gemm...@gmail.com> wrote: > >> requiring JConsole etc users make that class available to use the results, >> viewMessages(from, to) would still need be limited to viewing at most 2^31 >> at a time...just any 2^31 instead of the first 2^31 as at present. > > Cool, that's much better - they can get to the end of the queue if > they need too. > > - Aidan > -- > Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org > "A witty saying proves nothing" - Voltaire > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
