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.godf...@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 <adelbout...@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.godf...@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 <adelbout...@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.godf...@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 <adelbout...@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 > > > > > > > > > > > >
