Olivier, Yeap, the Web Management Console needs to be changed for that. I will look into it.
Kind Regards, Alex On 31 July 2018 at 15:10, VERMEULEN Olivier <[email protected]> wrote: > Thanks Alex, I just tested it and it works like a charm. > One thing though, this attribute is not accessible through the graphical > interface... > > Olivier > > -----Original Message----- > From: Oleksandr Rudyy <[email protected]> > Sent: mardi 31 juillet 2018 15:22 > To: [email protected] > Subject: Re: [Broker-J] Reject overflow policy > > Hi Olivier, > > By default, Qpid exchanges drop unroutable/rejected messages. > You can set exchange "unroutableMessageBehaviour" to "REJECT" in order to > reject the unroutable/rejected messages: > > "unroutableMessageBehaviour" : "REJECT" > > Kind Regards, > Alex > > > On 31 July 2018 at 12:44, VERMEULEN Olivier <[email protected]> > wrote: >> Hello, >> >> Actually I managed to reproduce my first use case where the client does not >> receive the exception. >> It happens when sending through a topic to a queue with REJECT policy >> enabled. >> The message is indeed rejected when the queue is full but the client does >> not receive anything... >> >> Olivier >> >> -----Original Message----- >> From: VERMEULEN Olivier >> Sent: mercredi 4 juillet 2018 15:36 >> To: [email protected] >> Subject: RE: [Broker-J] Reject overflow policy >> >> Hello, >> >> I get the same error as you now... >> There must have been something wrong with my use case the first time. >> Thanks for the help and sorry for the trouble >> >> Olivier >> >> -----Original Message----- >> From: Oleksandr Rudyy <[email protected]> >> Sent: mercredi 4 juillet 2018 14:35 >> To: [email protected] >> Subject: Re: [Broker-J] Reject overflow policy >> >> Oliver, >> >> I quickly tested publishing into a queue with reject policy configured using >> jms client of version 0.11.1. >> It worked for me: ResourceAllocationException was thrown on reaching a limit >> for the maximum number of messages. >> >> Could you please enable trace logging on client (for example, using env >> variable PN_TRACE_FRM=true) and debug logging on Broker side and repeat your >> test in order to understand what is happening? >> What is reported in both logs on reaching the limit? >> >> Kind Regards, >> Alex >> >> >> On 4 July 2018 at 11:10, VERMEULEN Olivier <[email protected]> >> wrote: >>> Hello Rudyy >>> >>> Thanks for the detailed answer. >>> I'm using a JMS client (qpid-jms-client 0.11.1) with a non-transacted >>> session and no specific flags. >>> For this use case I'm publishing directly in a standard queue. >>> >>> Olivier >>> >>> -----Original Message----- >>> From: Oleksandr Rudyy <[email protected]> >>> Sent: mercredi 4 juillet 2018 11:08 >>> To: [email protected] >>> Subject: Re: [Broker-J] Reject overflow policy >>> >>> Hi Olivier, >>> >>> The broker behaviour for reject policy depends on AMQP protocol in use. >>> >>> With AMQP 1-0 an error "Maximum depth exceeded on 'reject-queue' : >>> current=[count: 11, size: 5458], max=[count: 10, size: -1] [condition = >>> amqp:resource-limit-exceeded]" is reported back as part of broker >>> disposition for both transactional and non-transaction cases. >>> The JMS client throws javax.jms.ResourceAllocationException on receiving >>> the disposition with error. >>> >>> With AMQP 0-10 an execution exception >>> (ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED, description=No route >>> for message with destination 'amq.direct' and routing key 'reject-queue' : >>> Maximum depth exceeded on 'reject-queue' : >>> current=[count: 11, size: 9389], max=[count: 10, size: -1]) [error >>> code: 506(resource error)]) is sent by Broker to the client (followed by >>> session close) when following conditions are met: >>> * delivery property flag "discard-unroutable" is not set and transfer >>> accept-mode is not explicit >>> * broker amqp port attribute "closeWhenNoRoute" is set to true >>> (default)] Otherwise, >>> * when delivery property flag "discard-unroutable" is not set and transfer >>> accept-mode is explicit, a message reject is sent back. >>> * when delivery property flag "discard-unroutable" is set or amqp port >>> attribute "closeWhenNoRoute" is false, the message is discarded with >>> generating a broker log 'EXH-1003 : Discarded Message : Name: "{0}" >>> Routing Key: "{1}"' >>> >>> >>> With AMQP 0-8..0-91 a connection is closed with error "Maximum depth >>> exceeded on 'reject-queue' : current=[count: 11, size: 10330], >>> max=[count: 10, size: -1] [error code: 506(resource error)]" when following >>> conditions are met: >>> * transactions are used >>> * message is mandatory >>> * client supports broker feature "closeWhenNoRoute" >>> * synchronous publishing is not used >>> Otherwise, >>> * when synchronous publishing is used, the basick.nack is sent back. >>> * when message is mandatory or immediate, the broker sends back >>> basic.return >>> * when message is not mandatory and not immediate, the message is >>> discarded with generating a broker log 'EXH-1003 : Discarded Message : >>> Name: "{0}" Routing Key: "{1}"' >>> >>> Could you please clarify what protocol and client you are using and what >>> properties/flags are set on message transfer/publishing on client side? Do >>> you publish using transacted session? What exchange is used? >>> >>> Kind Regards, >>> Alex >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] For >>> additional commands, e-mail: [email protected] >>> >>> ******************************* >>> >>> This e-mail contains information for the intended recipient only. It may >>> contain proprietary material or confidential information. If you are not >>> the intended recipient you are not authorised to distribute, copy or use >>> this e-mail or any attachment to it. Murex cannot guarantee that it is >>> virus free and accepts no responsibility for any loss or damage arising >>> from its use. If you have received this e-mail in error please notify >>> immediately the sender and delete the original email received, any >>> attachments and all copies from your system. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] For >> additional commands, e-mail: [email protected] >> >> ******************************* >> >> This e-mail contains information for the intended recipient only. It may >> contain proprietary material or confidential information. If you are not the >> intended recipient you are not authorised to distribute, copy or use this >> e-mail or any attachment to it. Murex cannot guarantee that it is virus free >> and accepts no responsibility for any loss or damage arising from its use. >> If you have received this e-mail in error please notify immediately the >> sender and delete the original email received, any attachments and all >> copies from your system. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] > > ******************************* > > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not the > intended recipient you are not authorised to distribute, copy or use this > e-mail or any attachment to it. Murex cannot guarantee that it is virus free > and accepts no responsibility for any loss or damage arising from its use. If > you have received this e-mail in error please notify immediately the sender > and delete the original email received, any attachments and all copies from > your system. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
