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
