タスクスケジューラの構成

Spring Integration では、ApplicationContext はメッセージバスの中心的なロールを果たします。いくつかの構成オプションのみを考慮する必要があります。最初に、主要な TaskScheduler インスタンスを制御したい場合があります。そのためには、taskScheduler という名前の単一の Bean を提供します。これは、次のように定数としても定義されます。

IntegrationContextUtils.TASK_SCHEDULER_BEAN_NAME

デフォルトでは、Spring Integration は、Spring Framework リファレンスマニュアルのタスクの実行とスケジューリングセクションに従って、ThreadPoolTaskScheduler のインスタンスに依存します。デフォルトの TaskScheduler は、10 個のスレッドのプールで自動的に起動しますが、グローバルプロパティを参照してください。代わりに独自の TaskScheduler インスタンスを提供する場合は、'autoStartup' プロパティを false に設定するか、独自のプールサイズ値を指定できます。

ポーリングコンシューマーが構成で明示的なタスクエグゼキューター参照を提供すると、ハンドラーメソッドの呼び出しはメインスケジューラープールではなく、エグゼキューターのスレッドプール内で発生します。ただし、エンドポイントのポーラーにタスクエグゼキューターが提供されていない場合、メインスケジューラーのスレッドの 1 つによって呼び出されます。

ポーラースレッドで長時間実行されるタスクを実行しないでください。代わりにタスクエグゼキューターを使用してください。ポーリングエンドポイントが多数ある場合、プールサイズを大きくしない限り、スレッド不足が発生する可能性があります。また、ポーリングコンシューマーのデフォルト receiveTimeout は 1 秒です。この時間はポーラースレッドがブロックするため、このようなエンドポイントが多数存在する場合は、タスクエグゼキューターを使用して、飢 again を回避することをお勧めします。あるいは、receiveTimeout を減らすことができます。

入力チャネルがキューベース（つまり、ポーリング可能）チャネルの 1 つである場合、エンドポイントはポーリングコンシューマーです。イベント駆動型コンシューマーとは、キューではなくディスパッチャーを備えた入力チャネルを持つコンシューマーです（つまり、サブスクライブ可能です）。そのようなエンドポイントには、ハンドラーが直接呼び出されるため、ポーラー構成がありません。

JEE コンテナーで実行する場合、デフォルトの taskScheduler の代わりに、ここで説明するように Spring の TimerManagerTaskScheduler を使用する必要がある場合があります。これを行うには、次の例に示すように、環境に適した JNDI 名で Bean を定義します。

<bean id="taskScheduler" class="org.springframework.scheduling.concurrent.DefaultManagedTaskScheduler">
    <property name="jndiName" value="tm/MyTimerManager" />
    <property name="resourceRef" value="true" />
</bean>

カスタム TaskScheduler がアプリケーションコンテキストで構成されている場合（上記の DefaultManagedTaskScheduler のように）、フレームワークによって提供される ErrorMessage`s sent to the error channel, as is done with the default `TaskScheduler Bean として例外を処理できるように、MessagePublishingErrorHandler （integrationMessagePublishingErrorHandler Bean）を提供することをお勧めします。

詳細については、エラー処理も参照してください。