Andrea Cosentino created CAMEL-24729:
----------------------------------------
Summary: camel-infinispan: a lifespan set without its time unit is
silently ignored
Key: CAMEL-24729
URL: https://issues.apache.org/jira/browse/CAMEL-24729
Project: Camel
Issue Type: Bug
Components: camel-infinispan
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
h3. Summary
Setting {{CamelInfinispanLifespanTime}} without {{CamelInfinispanTimeUnit}} (or
{{CamelInfinispanMaxIdleTime}} without {{CamelInfinispanMaxIdleTimeUnit}})
makes the producer store the entry with *no expiry at all*, silently. The
half-configured expiry is discarded without a warning.
h3. Detail
{{InfinispanProducer}} gates every expiring write on both headers being present:
{code:java}
protected boolean hasLifespan(Message message) {
return !InfinispanUtil.isHeaderEmpty(message,
InfinispanConstants.LIFESPAN_TIME)
&& !InfinispanUtil.isHeaderEmpty(message,
InfinispanConstants.LIFESPAN_TIME_UNIT);
}
protected boolean hasMaxIdleTime(Message message) {
return !InfinispanUtil.isHeaderEmpty(message,
InfinispanConstants.MAX_IDLE_TIME)
&& !InfinispanUtil.isHeaderEmpty(message,
InfinispanConstants.MAX_IDLE_TIME_UNIT);
}
{code}
({{isHeaderEmpty}} is {{ObjectHelper.isEmpty(message.getHeader(header))}}.)
When either half is missing the condition is false and the producer falls
through to the plain {{cache.put(key, value)}} overload. Eight operations are
affected: PUT, PUTASYNC, PUTALL, PUTALLASYNC, PUTIFABSENT, PUTIFABSENTASYNC,
REPLACE, REPLACEASYNC.
There is no fallback: neither the lifespan value nor the time unit has an
endpoint option, so the headers are the only way to express expiry. A route
that sets the time and forgets the unit therefore writes an entry that never
expires - and nothing in the log says so. For a cache used as a TTL store this
is a data-retention problem that only shows up as unbounded growth much later.
h3. Why this is worth changing
This is the same defect class as CAMEL-24623: the component quietly discards
something the route asked for, and the result is indistinguishable from not
having asked.
One difference from CAMEL-24623 is worth noting for whoever fixes it. There the
lenient behaviour was deliberate and asserted by a test since CAMEL-9624
(2016), which is why the fix only added a warning. Here there is no such
contract: {{hasLifespan}}/{{hasMaxIdleTime}} were extracted in CAMEL-9740
(2016) from pre-existing inline {{isInHeaderEmpty(x) &&
isInHeaderEmpty(x_UNIT)}} conditions, and no test covers the half-set case -
every test in {{InfinispanProducerTestSupport}} sets both headers together. So
failing the exchange is defensible here, although a WARN naming the missing
header is the conservative option.
Found by the same source audit of {{components/camel-infinispan}} that produced
CAMEL-24622, CAMEL-24623 and CAMEL-24624; it was reported but left out of the
batch at the time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
