You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by markwolfe <mr...@gmail.com> on 2008/01/03 00:30:24 UTC
RedeliveryPolicy semantics
Gday
Currently having a look at camel to receive, transform, and validate some
files prior to uploading to a existing system.
The idea is a system uploads binary data files to a directory which camel
will consume. These files never expire and need to moved through a pipeline
will transform them, do some validation and then transport them to a retro
system using FTP. So far Camel has done an excellent job of doing this.
However I have run into an interesting dilemma relating to the current
redelivery policy. When we started testing the idea network outages showed
up an interesting issue. As far as I can see it only supports a retry count
being set that defines a count of tries and a couple back off strategies. In
my case however I would like it to try to retransmit until it is delivered.
To test this I have made a small change in the code.
==== START PATCH ====
Index:
camel-core/src/main/java/org/apache/camel/processor/RedeliveryPolicy.java
===================================================================
---
camel-core/src/main/java/org/apache/camel/processor/RedeliveryPolicy.java
(revision 608236)
+++
camel-core/src/main/java/org/apache/camel/processor/RedeliveryPolicy.java
(working copy)
@@ -30,6 +30,9 @@
* @version $Revision$
*/
public class RedeliveryPolicy implements Cloneable, Serializable {
+
+ public static int UNLIMITED_REDELIVERIES = -1;
+
protected static transient Random randomNumberGenerator;
protected int maximumRedeliveries = 6;
protected long initialRedeliveryDelay = 1000L;
@@ -60,7 +63,14 @@
* redelivered
*/
public boolean shouldRedeliver(int redeliveryCounter) {
- return redeliveryCounter < getMaximumRedeliveries();
+
+ // infinite retries is represented by UNLIMITED_REDELIVERIES
+ if (getMaximumRedeliveries() == UNLIMITED_REDELIVERIES){
+ return true;
+ } else {
+ return redeliveryCounter < getMaximumRedeliveries();
+ }
+
}
// Builder methods
==== END PATCH ====
Currently this is quite a simple hack. If people see the value of this
change I would be happy to build a couple of tests and add it to Jira.
Regards
Mark Wolfe
--
View this message in context: http://www.nabble.com/RedeliveryPolicy-semantics-tp14588327s22882p14588327.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RedeliveryPolicy semantics
Posted by pratibhaG <pr...@in2m.com>.
yes,
it worked
--
View this message in context: http://www.nabble.com/RedeliveryPolicy-semantics-tp14588327s22882p17358552.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RedeliveryPolicy semantics
Posted by Gert Vanthienen <ge...@skynet.be>.
Pratibha,
It is not because you're using Camel within ServiceMix, that shouldn't
make a difference. It's because of a type of mine -- it should say
errorHandler(noErrorHandler()) ;)
Gert
pratibhaG wrote:
> Thanks Gert for your reply
>
> Is it really
> from(SERVICE_IN).errorHandler(noErrorHandler).to(BEAN_IN);
>
> I am not able to build it.
> it is not able to recognize noErrorhandler
>
> ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Compilation failure
> /home/pghogale/projects/esb/example-jms-camel-working/tutorial-camel-su/src/main/java/errorhandling/camel/CamelErrorHandler.java:[19,46]
> cannot find symbol
> symbol : variable noErrorHandler
>
> is it because I am using camel within servicemix 3.2.1?
>
> Regards,
> Pratibha
>
Re: RedeliveryPolicy semantics
Posted by pratibhaG <pr...@in2m.com>.
Thanks Gert for your reply
Is it really
from(SERVICE_IN).errorHandler(noErrorHandler).to(BEAN_IN);
I am not able to build it.
it is not able to recognize noErrorhandler
ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
/home/pghogale/projects/esb/example-jms-camel-working/tutorial-camel-su/src/main/java/errorhandling/camel/CamelErrorHandler.java:[19,46]
cannot find symbol
symbol : variable noErrorHandler
is it because I am using camel within servicemix 3.2.1?
Regards,
Pratibha
--
View this message in context: http://www.nabble.com/RedeliveryPolicy-semantics-tp14588327s22882p17355912.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RedeliveryPolicy semantics
Posted by Gert Vanthienen <ge...@skynet.be>.
Pratibha,
Actually, I thought that -1 wasn't supported at all but in fact it is
and it should have worked. What I was trying to say: if you really want
to redeliver an infinite number of times, you can just as well drop the
deadLetterChannel alltogether and write
from(SERVICE_IN).errorHandler(noErrorHandler).to(BEAN_IN)
instead and have ServiceMix take care of retrying by never taking the
message off the SERVICE_IN queue.
Gert
pratibhaG wrote:
> may I ask you to please clarify this point.
> "If you specify noErrorHandler, the JMS endpoint in ServiceMix will just
> receive your bean exception and will not acknowledge the message off the
> queue. This will cause it to retry it forever. For more QoS, you can
> use transactions on the JBI JMS endpoint (or use Spring transactions
> with the Camel JMS endpoints). "
>
> If I put
> from(SERVICE_IN).errorHandler(deadLetterChannel(ERROR_IN).maximumRedeliveries(2)).to(BEAN_IN);
> it works fine. Here I am doing the same thing first specify a dead letter
> queue and afterwards specify redelivery.
>
> Thanks,
> Pratibha
>
> pratibhaG wrote:
>
>> Is this feature also available if I use camel in servicemix? That is if I
>> use
>> servicemix-camel component and have configuration like this:
>> from(SERVICE_IN).errorHandler(deadLetterChannel(ERROR_IN).maximumRedeliveries(-1)).to(BEAN_IN);
>>
>> will my message be redelivered infinitely if it gets error every time it
>> tries to redelive?
>>
>> I tried this in servicemix 3.2.1 but it never tried to redeliver my
>> message.
>> It has the same behaviour as of maximumRedeliveries(0).
>>
>> Any idea?
>>
>> Regards,
>> Pratibha
>>
>>
>
>
>
> -----
> ---
> Gert Vanthienen
> http://www.anova.be
>
>
>
Re: RedeliveryPolicy semantics
Posted by pratibhaG <pr...@in2m.com>.
may I ask you to please clarify this point.
"If you specify noErrorHandler, the JMS endpoint in ServiceMix will just
receive your bean exception and will not acknowledge the message off the
queue. This will cause it to retry it forever. For more QoS, you can
use transactions on the JBI JMS endpoint (or use Spring transactions
with the Camel JMS endpoints). "
If I put
from(SERVICE_IN).errorHandler(deadLetterChannel(ERROR_IN).maximumRedeliveries(2)).to(BEAN_IN);
it works fine. Here I am doing the same thing first specify a dead letter
queue and afterwards specify redelivery.
Thanks,
Pratibha
pratibhaG wrote:
> Is this feature also available if I use camel in servicemix? That is if I
> use
> servicemix-camel component and have configuration like this:
> from(SERVICE_IN).errorHandler(deadLetterChannel(ERROR_IN).maximumRedeliveries(-1)).to(BEAN_IN);
>
> will my message be redelivered infinitely if it gets error every time it
> tries to redelive?
>
> I tried this in servicemix 3.2.1 but it never tried to redeliver my
> message.
> It has the same behaviour as of maximumRedeliveries(0).
>
> Any idea?
>
> Regards,
> Pratibha
>
-----
---
Gert Vanthienen
http://www.anova.be
--
View this message in context: http://www.nabble.com/RedeliveryPolicy-semantics-tp14588327s22882p17339397.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RedeliveryPolicy semantics
Posted by Gert Vanthienen <ge...@skynet.be>.
Prathiba,
If you specify noErrorHandler, the JMS endpoint in ServiceMix will just
receive your bean exception and will not acknowledge the message off the
queue. This will cause it to retry it forever. For more QoS, you can
use transactions on the JBI JMS endpoint (or use Spring transactions
with the Camel JMS endpoints).
It just doesn't make sense to first specify a dead letter queue (i.e. a
queue to send messages to when delivery fails) and afterwards specify
infinite redelivery (i.e. no message will ever be send to the dead
letter queue).
Gert
pratibhaG wrote:
> Is this feature also available if I use camel in servicemix? That is if I use
> servicemix-camel component and have configuration like this:
> from(SERVICE_IN).errorHandler(deadLetterChannel(ERROR_IN).maximumRedeliveries(-1)).to(BEAN_IN);
>
> will my message be redelivered infinitely if it gets error every time it
> tries to redelive?
>
> I tried this in servicemix 3.2.1 but it never tried to redeliver my message.
> It has the same behaviour as of maximumRedeliveries(0).
>
> Any idea?
>
> Regards,
> Pratibha
>
Re: RedeliveryPolicy semantics
Posted by pratibhaG <pr...@in2m.com>.
Is this feature also available if I use camel in servicemix? That is if I use
servicemix-camel component and have configuration like this:
from(SERVICE_IN).errorHandler(deadLetterChannel(ERROR_IN).maximumRedeliveries(-1)).to(BEAN_IN);
will my message be redelivered infinitely if it gets error every time it
tries to redelive?
I tried this in servicemix 3.2.1 but it never tried to redeliver my message.
It has the same behaviour as of maximumRedeliveries(0).
Any idea?
Regards,
Pratibha
--
View this message in context: http://www.nabble.com/RedeliveryPolicy-semantics-tp14588327s22882p17337274.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RedeliveryPolicy semantics
Posted by James Strachan <ja...@gmail.com>.
On 02/01/2008, markwolfe <mr...@gmail.com> wrote:
>
> Gday
>
> Currently having a look at camel to receive, transform, and validate some
> files prior to uploading to a existing system.
>
> The idea is a system uploads binary data files to a directory which camel
> will consume. These files never expire and need to moved through a pipeline
> will transform them, do some validation and then transport them to a retro
> system using FTP. So far Camel has done an excellent job of doing this.
Great, thanks!
> However I have run into an interesting dilemma relating to the current
> redelivery policy. When we started testing the idea network outages showed
> up an interesting issue. As far as I can see it only supports a retry count
> being set that defines a count of tries and a couple back off strategies. In
> my case however I would like it to try to retransmit until it is delivered.
> To test this I have made a small change in the code.
>
> ==== START PATCH ====
> Index:
> camel-core/src/main/java/org/apache/camel/processor/RedeliveryPolicy.java
> ===================================================================
> ---
> camel-core/src/main/java/org/apache/camel/processor/RedeliveryPolicy.java
> (revision 608236)
> +++
> camel-core/src/main/java/org/apache/camel/processor/RedeliveryPolicy.java
> (working copy)
> @@ -30,6 +30,9 @@
> * @version $Revision$
> */
> public class RedeliveryPolicy implements Cloneable, Serializable {
> +
> + public static int UNLIMITED_REDELIVERIES = -1;
> +
> protected static transient Random randomNumberGenerator;
> protected int maximumRedeliveries = 6;
> protected long initialRedeliveryDelay = 1000L;
> @@ -60,7 +63,14 @@
> * redelivered
> */
> public boolean shouldRedeliver(int redeliveryCounter) {
> - return redeliveryCounter < getMaximumRedeliveries();
> +
> + // infinite retries is represented by UNLIMITED_REDELIVERIES
> + if (getMaximumRedeliveries() == UNLIMITED_REDELIVERIES){
> + return true;
> + } else {
> + return redeliveryCounter < getMaximumRedeliveries();
> + }
> +
> }
>
> // Builder methods
> ==== END PATCH ====
>
> Currently this is quite a simple hack. If people see the value of this
> change I would be happy to build a couple of tests and add it to Jira.
Great idea! We definitely should support continuous retries.
I've gone ahead and applied your patch so that a negative value of
maximumRedeliveries means retry forever (then 0 means never retry).
Many thanks!
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com