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 14:58:44 GMT
Great!
And I can test it once it is ready to confirm it works.
Adel

> Date: Wed, 6 Apr 2016 15:46:49 +0100
> Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
> From: rob.j.godfrey@gmail.com
> To: users@qpid.apache.org
> 
> Thanks!
> 
> I'll raise a JIRA to cover this later this afternoon, as well as some for
> the configuration options we discussed earlier.
> 
> -- Rob
> 
> 
> On 6 April 2016 at 15:20, Adel Boutros <adelboutros@live.com> wrote:
> 
> > 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.godfrey@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 <adelboutros@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.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