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
