Hi Rajith, 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? > 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. > > It seems to me that this is an example of poor application design and not something we should be trying to accommodate. Moreover when would we know to stop keeping the local queue replica? The one case where I can plausibly think an application might want to use this pattern (and not think that it is going to be hideously expensive) is if it is testing whether there are any messages on the queue which meet a particular selection criteria. It seems to me that the reason this may be expensive for the C++ broker is that server-side selectors are not (to my knowledge) yet implemented. However for this implementing server side selectors would be a better solution. If the application truly wants to have an up-to-date local copy of the queue which is can continually be browsing back and forth I would argue that the JMS API is not appropriate for that use case. > 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. I'm not convinced by the use case, the queue replication is only in the C++ and not the Java Broker - meaning even more complexity in the client... > 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 ? > > I'd need a lot of convincing that this was a worthwhile addition. regards, Rob
