As described in Chapter 1, Spring Integration Overview, there are different types of Message Endpoint, such
as the Channel Adapter (inbound or outbound) and the Service Activator.
Spring Integration provides many other components that are also endpoints, such as Routers,
Splitters, and Aggregators. Each endpoint may provide its own specific metadata so that the
MessageBus
can manage its connection to a channel and its polling schedule.
The scheduling metadata is provided as an implementation of the Schedule
interface.
This is an abstraction designed to allow extensibility of schedulers for messaging tasks. Currently, there is a
single implementation named PollingSchedule
and the endpoint may set the
period property. The polling period may differ depending on the type of MessageSource
(e.g. file-system vs. JMS).
While the MessageBus manages the scheduling of the trigger invocation threads, it may be necessary
to have concurrent threads for the endpoint's processing of each receive-and-handle unit of work.
Spring Integration provides an endpoint interceptor called ConcurrencyInterceptor
for this very purpose. The interceptor's configuration is provided by the
ConcurrencyPolicy
metadata object. When the MessageBus
activates an endpoint that has been defined with a ConcurrencyInterceptor, it will use these properties to
configure that endpoint's thread pool. These interceptors are configurable on a per-endpoint basis since
different endpoint handlers may have different performance characteristics and may have different
expectations with regard to the volume of throughput. The following table lists the available properties
of the ConcurrencyPolicy
and their default values:
Table 2.2. Properties of the ConcurrencyPolicy
Property Name | Default Value | Description |
---|---|---|
coreSize | 1 | the core size of the thread pool |
maxSize | 10 | the maximum size the thread pool can reach when under demand |
queueCapacity | 0 | capacity of the queue which defers an increase of the pool size |
keepAliveSeconds | 60 | how long added threads (beyond core size) should remain idle before being removed from the pool |
The details of configuring this and other metadata for each endpoint will be discussed in detail in Section 4.2.2, “Configuring Message Endpoints”.