To avoid lingering of Guava for a few more Druid releases in code, the "guava" config value could just forcibly use caffeine cache, concurrencyLevel parameter ignored, and appropriate warning messages logged. There is no harm in this, Caffeine's concurrency is practically "elastic" and doesn't demand concurrencyLevel.
On Mon, 6 Jan 2020 at 01:13, Gian Merlino <g...@apache.org> wrote: > Hey JJ, > > I think your idea of adding a new option and deprecating "guava" is a good > way forward. > > Gian > > On Fri, Dec 27, 2019 at 7:50 AM JJ Meyer <jjmey...@gmail.com> wrote: > > > Hello all, > > > > I'm planning on contributing for the first time. I'm working on > > https://github.com/apache/druid/issues/8399. No issues seem to occur > when > > replacing guava with caffeine in any of the classes posted in the issue > > with exception of the class, OnHeapLoadingCache. > > > > I wanted to post something here as I believe it will require a config > > change to use caffeine in this case. ( > > > > > https://druid.apache.org/docs/latest/development/extensions-core/druid-lookups.html#example-loading-on-heap-guava > > ). > > It seems as if guava's `concurrencyLevel` is not a property in caffeine's > > cache. Currently there are types `guava` and `mapDb`. To prevent a config > > change a third cache type, caffeine, can be added and the guava cache can > > be marked as deprecated and potentially removed in some future major > > release. The configs would be identical to the guava type with exception > of > > `concurrencyLevel` (it will be removed for the caffeine option). > > > > What do you all think of this? Is there another solution that is > preferred? > > > > Thanks, > > JJ > > >
