Ariel, thank you for bringing this topic to the ML. I may be missing something, so correct me if I'm wrong somewhere in the management of the Cassandra ecosystem. As I see it, the problem right now is that if we fork the ohc and put it under its own root, the use of that row cache is still not well tested (the same as it is now). I am particularly emphasising the dependency management side, as any version change/upgrade in Cassandra and, as a result of that change a new set of libraries in the classpath should be tested against this integration.
So, unless it is being widely used by someone else outside of the community (which it doesn't seem to be), from a maintenance and integration testing perspective I think it would be better to keep the ohc in-tree, so we will be aware of any issues immediately after the full CI run. I'm also +1 for not deprecating it, even if it is used in narrow cases, while the cost of maintaining its source code remains quite low and it brings some benefits. On Fri, 15 Dec 2023 at 05:39, Ariel Weisberg <ar...@weisberg.ws> wrote: > > 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. > >
