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]
