[
https://issues.apache.org/jira/browse/CAMEL-26237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136366#comment-18136366
]
Guillaume Nodet commented on CAMEL-26237:
-----------------------------------------
This issue has been triaged by an AI coding agent (on behalf of gnodet).
*Bug confirmed:* The root cause is in EhcacheComponent.createCacheManager().
When none of cacheManager, cacheManagerConfiguration, or configurationUri are
set, the method constructs a brand-new CacheManager on every invocation instead
of using managers.computeIfAbsent() like the other three code paths do. Since
EhcacheEndpoint.doStart() calls createCacheManager() per endpoint, two
endpoints like ehcache:x?action=PUT and ehcache:x?action=GET get separate
CacheManagers with isolated storage - a GET never finds what a PUT stored.
Additional issues found:
- Consumer on unconfigured cache gets UserManagedCache which has no event
executor, so listeners are silently ignored
- PUT with null body stores the DefaultMessage object instead of failing cleanly
- Setting valueType without keyType causes NPE
*Status:* A fix is already in progress in PR #28822 (branch
camel-26237-ehcache-four-default-fixes). Transitioning to In Progress.
_Note: This comment was generated by an AI coding agent and requires manual
verification._
> camel-ehcache - without a cacheManager each endpoint URI builds its own
> CacheManager, so a GET does not find what a PUT on another endpoint stored
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26237
> URL: https://issues.apache.org/jira/browse/CAMEL-26237
> Project: Camel
> Issue Type: Bug
> Components: camel-ehcache
> Reporter: Claus Ibsen
> Assignee: Guillaume Nodet
> Priority: Major
> Fix For: 4.24.0
>
>
> Found while adding the catalog body types of ehcache (CAMEL-24961, PR #28397).
> h4. 1. Each endpoint URI has its own CacheManager
> {{EhcacheEndpoint.doStart}} (main 2a465aa4814c, line 70) calls
> {{EhcacheComponent.createCacheManager}}, which without {{cacheManager}},
> {{cacheManagerConfiguration}} or {{configurationUri}} returns a new
> {{CacheManager}} for each call (line 113; the other branches share one
> through {{managers.computeIfAbsent}}). So {{ehcache:x}} and
> {{ehcache:x?action=GET}} are two caches named x: a GET does not find what the
> other endpoint stored. Checked on 4.24.0-SNAPSHOT with the default Ehcache
> setup and with an XML configuration.
> Proposed: share the default CacheManager per component, as the configured
> branches do.
> h4. 2. A consumer on a cache without configuration gets no events
> Without a cache configuration {{EhcacheManager.getCache}} (lines 115-122)
> falls back to a {{UserManagedCache}}, and the listener the consumer registers
> on it ({{EhcacheConsumer}} line 58) never gets an event, without a warning.
> Checked on 4.24.0-SNAPSHOT with the default Ehcache setup and with an XML
> configuration.
> Proposed: create a managed cache with the default configuration instead, or
> fail (or warn) when a consumer gets a UserManagedCache.
> h4. 3. PUT, PUT_IF_ABSENT and REPLACE with no body store the Camel message
> {{EhcacheProducer.getValue}} (line 168) calls
> {{message.getBody(Object.class)}} when there is no {{CamelEhcacheValue}}
> header; with a null body this converts the message itself, so the cache
> stores the {{DefaultMessage}} object instead of failing. Checked on
> 4.24.0-SNAPSHOT with the default Ehcache setup and with an XML configuration.
> Proposed: use {{getBody()}} for Object, and fail when the value is null.
> h4. 4. valueType without keyType: "keyType cannot be null"
> {{EhcacheManager.getCache}} (lines 89-98) falls back to Object only when both
> types are null, so {{valueType}} without {{keyType}} fails with a
> NullPointerException "keyType cannot be null". Checked on 4.24.0-SNAPSHOT
> with the default Ehcache setup and with an XML configuration.
> Proposed: default each type to Object (or the configured type) on its own.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
