THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- 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 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. 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
- 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 DONE
- Configuration of completion options should be more dynamic such as timeout and size DONE