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

Nicolas Filotto commented on CAMEL-21888:
-----------------------------------------

Please provide steps to reproduce, ideally a small GitHub project.

By *high CPU usage at startup*, do you mean that once started, the CPU goes 
back to normal or it never ends? 

> High CPU usage at startup due to Deque.size() iteration in SimpleLRUCache
> -------------------------------------------------------------------------
>
>                 Key: CAMEL-21888
>                 URL: https://issues.apache.org/jira/browse/CAMEL-21888
>             Project: Camel
>          Issue Type: Bug
>          Components: came-core
>    Affects Versions: 4.7.0
>            Reporter: Nadina Florea
>            Priority: Major
>
> Hello,
> Starting with *Camel 4.7.0,* a change was introduced in *SimpleLRUCache,* 
> where a *Deque* is now used to track *lastChanges.* 
> Please see: 
> [https://github.com/apache/camel/commit/a7e696927dea30795a49a4c0ac4a36ee700131ff]
>  and CAMEL-20850
> This change causes *high CPU usage at startup* when the cache is populated, 
> as *Deque.size() iterates over all cache entries.*
> This issue was observed only in production, after migrating to Camel 4.7.0, 
> where the cache size is significantly large (1,200,000 entries at that time). 
> Current stable version is Camel 4.6.0.
>  
> We are using {*}KafkaIdempotentRepository{*}, which relies on SimpleLRUCache. 
> In our app, we expose a metric that contains the size of the cache at a 
> certain point.
> {code:java}
> @Bean
> @ConditionalOnBean(KafkaIdempotentRepository.class)
> public MeterBinder cacheSize(final KafkaIdempotentRepository 
> idempotentRepository) {
>   return registry -> 
> Gauge.builder("cacheSize",idempotentRepository::getCacheSize)
> .register(registry);
> }{code}
> Would appreciate any insights on this issue.
>  
>  



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

Reply via email to