You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Adel Boutros <ad...@live.com> on 2016/04/04 18:30:38 UTC
Unroutable messages in Java Qpid Broker 6.0.0
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
Re: Unroutable messages in Java Qpid Broker 6.0.0
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ad...@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 <ad...@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 <ad...@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 <ad...@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
> > > > > >
> > > > > >
> > > >
> > > >
> >
>
>
RE: Unroutable messages in Java Qpid Broker 6.0.0
Posted by Adel Boutros <ad...@live.com>.
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 <ad...@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 <ad...@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 <ad...@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
> > > > >
> > > > >
> > >
> > >
>
RE: Unroutable messages in Java Qpid Broker 6.0.0
Posted by Adel Boutros <ad...@live.com>.
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 <ad...@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 <ad...@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 <ad...@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
> > > >
> > > >
> >
> >
Re: Unroutable messages in Java Qpid Broker 6.0.0
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ad...@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 <ad...@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 <ad...@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
> > >
> > >
>
>
RE: Unroutable messages in Java Qpid Broker 6.0.0
Posted by Adel Boutros <ad...@live.com>.
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 <ad...@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 <ad...@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
> >
> >
Re: Unroutable messages in Java Qpid Broker 6.0.0
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ad...@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 <ad...@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
>
>
RE: Unroutable messages in Java Qpid Broker 6.0.0
Posted by Adel Boutros <ad...@live.com>.
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 <ad...@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
Re: Unroutable messages in Java Qpid Broker 6.0.0
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ad...@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