Each time the getEnumeration method is called we create a new consumer. I fully understand the reasons as to why each enumeration needs to have it's own consumer. However I am wondering if we could optimize this a bit more as an suspecting user may end up creating lots of consumers by repeatedly calling getEnumeration in a bid to receive the latest snapshot. This may put a strain on the broker as well as the client side as it will contain consumers (and local message queues) for no good reason.
If we can receive queue events (only interested in dequeues here) then we can maintain a single local message queue per Queue browser. We could potentially leverage the async queue replication strategy (implemented in the c++ broker) here all though I am not sure if a similar functionality exists in the Java broker. Then each enumeration is just a light weight object which maintains only a pointer (index) to the local queue. If a dequeue event is received then that message is removed from the local queue. The local queue can be filled on demand using the sync receive method. Thoughts ? Regards, Rajith
