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)
