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
>
>
