The client implements session.recover() locally to satisfy the JMS requirements, and applies the outcome if the local redelivery policy is breached either on arrival or during local delivery, which (depending on the outcome applied) can then increment the broker side delivery count. There isnt a way to remotely increment the delivery count by more than 1 so what you noted is currently how things work. As you've found, transaction rollback occurs remotely and so the count is remotely updated each time.
You'd need to decide a tradeoff a configuration between the two options, or perhaps directly send things to a DLQ as the application [fails to] processes a message. I'd note that since the consumer applies the local redelivery policy to a message on arrival before the application sees it, you can perhaps leverage that using a lower client side limit (and possibly configuring a different outcome configuration, like MODIFIED_FAILED or REJECTED) to achieve something close to what you want in terms of overall attempts. E.g. try setting it to 2 (possibly with MODIFIED_FAILED). Robbie On Wed, 21 Aug 2019 at 18:12, Timo Naroska <[email protected]> wrote: > > Hi, > > we're trying to set up Broker J 7.1.4 / Qpid JMS 0.44.0 to retry messages on > failure. > On broker side, the queue is set up with Maximum Delivery Attempts = 5. > On client side, we set a JmsDefaultRedeliveryPolicy with > setMaxRedeliveries(5). The client is not transacted, using > Session.AUTO_ACKNOWLEDGE. > > If we detect an error in message processing, session.recover() is called. > This has the effect that the client is retrying the message locally up to the > set maximum on 5 before eventually releasing the message back to the broker. > (outcome MODIFIED_FAILED_UNDELIVERABLE) > > The problem is that the local retries on client side are apparently not > reported to the broker. So, all these retries are counted as only 1 delivery > on broker side. > The broker therefore transmits the message again with a delivery count of 2. > The client does its retries again... and this repeats until eventually the > broker count has reached the maximum and the message goes to DLQ. > > At that time the message has been processed 20(!) times rather than the > configured 5 retries. > > This seems to a bug in the implementation or a flaw in the protocol? Is there > any way to configure this in a way that only 5 retries total are done? > > > The only working solution we've found is to use transactions and do a > rollback on a bad message. Given that we're not using any transaction > features otherwise it seems to be a high overhead for a seemingly simple > retry logic? > > Thanks > Timo > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
