activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <>
Subject RE: Implementation of message redelivery delay
Date Tue, 15 Nov 2011 16:02:20 GMT
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. ;-)



> >> 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.
View raw message