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 17:20:49 GMT

    [ https://issues.apache.org/jira/browse/QPID-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217306#comment-13217306
] 

Rajith Attapattu commented on QPID-792:
---------------------------------------

{code}
+ // TODO - should really validate queue exists, but we often rely on creating the consumer
to create the queue :(
+ // _session.declareQueuePassive( queue );
{code}

Sorry for hijacking this JIRA to raise an issue with Queue validation in general. But this
issue is good use case to get some understanding into the more general issue of queue validation.

Rob, I agree that it would be nice if we can validate the Queue at the time we do session.createQueueBrowser().
But I'm not sure if we should be validating the queue here or much earlier in piece.
One issue is that once the destination is looked up, an application can call getQueue() and
currently if ADDR is used this returns null.
(With BURL it's not an issue as the queue name is explicitly given)

The above is causing numerous TCK failures. So I wonder for Queues, if we should be validating/resolving
them at the time it's being retrieved from jndi.
(This may or may not be possible as we might not have a connection/session in place).

If that's the case then I believe we don't need the validationQueue method here. For BURL
we always create the queue for a consumer so this check becomes unnecessary. 

However a potential issue here is where a Queue that's being created or resolved earlier could
have been deleted. But that could happen even between creating the browser and calling getEnumeraiton()
or between successive getEumeration() methods. Since we always create/resolve the queue (or
create with BURL) when creating a consumer this can be caught and handled.
                
> 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


Mime
View raw message