qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Unroutable messages in Java Qpid Broker 6.0.0
Date Mon, 18 Apr 2016 10:51:04 GMT
Hi Adel,

I'm just working on some other refactoring on the Java Broker AMQP 1.0
implementation...

Once I've completed that I'll take a look at implementing something in this
space - possibly towards the end of this week,

Hope this helps,
Rob

On 18 April 2016 at 11:09, Adel Boutros <adelboutros@live.com> wrote:

> Hello Rob,
> Do you have any updates on this issue?
> Regards,Adel Boutros.www.murex.com
>
> > From: adelboutros@live.com
> > To: users@qpid.apache.org
> > Subject: RE: Unroutable messages in Java Qpid Broker 6.0.0
> > Date: Wed, 6 Apr 2016 16:58:44 +0200
> >
> > 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