On Wed, Aug 10, 2011 at 4:17 PM, David Tombs <[email protected]> wrote: > On Wed, Aug 10, 2011 at 7:42 AM, Claus Ibsen <[email protected]> wrote: >> On Tue, Aug 9, 2011 at 5:05 PM, David Tombs <[email protected]> wrote: >>> Hi all, >>> >>> I am using the resequencer EIP in a situation where it would be better >>> never to pass on a message at all than to process it out-of-order. The >>> EIP, however, will deliver out-of-order messages if the timeout occurs >>> before receiving an expected message. For example, we receive: >>> >>> 1, 2, 3, 4, 5, 7, 8, (wait 10s), 6. >>> >>> In this case, the rest of the route will receive messages in the above >>> order with 6 last. >>> >>> Any ideas on how to avoid this? My only thought right now is to put a >>> filter after the resequencer to reject any messages that would precede >>> the last message passed on. >>> >> >> You can use a very high timeout value. > > Thanks for the response, but a very high timeout value doesn't really > solve my problem because I really need "never". It is also possible to > have dropped messages, so such a high timeout could harm performance > in that case. > > What do you think about my filter idea?
Yeah that is a good idea. In fact we may add support directly on the resequencer as well to filter out out of sequence numbers in case it have send out a batch. Fell free to create a JIRA ticket. And if possible working on a patch with unit test. In the future we plan to refactor the code for the resequencer, as we need to add more easily pluggable API for stores (persistence). And have it support recovery and redelivery etc. Just as the aggregator EIP now supports. > > Thanks again, > David > > -- > Wise men _still_ seek Him. > -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
