设置重试策略

发布于 2024-12-14 09:50:50 字数 1164 浏览 0 评论 0原文

我正在尝试设置一个重试策略,如下所示:

<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 (没什么花哨的)。

关于此事的另一个问题 - 假设连接器未启动(正在尝试重试策略) - 使用连接器作为端点的流会发生什么?

骡子怎么对待这些东西呢?

I am attempting to set up a retry policy like so:

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

I use said connector as an outbound endpoint in my flow but I don't see the retry policy even being called. (I've set breakpoints and so and they were not called).

I am using some sort of threaded SimpleRetryPolicy (nothing fancy).

One more question regarding the matter - suppose the connector doesn't start up (retry policy is being attempted) - What would happen to a flow which uses the connector as an endpoint??

How does mule treat these things?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

榆西 2024-12-21 09:50:50
  • 即使 JdbcConnector 对于 init/start/stop/dispose 方法没有任何操作,您的重试策略模板也应该在 AbstractConnector.connect() 记录“正在连接:”之后立即调用。也许您想在这个地方断点并继续执行?

  • 如果您使用线程重试策略,即使连接器失败,Mule 也会启动。取决于此连接器的入站端点将不会启动,因此在连接器启动之前,使用它们的流不会被触发。出站端点将抛出异常:由您来处理这种情况,无论是使用直到成功还是异常策略来执行一些自定义的问题处理。

  • Even if the JdbcConnector has noops for init/start/stop/dispose methods, your retry policy template is supposed to be called right after AbstractConnector.connect() logs "Connecting: ". Maybe you want to breakpoint at this place and follow through?

  • If you use a threaded retry policy, Mule will start even if a connector is failed. Inbound endpoints depending on this connector will not start hence flows using them won't get triggered until the connector can start. Outbound endpoints will throw exceptions: it's up to you to deal with this situation, either with until-successful or an exception-strategy that perform some custom handling of the issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文