You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2011/03/08 04:48:05 UTC
JMS Queue Browser Implementation
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
Re: JMS Queue Browser Implementation
Posted by Gordon Sim <gs...@redhat.com>.
On 03/08/2011 04:47 PM, Rajith Attapattu wrote:
>
>
> On Tue, Mar 8, 2011 at 5:27 AM, Gordon Sim <gsim@redhat.com
> <ma...@redhat.com>> wrote:
>
> On 03/08/2011 09:50 AM, Robert Godfrey wrote:
>
> On 8 March 2011 04:48, Rajith Attapattu<rajith77@gmail.com
> <ma...@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.
If each call to getEnumeration() creates a new subscription, then I'd
think that the cancellation should occur when the Enumeration is
exhausted or discarded.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: JMS Queue Browser Implementation
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Mar 8, 2011 at 5:27 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/08/2011 09:50 AM, Robert Godfrey wrote:
>
>> On 8 March 2011 04:48, Rajith Attapattu<ra...@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-subscribe@qpid.apache.org
>
>
Re: JMS Queue Browser Implementation
Posted by Robert Godfrey <ro...@gmail.com>.
On 8 March 2011 11:27, Gordon Sim <gs...@redhat.com> wrote:
> On 03/08/2011 09:50 AM, Robert Godfrey wrote:
>
>> On 8 March 2011 04:48, Rajith Attapattu<ra...@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).
>
>
Yeah - if this suggestion is in relation to the query on the Qpid user
mailing list then the problem there seems to be that the browsers are not
closing the subscriptions when they are done.
And, as an aside I would really like to understand the justification for
this pattern of querying by using browse... why not just use a no wait
receive?
-- Rob
Re: JMS Queue Browser Implementation
Posted by Gordon Sim <gs...@redhat.com>.
On 03/08/2011 09:50 AM, Robert Godfrey wrote:
> On 8 March 2011 04:48, Rajith Attapattu<ra...@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-subscribe@qpid.apache.org
Re: JMS Queue Browser Implementation
Posted by Robert Godfrey <ro...@gmail.com>.
Hi Rajith,
On 8 March 2011 04:48, Rajith Attapattu <ra...@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