[
https://issues.apache.org/jira/browse/CAMEL-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16903.
---------------------------------
Resolution: Implemented
For Camel 3.x the timeout and other aggregate related information is already
stored
> JdbcAggregationRepository not storing properties interfers with
> AggregateProcessor to restore completiontimeouts
> ----------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-16903
> URL: https://issues.apache.org/jira/browse/CAMEL-16903
> Project: Camel
> Issue Type: Bug
> Components: came-core, camel-sql
> Affects Versions: 2.16.3
> Reporter: Jonathan Schoreels
> Priority: Minor
> Fix For: 3.12.0
>
>
> Hello,
> I noticed during some testing with our production app that when a camel
> context is restarted, the completation timeouts of the aggregation were lost.
> I had the message :
> "Restored 0 CompletionTimeout conditions in the AggregationTimeoutChecker in
> 1 minute"
>
> After some investigation, it looks the timeouts are restored from the
> properties of the exchange, snippet from AggregateProcessor in branch master :
>
> {code:java}
> protected void restoreTimeoutMapFromAggregationRepository() throws Exception {
> // grab the timeout value for each partly aggregated exchange
> Set<String> keys = aggregationRepository.getKeys();
> if (keys == null || keys.isEmpty()) {
> return;
> }
> StopWatch watch = new StopWatch();
> LOG.trace("Starting restoring CompletionTimeout for {} existing exchanges
> from the aggregation repository...",
> keys.size());
> for (String key : keys) {
> Exchange exchange = aggregationRepository.get(camelContext, key);
> // grab the timeout value
> long timeout = exchange.hasProperties() ?
> exchange.getProperty(Exchange.AGGREGATED_TIMEOUT, 0, long.class) : 0;
> if (timeout > 0) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Restoring CompletionTimeout for exchangeId: {}
> with timeout: {} millis.",
> exchange.getExchangeId(), timeout);
> }
> addExchangeToTimeoutMap(key, exchange, timeout);
> }
> }
> // log duration of this task so end user can see how long it takes to
> pre-check this upon starting
> LOG.info("Restored {} CompletionTimeout conditions in the
> AggregationTimeoutChecker in {}",
> timeoutMap.size(), TimeUtils.printDuration(watch.taken()));
> }
> {code}
> But, as the JdbcAggregationRepository doesn't store properties (by design I
> think), the timeout is lost and the aggregations are restored without ones.
>
> This can be problematic because it causes a leakage of of element that will
> never be completed if the aggregation should have finished by a timeout.
>
> As I see it, there is two possibilities :
> * Modifying the current implementation of AggregateProcessor to load those
> from Headers : Quite impactful for something that only few aggregation
> repository will need
> * Modifying JdbcAggregationRepository to store the exchange properties : may
> leak some internal / extra information in the database.
> What's your thoughts ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
