Here it is:
https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage
When you read the last section "Unrouteable Messages", it is only talking about
message being discarded on the broker and not that the client will receive an
exception.
Regards,Adel
> Date: Wed, 6 Apr 2016 14:33:07 +0100
> Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> From: rob.j.godf...@gmail.com
> To: users@qpid.apache.org
>
> Can you point me at the section in the document you are referencing? (Most
> of the documentation was written with earlier versions of the protocol in
> mind so there may be a few places where the AMQP 1.0 behaviour differs from
> that of earlier versions).
>
> -- Rob
>
> On 6 April 2016 at 14:26, Adel Boutros <adelbout...@live.com> wrote:
>
> > Hello Rob,
> > Thank you for explanation, it makes complete sense and the proposed
> > configuration would indeed be highly valued.
> > So if I understand correctly, today there is no way to configure it. In
> > that case, a workaround would consist in setting for the exchange in
> > question an alternate exchange which will be linked to a queue without any
> > binding and this will be the queue where all unrouted messages would arrive
> > (Something like a default queue). Do you agree?
> > Also, would it be possible to update the documentation on the website to
> > include a mention to this behavior "and will generate an exception on the
> > JMS client-side"? This is to avoid people having to debug through code to
> > reach the same findings.
> > Regards,Adel
> >
> > > Date: Wed, 6 Apr 2016 10:18:01 +0100
> > > Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> > > From: rob.j.godf...@gmail.com
> > > To: users@qpid.apache.org
> > >
> > > Hi Adel,
> > >
> > > As you have discovered, currently when the Java Broker receives a message
> > > over AMQP 1.0 where the message cannot be routed to a queue, it rejects
> > the
> > > message (on the basis that the broker has not actually accepted the
> > > transfer of responsibility as it will be discarding it). This is
> > probably
> > > appropriate when you are looking for the destination to behave like a
> > > "queue" but not when you are expecting "topic" like behaviour. In
> > earlier
> > > versions of AMQP, the client could indicate via the "mandatory" flag as
> > to
> > > whether the broker should consider the failure to route to be an error or
> > > not - there is no such mechanism in 1.0. Having said that, I would
> > assume
> > > that for topic like "fire and forget" behaviour, the client should be
> > > sending the transfers pre-settled (since it does not actually care about
> > > the outcome). It may be that the best solution is to introduce
> > > configuration on the exchange to indicate whether incoming links should
> > be
> > > sent rejections, or messages silently discarded - and then to be able to
> > > override this behaviour on a per link basis using some form of link
> > target
> > > property.
> > >
> > > -- Rob
> > >
> > > On 4 April 2016 at 17:30, Adel Boutros <adelbout...@live.com> wrote:
> > >
> > > > Hello,
> > > > In the documentation of Qpid Java Broker 6.0.0, it is mentioned here
> > that
> > > > unroutable messages will be discarded eventually.
> > > > I have a test where a queue is bound to a topic and a message is sent
> > > > which doesn't match the binding filter on purpose. Instead of the
> > message
> > > > being just discarded, the sender is receiving an error informing him
> > the
> > > > message was rejected.
> > > > Is this expected? shouldn't the sender be "warned" instead of getting
> > an
> > > > exception?
> > > > Another workaround is to implement a "default" queue which will be
> > called
> > > > from the alternate exchange but I prefer to check with you this
> > behaviour
> > > > before implementing the workaround.
> > > > Test caseCreate topic "T"Create queue "Q"Create binding between T and Q
> > > > using a binding key BK1Have a consumer listen to QHave a sender send
> > to T a
> > > > message with a binding key BK2
> > > > Output client-sidejavax.jms.JMSException: Unknown error from remote
> > peer
> > > > at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:125)
> > > > at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpFixedProducer.processDeliveryUpdates(AmqpFixedProducer.java:232)
> > > > at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:804)
> > > > at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:92)
> > > > at
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:701)
> > > > at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> > > > at java.util.concurrent.FutureTask.run(FutureTask.java:262) at
> > > >
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> > > > at
> > > >
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> > > > at
> > > >
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > > > at
> > > >
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > > > at java.lang.Thread.run(Thread.java:744)
> > > > Checking the code of
> > > > org.apache.qpid.server.exchange.AbstractExchange#send, when a queue is
> > not
> > > > found in the routing table of the Exchange and no alternate exchange is
> > > > defined, then the message is considered as
> > > > org.apache.qpid.amqp_1_0.type.messaging.Rejected. This is what the
> > > > org.apache.qpid.amqp_1_0.type.Outcome has as value. Then client side,
> > the
> > > > code checks the value of the Outcome and sets an error in case it was
> > > > rejected.
> > > >
> > org.apache.qpid.jms.provider.amqp.AmqpFixedProducer#processDeliveryUpdates}
> > > > else if (outcome instanceof Rejected) {
> > > > LOG.trace("Outcome of delivery was rejected: {}", delivery);
> > > > ErrorCondition remoteError = ((Rejected) outcome).getError();
> > > > if (remoteError == null) {
> > > > remoteError = getEndpoint().getRemoteCondition();
> > > > }
> > > >
> > > > deliveryError = AmqpSupport.convertToException(remoteError);
> > > > }
> > > > Regards,
> > > > Adel Boutroswww.murex.com
> >
> >
