On Tue, Mar 8, 2011 at 5:27 AM, Gordon Sim <g...@redhat.com> wrote: > 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). >
The subscriptions are only cleaned up if 'close()' is called. In this case the user is repeatedly calling 'getEnumeration()' without closing the browser. It's not wrong as per the JMS API, but as Rob suggested it's probably not the best way to do what he wants. I think he has now resorted to closing the browser and recreating it each time. > [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 > >
