Configuring the Task Scheduler

在 Spring Integration 中，ApplicationContext 扮演消息总线的中心角色，您只需要考虑几个配置选项。首先，您可能想要控制中央 TaskScheduler 实例。您可以通过提供名为 taskScheduler 的单个 bean 来实现此目的。它还被定义为一个常量，如下所示：

In Spring Integration, the ApplicationContext plays the central role of a message bus, and you need to consider only a couple of configuration options. First, you may want to control the central TaskScheduler instance. You can do so by providing a single bean named taskScheduler. This is also defined as a constant, as follows:

IntegrationContextUtils.TASK_SCHEDULER_BEAN_NAME

默认情况下，Spring Integration 依赖 `ThreadPoolTaskScheduler`的实例，如 Spring 框架参考手册的 Task Execution and Scheduling部分中所述。该默认 `TaskScheduler`会自动启动，并带有十个线程的池，但请参阅 Global Properties。如果您自己提供 `TaskScheduler`实例，则可以将“autoStartup”属性设置为 `false`或提供您自己的池大小值。

By default, Spring Integration relies on an instance of ThreadPoolTaskScheduler, as described in the Task Execution and Scheduling section of the Spring Framework reference manual. That default TaskScheduler starts up automatically with a pool of ten threads, but see Global Properties. If you provide your own TaskScheduler instance instead, you can set the 'autoStartup' property to false or provide your own pool size value.

当轮询使用者在其配置中提供显式任务执行程序引用时，处理程序方法的调用发生在该执行程序的线程池中，而不是主调度程序池中。但是，当未为端点的轮询器提供任务执行程序时，它将由一个主调度程序线程调用。

When polling consumers provide an explicit task executor reference in their configuration, the invocation of the handler methods happens within that executor’s thread pool and not the main scheduler pool. However, when no task executor is provided for an endpoint’s poller, it is invoked by one of the main scheduler’s threads.

不要在轮询线程上运行长时间运行的任务。请改用任务执行器。如果您有许多轮询端点，可能会导致线程饥饿，除非您增加池的大小。此外，轮询使用者的默认 receiveTimeout 为一秒。由于轮询线程会阻塞此时间，因此当存在许多这样的端点时，我们建议您使用任务执行器，再次避免饥饿。或者，您可以减小 receiveTimeout。

Do not run long-running tasks on poller threads. Use a task executor instead. If you have a lot of polling endpoints, you can cause thread starvation, unless you increase the pool size. Also, polling consumers have a default receiveTimeout of one second. Since the poller thread blocks for this time, we recommend that you use a task executor when many such endpoints exist, again to avoid starvation. Alternatively, you can reduce the receiveTimeout.

如果其输入通道是基于队列（即，可轮询）的通道之一，则该端点为轮询使用者。事件驱动的使用者是具有派发器而不是队列作为输入通道的使用者（换句话说，它们是可订阅的）。此类端点没有轮询器配置，因为其处理程序被直接调用。

An endpoint is a Polling Consumer if its input channel is one of the queue-based (that is, pollable) channels. Event-driven consumers are those having input channels that have dispatchers instead of queues (in other words, they are subscribable). Such endpoints have no poller configuration, since their handlers are invoked directly.

在 JEE 容器中运行时，您可能需要使用 Spring 的 TimerManagerTaskScheduler，如 here中所述，而不是默认的 taskScheduler。为此，请使用以下示例所示，定义带有与环境相匹配的适当 JNDI 名称的 bean：

When running in a JEE container, you may need to use Spring’s TimerManagerTaskScheduler, as described here, instead of the default taskScheduler. To do so, define a bean with the appropriate JNDI name for your environment, as the following example shows:

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

在应用程序上下文中配置自定义 TaskScheduler 时（比如上面提到的 DefaultManagedTaskScheduler），建议向它提供一个 MessagePublishingErrorHandler (integrationMessagePublishingErrorHandler bean）以能够处理异常，就像框架提供的 ErrorMessage`s sent to the error channel, as is done with the default `TaskScheduler bean 一样。

When a custom TaskScheduler is configured in the application context (like the above mentioned DefaultManagedTaskScheduler), it is recommended to supply it with a MessagePublishingErrorHandler (integrationMessagePublishingErrorHandler bean) to be able to handle exceptions as ErrorMessage`s sent to the error channel, as is done with the default `TaskScheduler bean provided by the framework.

有关更多信息，另请参阅 Error Handling。

See also Error Handling for more information.