[
https://issues.apache.org/jira/browse/CAMEL-26753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-26753.
---------------------------------
Resolution: Fixed
Fixed by https://github.com/apache/camel/pull/29534 (merged to main as
55754e0378c8). Thanks!
_Claude Code on behalf of davsclaus_
> KeyValueRepository - a very large TTL wraps around, so the entry expires at
> once or is left out of keys()
> ---------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26753
> URL: https://issues.apache.org/jira/browse/CAMEL-26753
> Project: Camel
> Issue Type: Bug
> Components: camel-caffeine, camel-core, camel-ehcache, camel-jcache,
> camel-jpa, camel-sql
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
> Fix For: 4.24.0
>
>
> {{MemoryKeyValueRepository}}, {{JdbcKeyValueRepository}},
> {{JpaKeyValueRepository}}, {{EhcacheKeyValueRepository}} and
> {{JCacheKeyValueRepository}} compute the expiry time of an entry as
> {{System.currentTimeMillis() + ttl.toMillis()}} without an overflow check.
> For a TTL near {{Long.MAX_VALUE}} milliseconds, such as
> {{Duration.ofMillis(Long.MAX_VALUE)}}, the sum wraps around to a negative
> time:
> * {{MemoryKeyValueRepository}}, {{EhcacheKeyValueRepository}} and
> {{JCacheKeyValueRepository}} treat the entry as expired at once: {{get}}
> returns {{null}} right after {{put}}, and {{putIfAbsent}} overwrites it.
> * {{JdbcKeyValueRepository}} and {{JpaKeyValueRepository}}, where an expiry
> time of 0 means no expiry, return the value from {{get}} and {{contains}},
> but leave the entry out of {{keys()}} and {{size()}}. With the open fix for
> CAMEL-26737, {{replace}} and {{delete(key, expected)}} of
> {{JdbcKeyValueRepository}} also treat it as expired.
> A TTL above {{Long.MAX_VALUE}} milliseconds, such as
> {{ChronoUnit.FOREVER.getDuration()}}, makes {{Duration.toMillis()}} throw an
> {{ArithmeticException}} from {{put}}, {{putIfAbsent}} and {{replace}}.
> {{CaffeineKeyValueRepository}} calls {{ttl.toNanos()}}, which throws an
> {{ArithmeticException}} already for a TTL of about 292 years.
> The state store {{ttl}} option and {{CamelStateStoreTtl}} header, and the
> Cache EIP {{ttl}}, are milliseconds passed as {{Duration.ofMillis(ttl)}}, so
> a user who sets {{Long.MAX_VALUE}} to mean "forever" gets an entry that the
> in-memory repository drops at once.
> Found while fixing CAMEL-26737.
> *Expected*: the {{KeyValueRepository}} Javadoc says that a null, zero or
> negative TTL means no expiry; a positive TTL too large to add to the current
> time should mean that the entry does not expire either, not that it expires
> at once.
> *Suggested fix*: add the TTL with {{Math.addExact}} and use
> {{Long.MAX_VALUE}} when the sum or {{toMillis()}} overflows, in a shared
> helper in {{KeyValueRepositoryHelper}}; in {{CaffeineKeyValueRepository}},
> use {{Long.MAX_VALUE}} nanoseconds when {{toNanos()}} overflows.
> *Affected*: main and 4.23.0 (read, not run on 4.23.0; reproduced with unit
> tests on main).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
