0

Mule 3.4 は、デフォルトの 16 スレッドのみを作成しており、以下のコードで指定された構成を取りませんでした。

  1. MaxActive="100" は作成されず、16 個のスレッドを作成して処理するだけです。
  2. INITIALISE_ALL も機能していません。1 つのアイドル スレッドがあり、データが送信されると、16 を作成してプロセスを実行します。そのため、MaxIdle=2 も機能していません (jvisualvm を使用して監視)

デフォルトの動作をオーバーライドしないのはなぜですか? 何か不足していますか？

私が今直面している最も重大な問題は、28 個の ID を VM に送信すると、それらの一部が処理され、残りについての手がかりがなく、これに関する特定の番号/パターンがないことです。(ローカル ボックスで問題を再現することはできません。これは、QA、UAT ボックスなどのより高い環境で発生しており、前述のように、この問題なしで機能していました)。助けてください。

<flow name="Event0">
    <vm:inbound-endpoint ref="PROCESS.EVENT0" />
    <pooled-component>
        <spring-object bean="abcProcess" />
        <pooling-profile exhaustedAction="WHEN_EXHAUSTED_WAIT" initialisationPolicy="INITIALISE_ALL" maxActive="100" maxIdle="2"    maxWait="20000" />
    </pooled-component>
    <custom-exception-strategy class="org.mule.exception.DefaultMessagingExceptionStrategy">
        <commit-transaction exception-pattern="*" />
        <vm:outbound-endpoint ref="ErrorHandlerInput" />
    </custom-exception-strategy>
</flow>
4

1 に答える 1

0

を使用してDefaultMessagingExceptionStrategyおり、ドキュメントには次のように記載されています。

これは、フローとサービスのデフォルトの例外ハンドラーです。ハンドラーはエラーをログに記録し、この例外戦略に設定されている場合、メッセージと例外を例外エンドポイントに転送します。要素を介してエンドポイントが構成されている場合、デッド レター キュー パターンが想定されるため、トランザクションはコミットされます。そうしないと、トランザクションがロールバックし、ソース メッセージが再配信される可能性があります (トランスポートによって異なります)。

したがって、おそらくログと、構成したと思われる例外エンドポイントを確認する必要があります。

于 2014-04-13T18:15:21.520 に答える