qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-792) Need to revise QueueBrowser implementation strategy
Date Mon, 27 Feb 2012 18:06:49 GMT

    [ 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:dev-subscribe@qpid.apache.org

View raw message