Page History

...

• BatchSender should use ExecutorsService that ensures if a thread is dead a new thread will be started, eg the task is always running. DONE
• BatchSender is currently only a single thread. We should support concurrency, so you can have multiple output based on per correlation key. DONE
• BatchSender should support transactions, which you can do with .transacted(). But we should have unit test based on that if absent.BatchSender should have simpler logic for enqueing and locking if possible. DONE
• BatchProcessor should support persistent, so aggregated exchanges can be stored in a database using JPA. See how we do this with the Idempotent Consumer and/or Tracer. PLUGGABLE SPI DONE
• If possible: AggregationStrategy should be invoked on the fly so you in the future can use it to determine if we are complete. DONE
• Batch timeout and completion predicate should work together so the completion is triggered by the first one. DONE
• Batch timeout should be per correlation key based, and not a single global timeout. DONE
• If possible: Add POJO based aggregation strategy so you can avoid using the low level Exchange APIs
• Add option what to do in case the correlation key cannot be evaluated, eg to ignore or throw an exception back to caller. DONE
• Add option to ignore to late exchanges if a correlation key has been closed. DONE
• Look all JIRA tickets at Apache what we have for the Aggregator DONE
• Resequencer is also using the BatchProcessor so we should ensure it works as well and maybe it can benefit some of the new features as well.
• BatchSender should support transactions, which you can do with .transacted(). But we should have unit test based on that if absent.
• Add JPA persistent AggregationRepository out of the box
• Consider if possible a JMS persistent AggregationRepository out of the box
• Configuration of completion options should be more dynamic such as timeout and size DONEThe persistence store should be able to be cleanup from time to time so it wont grow forever