djb
djb

Reputation: 1674

Camel delay overrides any redeliveryPolicy

Here is a simplified ftp polling mechanism.

<camelContext id="Fetcher" xmlns="http://camel.apache.org/schema/blueprint">

    <redeliveryPolicyProfile id="redeliveryPolicy"
        redeliveryDelay="10000" 
        maximumRedeliveries="-1" />

    <camel:route id="fetchFiles">  
        <camel:from uri="ftp://10.20.30.40/From?username=user&password=RAW({{password}})&delay=3000" />
        <camel:to uri="log:input?showAll=true&level=INFO"/>
        <camel:to uri="file://incomingDirectory" />

        <onException redeliveryPolicyRef="msRedeliveryPolicy">
            <exception>java.lang.Exception</exception>
            <redeliveryPolicy logRetryAttempted="true" retryAttemptedLogLevel="WARN"/>
        </onException>      
    </camel:route>

</camelContext>

What do you think happens on failure? (Delay is 3 seconds, and redeliveryDelay is 10 seconds.)

Answer: It polls every 3 seconds, forever.

So let's look at the docs. Maybe I need this

"repeatCount (scheduler)"

Specifies a maximum limit of number of fires. So if you set it to 1, the scheduler will only fire once. If you set it to 5, it will only fire five times. A value of zero or negative means fire forever.

Default: 0

Nope, it's not even a valid parameter. So why's it in the docs?

 Unknown parameters=[{repeatCount=5}]

Ok, so I suppose every 3 seconds it polls. So how do I tell camel to stop that? Let's try set 'handled' to true?

<onException redeliveryPolicyRef="msRedeliveryPolicy">
    <exception>java.lang.Exception</exception>
    <redeliveryPolicy logRetryAttempted="true" retryAttemptedLogLevel="WARN"/>
    <handled><constant>true</constant></handled>
</onException>  

No luck. Still 3 seconds. It's clearly not even getting to the redelivery part.

What's the secret?

Upvotes: 0

Views: 488

Answers (1)

hk6279
hk6279

Reputation: 1879

The fact is errors happen in from endpoint are not handled by user defined route (i.e. fetchFiles in above setup). So, onException and redeliveryPolicy are not involved as they only affect stuff belongs to user defined route.

To control the behavior of consumer defined in from endpoint, the obvious way is to use the option exist in that component. As suggested by @Screwtape, use backoffErrorThreshold and backoffMultplier for your case.

Why parameter repeatCount exist in doc, but is invalid to use? It probably does not exist in your camel version and Camel document writer forget to mark the first exist version in the doc.

Upvotes: 1

Related Questions