go ahead and make it better, more intuitive. Passing in the message makes sense. The backward compatibility requirements are on the setters such that existing config will not break. http://activemq.apache.org/redelivery-policy.html
On 15 November 2011 16:02, Hubert, Eric <[email protected]> wrote: > 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. >> > -- http://fusesource.com http://blog.garytully.com
