[jira] [Assigned] (AMQ-7042) reduce number of retries when nonBlockingRedelivery is true

["Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Baptiste Onofré reassigned AMQ-7042:
-----------------------------------------

    Assignee: Jean-Baptiste Onofré

> reduce number of retries when nonBlockingRedelivery is true
> -----------------------------------------------------------
>
>                 Key: AMQ-7042
>                 URL: https://issues.apache.org/jira/browse/AMQ-7042
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 5.13.3
>            Reporter: Jon Harper
>            Assignee: Jean-Baptiste Onofré
>            Priority: Major
>
> It might be useful to have a global redelivery delay that is to reduce the number of retries in the case of a sporadic failures that affects all messages. This way you would have the following sequence of events where F means a failure and S success
> {noformat}
> # with separate redelivery times
> FFFFF     FFFFF          FFFFF                    SSSSS
> # with initial redelivery replaced by a global value
> FFFFF     F              F                        SSSSS
> #         ^ first msg    |                        |
> #                        ^ second msg             |
> #                                                 ^ msg 3,4,5,1,2
> {noformat}
> But this means that the redelivery time of a message can not be computed at the time the message is handled (because for example this would reschedule the 5th message in a very long time immediatly). Instead, you either have to implement a mechanism to retry messages before their schedule, or schedule messages like in the first case and then if the last message was rollbacked, don't process them and reschedule according to the global time.
> Note that due to AMQ-5730, the current system (at least until activemq 5.15.5) is broken and has the following behavior:
> {noformat}
> # buggy behavior until at least actiemq 5.15.5
> FFFFF     F           F                    F     |   
> #         ^ first msg |                          |
> #                     ^ second msg               |
> #                                                ^ would work here
> # the next messages have been scheduled in a very long time
> # even though the failure period was really short
> # they are basically lost (limited by maxredeliverydelay)  until
> # the consumer is stopped and another consumer processes them
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)