[
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:[email protected]
