[
https://issues.apache.org/jira/browse/QPID-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217337#comment-13217337
]
Rajith Attapattu commented on QPID-792:
---------------------------------------
Thanks for sharing your thoughts on this.
I currently have a patch in our internal branch that does validate the queue
when trying to create the QueueBrowser.
So certainly in line with what you mentioned about checking for the presence of
the queue.
(I also agree with you that creating queues when creating consumers by default
is an aberration)
However the TCK failures are certainly forcing us to look at Queue validation
more broadly. Hence my questions.
It seems to me we need several types of validation.
1. One that checks for the presence of a queue, which as you mention needs to
be performed every time we use the Queue to create something (ex consumers,
browsers..etc)
2. Once that tries to resolve an address to see if it's indeed a Queue or a
Topic (unless explicitly specified).
3. One that actually acts upon the address instructions to create, assert a
Queue and acts on the node and link properties as instructed.
When I mentioned about validation with jndi or when getQueueName() was invoked,
I was thinking about #2 and,
When I mentioned "If that's the case then I believe we don't need the
validationQueue method here", I actually meant that step #2 should probably
have been done before, not inside the QueueBrowser implementation. "But I
totally missed the point that the JMS API expects us to check the presence of
the queue as well".
Currently we do all 3 in one method.
Rob, here's another interesting question.
Do we need to do step #3 when we create the QueueBrowser or when we create the
actual consumer(s) when getEnumeraiton() is called ?
That is if we need to create/assert the node, node bindings and link
properties/bindings at the time we create the Browser or when we create the
actual consumers.
> 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:[email protected]
