activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: Implementation of message redelivery delay
Date Wed, 16 Nov 2011 10:18:25 GMT
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 <Eric.Hubert@jestadigital.com> 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

Mime
View raw message