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 <[email protected]> wrote: > Hello Rob, > Do you have any updates on this issue? > Regards,Adel Boutros.www.murex.com > > > From: [email protected] > > To: [email protected] > > 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: [email protected] > > > To: [email protected] > > > > > > 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 <[email protected]> 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: [email protected] > > > > > To: [email protected] > > > > > > > > > > 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 <[email protected]> > 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: [email protected] > > > > > > > To: [email protected] > > > > > > > > > > > > > > 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 <[email protected]> > 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 > > > > > > > > > > > > > > > > > > > > > > > >
