Since we're on a major migration process of this website, some component documents here are out of sync right now. In the meantime you may want to look at the early version of the new website
https://camel.apache.org/staging/
We would very much like to receive any feedback on the new site, please join the discussion on the Camel user mailing list.
ResequencerThe Resequencer from the EIP patterns allows you to reorganise messages based on some comparator. By default in Camel we use an Expression to create the comparator; so that you can compare by a message header or the body or a piece of a message etc. The Camel supports two resequencing algorithms:
By default the Resequencer does not support duplicate messages and will only keep the last message, in case a message arrives with the same message expression. However in the batch mode you can enable it to allow duplicates. Batch ResequencingThe following example shows how to use the batch-processing resequencer so that messages are sorted in order of the body() expression. That is messages are collected into a batch (either by a maximum number of messages per batch or using a timeout) then they are sorted in order and then sent out to their output. Using the Fluent Builders The batch-processing resequencer can be further configured via the This sets the batch size to 300 and the batch timeout to 4000 ms (by default, the batch size is 100 and the timeout is 1000 ms). Alternatively, you can provide a configuration object. So the above example will reorder messages from endpoint direct:a in order of their bodies, to the endpoint mock:result. for example to reorder messages using a custom sequence number in the header You can of course use many different Expression languages such as XPath, XQuery, SQL or various Scripting Languages. Using the Spring XML Extensions Allow DuplicatesAvailable as of Camel 2.4 In the ReverseAvailable as of Camel 2.4 In the In Java DSL there is a Resequence JMS messages based on JMSPriorityAvailable as of Camel 2.4 It's now much easier to use the Resequencer to resequence messages from JMS queues based on Ignore invalid exchangesAvailable as of Camel 2.9 The Resequencer EIP will from Camel 2.9 onwards throw a Reject Old ExchangesAvailable as of Camel 2.11 This option can be used to prevent out of order messages from being sent regardless of the event that delivered messages downstream (capacity, timeout, etc). If enabled using This option is available for the stream resequencer only. Stream ResequencingThe next example shows how to use the stream-processing resequencer. Messages are re-ordered based on their sequence numbers given by a Using the Fluent Builders This sets the resequencer's capacity to 5000 and the timeout to 4000 ms (by default, the capacity is 1000 and the timeout is 1000 ms). Alternatively, you can provide a configuration object. The stream-processing resequencer algorithm is based on the detection of gaps in a message stream rather than on a fixed batch size. Gap detection in combination with timeouts removes the constraint of having to know the number of messages of a sequence (i.e. the batch size) in advance. Messages must contain a unique sequence number for which a predecessor and a successor is known. For example a message with the sequence number 3 has a predecessor message with the sequence number 2 and a successor message with the sequence number 4. The message sequence 2,3,5 has a gap because the successor of 3 is missing. The resequencer therefore has to retain message 5 until message 4 arrives (or a timeout occurs). If the maximum time difference between messages (with successor/predecessor relationship with respect to the sequence number) in a message stream is known, then the resequencer's timeout parameter should be set to this value. In this case it is guaranteed that all messages of a stream are delivered in correct order to the next processor. The lower the timeout value is compared to the out-of-sequence time difference the higher is the probability for out-of-sequence messages delivered by this resequencer. Large timeout values should be supported by sufficiently high capacity values. The capacity parameter is used to prevent the resequencer from running out of memory. By default, the stream resequencer expects or via a Using the Spring XML Extensions Further ExamplesFor further examples of this pattern in use you could look at the batch-processing resequencer junit test case and the stream-processing resequencer junit test case |