Hi, To add some additional context.
The row cache is disabled by default and it is already pluggable, but there isn’t a Caffeine implementation present. I think one used to exist and could be resurrected. I personally also think that people should be able to scratch their own itch row cache wise so removing it entirely just because it isn’t commonly used isn’t the right move unless the feature is very far out of scope for Cassandra. Auto enabling/disabling the cache is a can of worms that could result in performance and reliability inconsistency as the DB enables/disables the cache based on heuristics when you don’t want it to. It being off by default seems good enough to me. RE forking, we could create a GitHub org for OHC and then add people to it. There are some examples of dependencies that haven’t been contributed to the project that live outside like CCM and JAMM. Ariel On Thu, Dec 14, 2023, at 5:07 PM, Dinesh Joshi wrote: > I would avoid taking away a feature even if it works in narrow set of > use-cases. I would instead suggest - > > 1. Leave it disabled by default. > 2. Detect when Row Cache has a low hit rate and warn the operator to turn it > off. Cassandra should ideally detect this and do it automatically. > 3. Move to Caffeine instead of OHC. > > I would suggest having this as the middle ground. > >> On Dec 14, 2023, at 4:41 PM, Mick Semb Wever <m...@apache.org> wrote: >> >> >> >>> 3. Deprecate the row cache entirely in either 5.0 or 5.1 and remove it in a >>> later release >> >> >> >> I'm for deprecating and removing it. >> It constantly trips users up and just causes pain. >> >> Yes it works in some very narrow situations, but those situations often >> change over time and again just bites the user. Without the row-cache I >> believe users would quickly find other, more suitable and lasting, solutions.
