On 07/08/2011 07:33 PM, Gang, Litao wrote:
Hello there,
I have a simple question on the C++ api.
I want to handle the case where the message destination is not reachable.
Right now, w/o doing anything, I got an error like
2011-07-08 10:53:17 warning Exception received from broker: not-found:
not-found: Queue not found: 7efc7c38-7e73-4aa4-9fca-84c0e38ad4b7
(qpid/broker/SessionAdapter.cpp:755) [caused by 2 \x08:\x01]
2011-07-08 10:53:17 error anonymous.4a1e7ce0-52ee-4186-9439-d6bafd54f5b1 error:
Queue 7efc7c38-7e73-4aa4-9fca-84c0e38ad4b7 does not exist
terminate called after throwing an instance of 'qpid::messaging::NotFound'
what(): Queue 7efc7c38-7e73-4aa4-9fca-84c0e38ad4b7 does not exist
It is caused by an unreachable queue. If I use client::message, I can specify the
deliveryProperty, use
setDiscardUnroutable<http://qpid.apache.org/apis/0.10/cpp/html/a00057.html#ae0ce53d8840f12035958f20779af474e>(true).
But I am using messaging::message class, and the only method I guess I can use is
setProperty(). But I did not find any document, which property name I should use,and
how to set it.
Could anybody shed some lights on this?
The discard-unroutable property is not available in the messaging API.
In any case it will not help with the situation you are encountering.
The error you are seeing is due to the messaging API implementation
issuing a passive declare for the queue to which you are creating a
sender. This is deliberate and is intended to help highlight
configuration errors.
If the queue is deleted after the sender is created, then you will not
see this error. It is only triggered by the creation of the sender, not
the sending of messages.
The discard-unroutable flag will not affect this. Since the default
exchange does not have an alternate-exchange, the only effect this
property would have is when the messages transferred also have the
accept-mode set to explicit. In that case if discard-unroutable is
false, the message *should* result in a reject (if true it will just be
discarded). Note that at present the c++ Qpid broker does not actually
do this reject (see QPID-1490).
At present you would have to catch the exception from creating the
sender, and (sadly) recreate the session. This is inherited from the
AMQP specification, but I believe it is the wrong behaviour and that the
messaging API should keep the session usable (though the underlying AMQP
session will be lost). I have raised
https://issues.apache.org/jira/browse/QPID-3179 to cover that, but
haven't really spent any time looking at the deeper issues yet.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
