Available as of Camel 2.10
Current features it provides:
LevelDBAggregationRepository is an
AggregationRepository which on the fly persists the aggregated messages. This ensures that you will not loose messages, as the default aggregator will use an in memory only
It has the following options:
A mandatory repository name. Allows you to use a shared
Filename for the persistent storage. If no file exists on startup a new file is created.
Use an existing configured
Camel 2.12: Whether or not the LevelDBFile should sync on write or not. Default is false. By sync on write ensures that its always waiting for all writes to be spooled to disk and thus will not loose updates. See LevelDB docs for more details about async vs sync writes.
Whether the get operation should return the old existing Exchange if any existed. By default this option is
Whether or not recovery is enabled. This option is by default
If recovery is enabled then a background task is run every x'th time to scan for failed exchanges to recover and resubmit. By default this interval is 5000 millis.
Allows you to limit the maximum number of redelivery attempts for a recovered exchange. If enabled then the Exchange will be moved to the dead letter channel if all redelivery attempts failed. By default this option is disabled. If this option is used then the
An endpoint uri for a Dead Letter Channel where exhausted recovered Exchanges will be moved. If this option is used then the
repositoryName option must be provided. Then either the
persistentFileName or the
levelDBFile must be provided.
What is preserved when persisting
LevelDBAggregationRepository will only preserve any
Serializable compatible message body data types. Message headers must be primitive / string / numbers / etc. If a data type is not such a type its dropped and a
WARN is logged. And it only persists the
Message body and the
Message headers. The
Exchange properties are not persisted.
LevelDBAggregationRepository will by default recover any failed Exchange. It does this by having a background tasks that scans for failed Exchanges in the persistent store. You can use the
checkInterval option to set how often this task runs. The recovery works as transactional which ensures that Camel will try to recover and redeliver the failed Exchange. Any Exchange which was found to be recovered will be restored from the persistent store and resubmitted and send out again.
The following headers is set when an Exchange is being recovered/redelivered:
Is set to true to indicate the Exchange is being redelivered.
The redelivery attempt, starting from 1.
Only when an Exchange has been successfully processed it will be marked as complete which happens when the
confirm method is invoked on the
AggregationRepository. This means if the same Exchange fails again it will be kept retried until it success.
You can use option
maximumRedeliveries to limit the maximum number of redelivery attempts for a given recovered Exchange. You must also set the
deadLetterUri option so Camel knows where to send the Exchange when the
maximumRedeliveries was hit.
You can see some examples in the unit tests of camel-leveldb, for example this test.
Using LevelDBAggregationRepository in Java DSL
In this example we want to persist aggregated messages in the
Using LevelDBAggregationRepository in Spring XML
The same example but using Spring XML instead:
To use LevelDB in your camel routes you need to add the a dependency on camel-leveldb.
If you use maven you could just add the following to your pom.xml, substituting the version number for the latest & greatest release (see the download page for the latest versions).