[
https://issues.apache.org/jira/browse/QPID-6701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711561#comment-14711561
]
Gordon Sim commented on QPID-6701:
----------------------------------
The key purpose of the 'resolution' is to determine how to construct the
message.transfer request in 0-10, specifically what to put in the destination.
You still have to know this even if the thing you are sending to is neither a
queue nor an exchange.
The 0-10 protocol strictly speaking only allows transfers to 'exchanges' and
subscriptions from 'queues', but I think you could argue for a fair degree of
leeway in what the actual behaviour is. I would argue that the most obvious way
to send to some extension defined thing would be by specifying it's name in the
message.transfer's destination field. If you did that and the thing named in
that field doesn't exist, you will still get an exception. (Of course it might
well also make sense to treat that thing as an exchange for the purposes of an
exchange.query (returning as the 'type' some indication of what manner of thing
it is) and ideally even exchange.bound. That way resolution would work as
normal.
Point 3. in Rajith's mail would only happen if you were publishing to the
default exchange, using the name of the thing as the value for the routing-key.
The default exchange is an unfortunate concept. However given the silent
dropping of messages, I think it only makes sense to use that for things that
can be queried via queue.query (or again exchange.bound), even if it isn't a
queue.
Having messages get silently dropped where previously an error would result is
in my view a real regression. I think either the default in the case of being
unable to resolve it as a queue or an exchange, should be to treat it as
something that goes in the destination filed of the transfer, meaning transfers
would at least fail with an error. Ideally providing a standard way over 0-10
to test the existence of these non-standard things would be good, and that
would allow the resolution to proceed as before.
> [Regression btw 0.30 - 0.32] If address doesn't resolve an exception is not
> thrown
> ----------------------------------------------------------------------------------
>
> Key: QPID-6701
> URL: https://issues.apache.org/jira/browse/QPID-6701
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: 0.32
> Reporter: Rajith Attapattu
> Assignee: Keith Wall
> Priority: Blocker
> Fix For: qpid-java-6.0
>
>
> If you run "java -cp $CP org.apache.qpid.example.Spout non-existing-node",
> 1. In 0.30 you get an exception with the cause "org.apache.qpid.AMQException:
> Exception occured while verifying destination"
> 2. In 0.32 no such exception is thrown.
> The issue is in the resolveAddress method in AMQSession class.
> If resolved is false no action is taken. There are a couple issues with this.
> 1. A producer can be created to a non existent queue or exchange.
> 2. Messages being dropped - While sending to a non existing exchange will
> result in an error, sending to a non existent queue via an exchange will
> simply result in messages being dropped.
> 3. The address will continue to be resolved as there was no error the
> previous time.
> We should throw an exception if resolved == false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
