Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
MIME-Version: 1.0
In-Reply-To: <DUB112-W35206BEC80C867DEE22EEECD9F0@phx.gbl>
References: <DUB112-W4354A60505388140791D3FCD9D0@phx.gbl>
	<CACsaS95zfcCfa+34TE82seuJiUH=qw-PH_vPrzcPKzYkM3nSkQ@mail.gmail.com>
	<DUB112-W86A49D855EE4793AEB676FCD9F0@phx.gbl>
	<CACsaS97t7b+pAyWxRGDANDuZGm3chP5_g95jok+cEtxu36bHHg@mail.gmail.com>
	<DUB112-W35206BEC80C867DEE22EEECD9F0@phx.gbl>
Date: Wed, 6 Apr 2016 15:46:49 +0100
Message-ID: 
 <CACsaS94qxnzzw_pfD8jo=jBp+D558qxj4NBBQYTK6q9skO0sSQ@mail.gmail.com>
Subject: Re: Unroutable messages in Java Qpid Broker 6.0.0
From: Rob Godfrey <rob.j.godfrey@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=089e0122e720200ae4052fd208ee

--089e0122e720200ae4052fd208ee
Content-Type: text/plain; charset=UTF-8

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

--089e0122e720200ae4052fd208ee--