On 03/08/2011 09:50 AM, Robert Godfrey wrote:
On 8 March 2011 04:48, Rajith Attapattu<rajit...@gmail.com> wrote:
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.
Is creating a consumer really that expensive? Or is the issue that the
whole queue is then (potentially) sent to the client?
Or is it that the subscriptions are never cleaned up correctly? (The
mail on the user list talked about increasing numbers of subscriptions).
[snip]
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.
I'm not very enthusiastic about this. Where possible I think we should be
sticking to standard AMQP functionality.
+1
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
