What I did in this patch was to change the StreamResequencer to start a
polling thread in the same way as the BatchProcessor does. This polling
thread consumes messages from an endpoint, re-orders messages and sends them
to the next processor. There's no queue any more and no separate thread
reading re-ordered messages from that queue.
This change required to remove the Processor interface from the
StreamResequencer. Having a processor interface AND synchronous dispatch of
messages doesn't allow an implementation of a timeout-based resequencing
algorithm (at least, I cannot image how to do that). Therefore, I only see
these two implementation options for the resequencer:
2: Poll mechanism + sync delivery of messages (provided by patch)
:b) would result in having two threads "between" queue a and b with option
1. When using option 2 then there would be only a single thread
involved/working between queue a and b.
Does option 2 (i.e. the provided patch) address the description from
CAMEL-126 or do I miss something?