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

["Claus Ibsen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-19096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704828#comment-17704828 ] 

Claus Ibsen commented on CAMEL-19096:
-------------------------------------

I think you need to configure your ehcache accordingly to your needs for capacity/sizes etc.

> EhcacheAggregationRepository drops messages on OversizeMappingException
> -----------------------------------------------------------------------
>
>                 Key: CAMEL-19096
>                 URL: https://issues.apache.org/jira/browse/CAMEL-19096
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-ehcache
>    Affects Versions: 3.14.7
>            Reporter: Pieter Callewaert
>            Priority: Minor
>         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)