Resequencer
Introduction Related to the Aggregator, albeit different from a functional standpoint, is the Resequencer.
Functionality The Resequencer works in a similar way to the Aggregator, in the sense that it uses the CORRELATION_ID to store messages in groups, the difference being that the Resequencer does not process the messages in any way. It simply releases them in the order of their SEQUENCE_NUMBER header values. With respect to that, the user might opt to release all messages at once (after the whole sequence, according to the SEQUENCE_SIZE, has been released), or as soon as a valid sequence is available.
Configuring a Resequencer Configuring a resequencer requires only including the appropriate element in XML. A sample resequencer configuration is shown below. ]]> ]]> The id of the resequencer is optional. The input channel of the resequencer. Required. The channel to which the resequencer will send the reordered messages. Optional. The channel to which the resequencer will send the messages that timed out (if send-partial-result-on-timeout is false). Optional. Whether to send out ordered sequences as soon as they are available, or only after the whole message group arrives. Optional (false by default). A reference to a MessageGroupStore that can be used to store groups of messages under their correlation key until they are complete. Optional with default a volatile in-memory store. Whether, upon the expiration of the group, the ordered group should be sent out (even if some of the messages are missing). Optional (false by default). See . The timeout interval to wait when sending a reply Message to the output-channel or discard-channel. By default the send will block for one second. It is applied only if the output channel has some 'sending' limitations, e.g. QueueChannel with a fixed 'capacity'. In this case a MessageDeliveryException is thrown. The send-timeout is ignored in case of AbstractSubscribableChannel implementations. In case of group-timeout(-expression) the MessageDeliveryException from the scheduled expire task leads this task to be rescheduled. Optional. A reference to a bean that implements the message correlation (grouping) algorithm. The bean can be an implementation of the CorrelationStrategy interface or a POJO. In the latter case the correlation-strategy-method attribute must be defined as well. Optional (by default, the aggregator will use the IntegrationMessageHeaderAccessor.CORRELATION_ID header) . A method defined on the bean referenced by correlation-strategy, that implements the correlation decision algorithm. Optional, with restrictions (requires correlation-strategy to be present). A SpEL expression representing the correlation strategy. Example: "headers['foo']". Only one of correlation-strategy or correlation-strategy-expression is allowed. A reference to a bean that implements the release strategy. The bean can be an implementation of the ReleaseStrategy interface or a POJO. In the latter case the release-strategy-method attribute must be defined as well. Optional (by default, the aggregator will use the IntegrationMessageHeaderAccessor.SEQUENCE_SIZE header attribute). A method defined on the bean referenced by release-strategy, that implements the completion decision algorithm. Optional, with restrictions (requires release-strategy to be present). A SpEL expression representing the release strategy; the root object for the expression is a Collection of Messages. Example: "size() == 5". Only one of release-strategy or release-strategy-expression is allowed. Only applies if a MessageGroupStoreReaper is configured for the <resequcencer>'s MessageStore. By default, when a MessageGroupStoreReaper is configured to expire partial groups, empty groups are also removed. Empty groups exist after a group is released normally. This is to enable the detection and discarding of late-arriving messages. If you wish to expire empty groups on a longer schedule than expiring partial groups, set this property. Empty groups will then not be removed from the MessageStore until they have not been modified for at least this number of milliseconds. Note that the actual time to expire an empty group will also be affected by the reaper's timeout property and it could be as much as this value plus the timeout. See . See . See . See . When a group is completed due to a timeout (or by a MessageGroupStoreReaper), the empty group's metadata is retained by default. Late arriving messages will be immediately discarded. Set this to true to remove the group completely; then, late arriving messages will start a new group and won't be discarded until the group again times out. The new group will never be released normally because of the "hole" in the sequence range that caused the timeout. Empty groups can be expired (completely removed) later using a MessageGroupStoreReaper together with the empty-group-min-timeout attribute. Default: 'false'. Since there is no custom behavior to be implemented in Java classes for resequencers, there is no annotation support for it.