Gary, I raised AMQ-3597 [1]. And of course we are willing to help with the implementation and test case creation, if we are able to.
As we are still struggling with the "simple" setup of consumer-based redelivery, this may take some time though. We would like to get a better understanding of the code before we start looking into a very concrete issue. We have also been slightly confused about the specific handling of the consumer for the case of the initial delay, until we found out, that the initial delay is only copied to the redeliveryDelay member of the RedeliveryPolicy at class instantiation time, so that if someone sets this property via a Spring bean (setter injection) the getNextRedeliveryDelay(long) if called with 0 will never pickup the configured value. Therefore the differentiation is probably moved to the user of the class, although this is not really intuitive. Is everything of the RedeliveryPolicy class (including the getNextRedeliveryDelay(long) which does not really represent a conventional getter) considered to be part of the public API? Changing from a delay to a redeliveryCount should result in rather small implementation changes (both inside the method implementation as well as the broker internal usages), but a bad smell in terms of API change. Contrary adding another operation with a different name and deprecating the existing one would not be of much value either, once all internal usages are changed. Thinking about potential future requirements and noticing RedeliveryPolicy is no interface, but a concrete class it might also be an option to not pass in just the redelivery counter, but possibly the message. This could allow the use of other metadata to influence the way the delivery delay is calculated. If you have any preference or some don't, please just shortly comment. Otherwise I will update the issue once we look into the implementation. If someone wants to beat us, we are of course all open. ;-) Thanks, Eric [1] https://issues.apache.org/jira/browse/AMQ-3597 > >> I think a change to pass the redeliveryCount to the redelivery policy > >> would make sense, such that the policy can determine the delay > >> independent of the consumer. > > Yes, this is exactly how I was originally anticipating the > implementation would work. What are the plans regarding releasing 5.6? Any > chance that such a change could be included? > > We are actively trying to lock down 5.6[1] but this change is a nice > candidate and would require a major version due to the api change so > now is a good time. > > Can you raise a jira issue for this or even submit a patch with a test > case and we can integrate it. >
