0

In the following route, the maximumRedeliveries clausule from redeliveryPolicy is ignored when we get an exception. We get:

Failed delivery for (MessageId: ID-UW205584-58231-1527668174534-39-248 on ExchangeId: ID-UW205584-58231-1527668174534-39-24). On delivery attempt: 0

Failed delivery for (MessageId: ID-UW205584-58231-1527668174534-39-248 on ExchangeId: ID-UW205584-58231-1527668174534-39-24). On delivery attempt: 1

And then it remains in a infinity loop repeating the last retry. Any idea? Thank you very much community!

Our route looks like follows:

<?xml version="1.0" encoding="ASCII"?>
<routes xmlns="http://camel.apache.org/schema/spring">
    <route handleFault="true">
        <from uri="switchyard://ProcessTaskEx"/>
        <log message="ProcessTaskEx - message received: ${body}" loggingLevel="DEBUG" logName="WebServiceQueues" />
        <to uri="switchyard://RequestCapacity"/>
        <onException>
            <exception>java.lang.Exception</exception>
             <exception>webservicequeues.utilities.WebServiceQueueException</exception>

            <redeliveryPolicy maximumRedeliveries="2" redeliveryDelay="6000" maximumRedeliveryDelay="90000" retriesExhaustedLogLevel="INFO" retryAttemptedLogLevel="INFO"/>
            <handled>
                <constant>true</constant>
            </handled>

            <log message="Failed after Retry.Sending ProcessTask Request to Error Queue" loggingLevel="ERROR" logName="WebServiceQueues" />
            <to uri="switchyard://ErrorProcessTaskExQueue"/>
        </onException>
    </route>
</routes>
user9868874
  • 3
  • 4

1 Answers1

0

Because you get an infinite loop, it sounds like the message header CamelRedeliveryCounter gets overwritten every time and therefore it never reaches the maximumRedeliveries of 2.

Is it possible that the call to the endpoint where the error occurs deletes or resets message headers? Particularly CamelRedeliveryCounter?

burki
  • 6,741
  • 1
  • 15
  • 31
  • I don't think so. We perform no action with the headers and I have set all the transformers to plane transformations, might it be a bug..? We have it after an upgrade from Fuse 6.1 camel 2.1 to Fuse 6.3 Camel 2.17 https://stackoverflow.com/questions/48774952/camelredeliverycounter-not-increasing-after-2-no-matter-whats-the-value-of-max – user9868874 Jun 04 '18 at 09:50
  • To find out if it is an endpoint problem I would replace the endpoint `RequestCapacity` with a simple bean that throws for example a `WebServiceQueueException` and probably replace the `ErrorProcessTaskExQueue` endpoint with a Camel mock. If the redelivery policy then works as expected, the `switchyard` endpoints seem to cause this issue. – burki Jun 04 '18 at 11:31
  • Hi Burki, I tried what you said. Actually I just changed (which returns a SOAP Fault) with a bean that raises the WebServiceQueueException and now it works...So, does it mean that this issue happens if we get a SOAP fault? Rgs – user9868874 Jun 04 '18 at 13:08
  • In this last case I have: On delivery attempt: 1 caught: webservicequeues.utilities.WebServiceQueueException: ProcessTaskEx Service not available, in the previous case I had: On delivery attempt: 1 caught: org.apache.camel.CamelException: – user9868874 Jun 04 '18 at 13:11
  • I did not mock the error queue, so will it be a problem in the exception handling I assume... – user9868874 Jun 04 '18 at 14:05
  • Either Camel redelivery has a problem with faults OR (as I assumed in my answer) the `switchyard://RequestCapacity` bothers somehow the Camel redelivery. To eliminate the first you would have to build a simple mock webservice that throws a fault and call it from your route instead of `switchyard://RequestCapacity`. If redelivery still works, the endpoint causes the problem. If redelivery no more works with the simple webservice, Faults in general seem to be a problem. – burki Jun 04 '18 at 14:35
  • Hi Burki, I did it, I Mock locally a SOAP fault with another text, and it got stuck again in an infinity loop... – user9868874 Jun 04 '18 at 16:45
  • Then it looks like there is a general problem with Faults and redelivery. Have you tried using another Camel minor version or the most current release? – burki Jun 05 '18 at 06:43
  • In such cases I normally build an as small as possible example project that shows the problem and is very easy to run (Camel route test). I then submit it to the [Camel user mailinglist](http://camel.apache.org/mailing-lists.html) to allow the developers to check if it is a bug or another problem. – burki Jun 05 '18 at 06:43
  • Well, we are using Jboss Fuse 6.3 which comes with Camel 2.17, so we have to stick with this version...I will do it, I will recreate the problem, send to the camel mail list and to the jboss support. :) I let you know the outcome. If you have any other ideas... Let me know! I assume this will take some weeks... Rgs – user9868874 Jun 05 '18 at 06:57
  • Yes please. I am curious if this really is a bug/problem. Thanks – burki Jun 05 '18 at 06:59
  • I am in contact with jboss support, meanwhile, after changing some properties internally, I see the following: 09:10:47,302 SEVERE [com.sun.xml.messaging.saaj.soap.ver1_1] (http-127.0.0.1:8080-1) SAAJ0303: Operation getFaultSubcodes not supported by SOAP 1.1 09:10:47,302 INFO [org.apache.camel.processor.DefaultErrorHandler] (Thread-4 (HornetQ-client-global-threads-32602662)) Failed delivery for (MessageId: ID-UW205584 1 caught: org.apache.camel.CamelException: (functional error) . And it repeats again and again, could this be the error causing the infinity loop? – user9868874 Jun 13 '18 at 07:14
  • I have see as well if I remove the redelivery policy and I add the following error line to the route: just before the errorqueue, I see that ${body} is empty... – user9868874 Jun 13 '18 at 10:12