1
votes

I have a mule flow(mock-flow) that currently makes http calls to a couple of microservices. If one of the service calls fails due to a connection exception, i have a rollback exception strategy configured to reprocess the message (sending to kafka which in turn invokes the mock flow)but the retry seems to be happening indefinitely inspite of specifying a maxRedeliveryAttempts attribute. How do I limit the no of retries? Any help would be greatly appreciated

<flow name="mock-flow">
    <logger level="INFO" message="CRD::: Calling Selldown settle Micro Service***"/>
    <logger message="CRD::: Response received : #[message.payload]" level="INFO" />
    <http:request config-ref="tp-ins-selldown-msConfig" path="/settle"
                method="POST" doc:name="HTTP">
                <http:success-status-code-validator
                    values="200,201" />
    </http:request>
    <http:request parseResponse="false" config-ref="tp-ins-limits-msConfig" path="booksdlimit"
            method="POST" doc:name="HTTP">
                <http:success-status-code-validator values="200,201"/>
    </http:request>             
    <choice-exception-strategy doc:name="Choice Exception Strategy">
        <rollback-exception-strategy when="exception.causedBy(java.net.ConnectException)" maxRedeliveryAttempts="2" doc:name="Rollback Exception Strategy">
            <logger message="Will attempt redelivery" level="INFO" doc:name="Logger" />
            <vm:outbound-endpoint exchange-pattern="one-way" path="kafka.inpath" doc:name="VM" />
            <on-redelivery-attempts-exceeded>
            <logger message="redelivery attempt exceeded" level="INFO" doc:name="Logger" />
                <logger message="Retry exhausted" level="INFO" doc:name="Logger" />
            </on-redelivery-attempts-exceeded>
        </rollback-exception-strategy>
    </choice-exception-strategy>

1

1 Answers

0
votes

Since the maxReDeliveryAttempts attrtibute wasn't working(for whatever weird reason), I had to do it on my own(manually) by configuring a mule object store with the message request as the key and retry counter as the value.

    <rollback-exception-strategy when="exception.causedBy(java.net.ConnectException)" doc:name="Rollback Exception Strategy">
                <objectstore:retrieve config-ref="ObjectStore" key="#[uuid]" targetProperty="retryCounter" doc:name="Get value from ObjectStore" />
                <logger level="INFO" doc:name="Logger" message="Retry counter --------------> #[retryCounter]"/>
            <choice doc:name="Choice">
                <when expression="#[retryCounter > 3]">
                    <logger message="Retry exhausted" level="INFO" doc:name="Logger" />
                    <objectstore:remove key="#[uuid]" config-ref="ObjectStore" ignoreNotExists="true" doc:name="Remove the key after retry exhaust" />
                </when>
                <otherwise>
                    <expression-component>
                        Thread.sleep(3000);
                    </expression-component>
                    <logger message="Will attempt redelivery" level="INFO" doc:name="Logger" />
                    <transformer ref="ObjectToString"/>
                    <vm:outbound-endpoint exchange-pattern="one-way" path="kafka.inpath" doc:name="VM" />
                    <objectstore:remove key="#[uuid]" config-ref="ObjectStore" ignoreNotExists="true" doc:name="Remove if exists" />
                    <objectstore:store config-ref="ObjectStore" key="#[uuid]" value-ref="#[retryCounter + 1]" doc:name="Store new value" />
                </otherwise>
            </choice>
        </rollback-exception-strategy>

Seems even if maxRedeliveryAttempts variable had worked, it might not have helped my use case since when multiple requests are triggered, there is no way we would ensure that every request was retriggered only 3 times by simply relying on this attribute(unless mule internally uses a hashcode for every req to determine if it has already been retriggered or not)

Also flow variables and session variables didn't work in my case since the retrigger point was a kafka queue (which wasn't manually invoked by flow-ref). Hence had to use an object store