Make Caffeine the default in-memory cache

[ben-manes]

Per #4062, Druid now requires a Java 8 runtime. Previously the JDK7 support meant that the Caffeine integration was provided as an optional plugin. The default in-memory cache is a synchronized LinkedHashMap, which has low performance in production usages.

Switching was approved so this should improve the out-of-the-box experience.

[gianm]

@ben-manes would you be willing to contribute a patch that does the necessary shuffling around of things?

[ben-manes]

I could try, but I wouldn't be able to get to it for a week or two.

[gianm]

You might still get to it first!

Going to mark this 0.10.1 since it seems like something we should be able to do for the next release.

Btw, there is no "default" cache (by default cache is disabled, and enabling it requires setting a specific cache type) so imo, what this issue should be about is:

• Move caffeine-cache from an extension to core
• Update the example cache configs (where most users get their first cache configs from) to use caffeine instead of local
• Update other caching related docs, and release notes, to push people towards choosing caffeine over local
• Possibly deprecate local

An alternative interpretation is we should merge local with caffeine so they both do the same thing, but I don't think we should do this right now, in part because the configs are different and so it wouldn't be a fully compatible change with folks' existing configs. imo, it would make sense to do that in the next major release when local is not just deprecated, but removed.

[drcrallen]

To play Devils' advocate here:

Is there any advantage to moving it to core vs updating the example configs to include it by default?

[gianm]

My thinking is that since local and memcache are not-extensions, having caffeine be an extension makes it feel less "recommended". If local cache and memcache became extensions too then it would make sense for caffeine to stay an extension.

[drcrallen]

Would moving memcached and local to extensions make sense?

[drcrallen]

Or maybe just memcached

[drcrallen]

A "reference implementation" with no external dependencies is a good thing to keep in core druid

[drcrallen]

Having quality extensions helps serve as examples and templates for new developers.

[gianm]

Are you envisioning a path to deprecating and eventually removing local in that case? I was thinking a process like (1) move caffeine to core, (2) deprecate local, (3) remove local, (4) now caffeine is the only remaining local mode cache.

If caffeine stays an extension that at steps (3) and (4) we won't have any cache impl in core.

[drcrallen]

I was thinking:

1. Make things that are extension point AND require external dependencies be an extension
2. Move memcached to an extension
3. Make "local" the reference implementation inside of Druid and memcached/caffeine the reference extensions in extensions-core.
4. Since the hybrid cache doesn't require external dependencies, I'm not quite sure where it would fall here.

I'm not convinced this is the right way to go, this is just the first time we've had an extension that is hands down superior to the things that have been packaged in druid before. So spending some time figuring out what should be a core-extension vs what should be packaged in druid default makes some sense.

Core extensions are already packaged in every release, and cache is disabled by default, so since people have to choose the cache impl anyways and modify configs, I don't think it is undue burden.

[drcrallen]

so by "make default" if this means "use in all the examples and highly recommend it" then that can (and should) be done in either scenario.