Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of gary.tully@gmail.com designates
 209.85.212.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <D9E05F6398B5D94DA1A22A87AD22125DDECCD9C3B4@BERWNXMB01.jcorp.ad.jamba.net>
References: 
 <D9E05F6398B5D94DA1A22A87AD22125DDECAADEC99@BERWNXMB01.jcorp.ad.jamba.net>
	<CAGB5yN=DKb2t0hAsKq+n+=DMLW7X5So3b_+CFDhHuFm91SnBqg@mail.gmail.com>
	<D9E05F6398B5D94DA1A22A87AD22125DDECCD9C3A5@BERWNXMB01.jcorp.ad.jamba.net>
	<CAH+vQmOM60PN6-87bn9TMQKWhCYVBy=4e09HPd=aJS6n7JBshg@mail.gmail.com>
	<D9E05F6398B5D94DA1A22A87AD22125DDECCD9C3AB@BERWNXMB01.jcorp.ad.jamba.net>
	<CAH+vQmMbGL9QNqkL=6XvY_p5xDtBkjbAns=wBDFOhQNhNiCGBw@mail.gmail.com>
	<D9E05F6398B5D94DA1A22A87AD22125DDECCD9C3B4@BERWNXMB01.jcorp.ad.jamba.net>
Date: Wed, 16 Nov 2011 10:18:25 +0000
Message-ID: 
 <CAH+vQmOE=WisqyXYLPNNo6H+9kzG1yYZH0qvmydYp4FeUD+Tnw@mail.gmail.com>
Subject: Re: Implementation of message redelivery delay
From: Gary Tully <gary.tully@gmail.com>
To: dev@activemq.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

go ahead and make it better, more intuitive. Passing in the message makes s=
ense.
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> wrot=
e:
> Gary, I raised AMQ-3597 [1].
>
> And of course we are willing to help with the implementation and test cas=
e creation, if we are able to.
>
> As we are still struggling with the "simple" setup of consumer-based rede=
livery, this may take some time though. We would like to get a better under=
standing of the code before we start looking into a very concrete issue.
>
> We have also been slightly confused about the specific handling of the co=
nsumer for the case of the initial delay, until we found out, that the init=
ial delay is only copied to the redeliveryDelay member of the RedeliveryPol=
icy 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 differentiati=
on is probably moved to the user of the class, although this is not really =
intuitive.
>
> Is everything of the RedeliveryPolicy class (including the getNextRedeliv=
eryDelay(long) which does not really represent a conventional getter) consi=
dered 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 th=
e broker internal usages), but a bad smell in terms of API change.
> Contrary adding another operation with a different name and deprecating t=
he existing one would not be of much value either, once all internal usages=
 are changed.
> Thinking about potential future requirements and noticing RedeliveryPolic=
y is no interface, but a concrete class it might also be an option to not p=
ass in just the redelivery counter, but possibly the message. This could al=
low the use of other metadata to influence the way the delivery delay is ca=
lculated.
>
> If you have any preference or some don't, please just shortly comment. Ot=
herwise I will update the issue once we look into the implementation. If so=
meone wants to beat us, we are of course all open. ;-)
>
> Thanks,
> =A0 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? A=
ny
>> 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.
>>
>


--=20
http://fusesource.com
http://blog.garytully.com