[jira] [Updated] (CAMEL-16903) JdbcAggregationRepository not storing properties interfers with AggregateProcessor to restore completiontimeouts

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-16903:
--------------------------------
    Fix Version/s: 3.12.0

> 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)