Настройка политики повторных попыток - PullRequest
Новая
       0

Настройка политики повторных попыток

1 голос
/ 08 ноября 2011

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

<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>

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

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

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

Как мул относится к этим вещам?

1 Ответ

0 голосов
/ 08 ноября 2011

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

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

...