Блог

Я пытаюсь настроить политику повторных попыток следующим образом:

 <spring:beans>
        <spring:bean id="threadingPolicyTemplate"
            class="org.mule.retry.async.AsynchronousRetryTemplate">
            <spring:constructor-arg index="0">
                <spring:bean id="foreverRetryPolicyTemplate"
                    class="com.Component.ChatConnectionRetryPolicyTemplate">
                    <spring:property name="sleepTime" value="${connector.retryInterval}" />
                </spring:bean>
            </spring:constructor-arg>
        </spring:bean>
    </spring:beans>

    <jdbc:connector name="jdbcConnector" dataSource-ref="SQLServerjdbcDataSource">
        <spring:property name="retryPolicyTemplate" ref="threadingPolicyTemplate"/>
        <jdbc:query key="PollDB"
            value="select * from ofMessageArchive where ID >  #[payload:]" />
    </jdbc:connector>
  

Я использую указанный соединитель в качестве исходящей конечной точки в моем потоке, но я не вижу, чтобы политика повторных попыток даже вызывалась. (Я установил точки останова и so, и они не были вызваны).

Я использую какой-то threaded SimpleRetryPolicy (ничего особенного).

Еще один вопрос по этому поводу — предположим, соединитель не запускается (выполняется политика повторных попыток) — Что произойдет с потоком, который использует соединитель в качестве конечной точки??

Как mule обрабатывает эти вещи?

• Даже если в JdbcConnector нет параметров для методов init / start / stop / dispose, предполагается, что ваш шаблон политики повторных попыток вызывается сразу после того, как AbstractConnector.connect() регистрирует «Подключение: «. Может быть, вы хотите установить точку останова в этом месте и довести дело до конца?

• Если вы используете многопоточную политику повторных попыток, Mule запустится, даже если произошел сбой соединителя. Входящие конечные точки, зависящие от этого соединителя, не запустятся, следовательно, потоки, использующие их, не будут запущены до тех пор, пока соединитель не сможет запуститься. Исходящие конечные точки будут генерировать исключения: вам решать, как справиться с этой ситуацией, либо с помощью until-successful, либо с помощью стратегии исключения, которая выполняет некоторую пользовательскую обработку проблемы.