Re: DefaultTimeoutMap vs Caffeine

[Guillaume Nodet <gn...@apache.org>]

I'm currently in the process of making caffeine optional by externalizing
it from camel-core into its own module, similar to camel-headersmap.  It
will be aumtically wired if in the class path using a custom
META-INF/services file.  So please make sure it actually says optional.

Le sam. 9 févr. 2019 à 12:01, Marc Carter <dr...@gmail.com> a écrit :

> TimeoutMap (primarily used by AggregateProcessor with completionTimeout
> ) is not well suited to large aggregation maps as it does an O(n) scan
> across all registered timeouts every 1000ms. I intended to take a look
> at improving this but it's also not great example of open-close either,
> all users must extend DefaultTimeoutMap to get any use at all meaning
> it's difficult to substitute an experimental implementation.  The
> further the thought process goes the more it turns into "why not use
> Caffeine"
>
> * Already in use in camel-core (LRUCache etc)
>
> * Synchronous eviction listeners -
> https://github.com/ben-manes/caffeine/wiki/Writer
>
> * Supports O(1) per-entry timeouts -
> https://github.com/ben-manes/caffeine/issues/114
>
> * Has active eviction/refresh capabilities which can (probably) be used
> to trigger EIP completed-by-timeout
>
> Thoughts?
>
> Marc
>
>
>

-- 
------------------------
Guillaume Nodet

Re: DefaultTimeoutMap vs Caffeine

[Marc Carter <dr...@gmail.com>]

Thanks for passing that on! Is Netty also being removed as a core 
dependency?

I have been looking into this and Caffeine is _not_ currently a great 
fit as it *doesn't* yet support synchronous eviction listeners (*). 
Instead, I now have a pared-down but fully working implementation using 
CHM memory-consistency guarantees in place of the explicit Lock, 
io.netty.util.HashedWheelTimer to implement evictions and a few JMH 
benchmarks for #put(K,V) cost. Remaining work:

* Align with AggregationProcessor locking strategies (this one might be 
tricky)

* Figure out if/how to compose suitable scenario tests for something 
with asynchronous behaviour and amortising costs.

* Compare Netty HashedWheelTimer vs Caffeine TimerWheel

Marc

(*) Below Issue is exactly the scenario Camel wants. Linked issues 
update the accidentally misleading docs:

https://github.com/ben-manes/caffeine/issues/195

On 3/25/19 11:42 AM, Guillaume Nodet wrote:
> I'm currently in the process of making caffeine optional by externalizing
> it from camel-core into its own module, similar to camel-headersmap.  It
> will be aumtically wired if in the class path using a custom
> META-INF/services file.  So please make sure it actually says optional.
>
> Le sam. 9 févr. 2019 à 12:01, Marc Carter <dr...@gmail.com> a écrit :
>
>> TimeoutMap (primarily used by AggregateProcessor with completionTimeout
>> ) is not well suited to large aggregation maps as it does an O(n) scan
>> across all registered timeouts every 1000ms. I intended to take a look
>> at improving this but it's also not great example of open-close either,
>> all users must extend DefaultTimeoutMap to get any use at all meaning
>> it's difficult to substitute an experimental implementation.  The
>> further the thought process goes the more it turns into "why not use
>> Caffeine"
>>
>> * Already in use in camel-core (LRUCache etc)
>>
>> * Synchronous eviction listeners -
>> https://github.com/ben-manes/caffeine/wiki/Writer
>>
>> * Supports O(1) per-entry timeouts -
>> https://github.com/ben-manes/caffeine/issues/114
>>
>> * Has active eviction/refresh capabilities which can (probably) be used
>> to trigger EIP completed-by-timeout
>>
>> Thoughts?
>>
>> Marc
>>
>>
>>