Re: Unroutable messages in Java Qpid Broker 6.0.0
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 wrote: > Hello Rob, > Do you have any updates on this issue? > Regards,Adel Boutros.www.murex.com > > > From: adelbout...@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.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 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 > 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
RE: Unroutable messages in Java Qpid Broker 6.0.0
Hello Rob, Do you have any updates on this issue? Regards,Adel Boutros.www.murex.com > From: adelbout...@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.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 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 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 > > > >
RE: Unroutable messages in Java Qpid Broker 6.0.0
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 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 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 wrote: > > > > > > > > > > > Hello, > > > > >
Re: Unroutable messages in Java Qpid Broker 6.0.0
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 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 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 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 > > > > > e
RE: Unroutable messages in Java Qpid Broker 6.0.0
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 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 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 > > > >
Re: Unroutable messages in Java Qpid Broker 6.0.0
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 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 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) > > >
RE: Unroutable messages in Java Qpid Broker 6.0.0
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 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
Re: Unroutable messages in Java Qpid Broker 6.0.0
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 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
