You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (Resolved) (JIRA)" <ji...@apache.org> on 2012/02/27 23:01:58 UTC
[jira] [Resolved] (QPID-792) Need to revise QueueBrowser
implementation strategy
[ https://issues.apache.org/jira/browse/QPID-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell resolved QPID-792.
---------------------------------
Resolution: Fixed
I'm going to go ahead and accept the changes on this for now, they seem reasonable and very much in the spirit of the JIRA.
The additional discussion on queue validation should probably move to the dev list as suggested, but I guess I can repost this if it does, so while I'm here...
I also think that the (Java) client shouldnt be making gueses as to whether something is a Queue or a Topic, as I'm sure was fairly evident from previous mailings on the subject last year. If that questionable behaviour is causing pain, then we should at least consider simply not doing it. Destination is itself only the parent interface of Queue and Topic, it doesnt actually offer any methods (even the toString, though for backwards compatibility reasons admitedly) and really only serves to allow creating Topic and Queue consumers etc without having to have a specific Session type. I realise forcing users to specify queue or topic in the address string wouldnt be consistent with the other clients, but I do think its worth noting that the Java client *isn't* entirely consistent with the other clients for obvious reasons and trying to make it more so isnt necessarily always going to be a helpful or useful thing.
> Need to revise QueueBrowser implementation strategy
> ---------------------------------------------------
>
> Key: QPID-792
> URL: https://issues.apache.org/jira/browse/QPID-792
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Rajith Attapattu
> Assignee: Robbie Gemmell
> Fix For: 0.15
>
>
> While debuggin and issue I noticed the following behaviour in the AMQQueueBrowser class.
> 1) When we create a queue browser we do a subscribe immediately
> followed by a cancel. (And then we subscribe again when we enumerate).
> The rationale for doing so it to verify the selector is valid. This is
> very confusing for customers who look at the log and it is not appropriate IMHO.
> Currently we use client side selectors, so it is easy validate this. The
> above step is completely unnecessary.
> If we are to use server side selectors the right way to do is
> a)Send a subscribe with the selector
> b)Give message credits only when you call the enumerate method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org