[jira] [Created] (CAMEL-19096) EhcacheAggregationRepository drops messages on OversizeMappingException

["Pieter Callewaert (Jira)" <ji...@apache.org>]

Pieter Callewaert created CAMEL-19096:
-----------------------------------------

             Summary: EhcacheAggregationRepository drops messages on OversizeMappingException
                 Key: CAMEL-19096
                 URL: https://issues.apache.org/jira/browse/CAMEL-19096
             Project: Camel
          Issue Type: Bug
          Components: camel-ehcache
    Affects Versions: 3.14.7
            Reporter: Pieter Callewaert
             Fix For: 3.14.8
         Attachments: aggregation-investigation.zip

When using an EhCacheAggregationRepository with an offheap store and the aggregated exchange becomes too large, the cache entry is cleared, effectively loosing exchanges.

Have a route that aggregates string message bodies by aggregating them by concatinating the messages.  The aggregation is completed per 100 messages or 5 minutes. The aggregationRepository has a disk backed store.

When the aggregated exchange becomes to large, EhCache throws an 
{code:java}
 o.e.i.i.r.RobustResilienceStrategy - Ehcache key true recovered from
org.ehcache.spi.resilience.StoreAccessException: The element with key 'true' is too large to be stored in this offheap store.
        at org.ehcache.impl.internal.store.offheap.AbstractOffHeapStore.computeWithRetry(AbstractOffHeapStore.java:1038)        at org.ehcache.impl.internal.store.offheap.AbstractOffHeapStore.put(AbstractOffHeapStore.java:250)
        at org.ehcache.impl.internal.store.tiering.TieredStore.put(TieredStore.java:108) {code}
after this call the entry in the cache is removed, effectively loosing messages.
{code:java}
        cacheManager.createCache("cacheName", CacheConfigurationBuilder
                .newCacheConfigurationBuilder(String.class, DefaultExchangeHolder.class,
                        ResourcePoolsBuilder.newResourcePoolsBuilder()
                                .heap(1000, EntryUnit.ENTRIES)
                                .disk(1, MemoryUnit.MB, true))
                .withExpiry(ExpiryPolicyBuilder.noExpiration()));{code}
Attached is a project demonstrating the behaviour. As a reference there is also a variant with LevelDb which behaves as expected.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)