qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adel Boutros <adelbout...@live.com>
Subject RE: Unroutable messages in Java Qpid Broker 6.0.0
Date Wed, 06 Apr 2016 13:26:32 GMT
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.godfrey@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 <adelboutros@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
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message