> > 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.
>From the original email bringing OHC in tree is not an option because the current maintainer is not interested in donating it to the ASF. Thus the option 1 of some set of people forking it to their own github org and maintaining a version outside of the ASF C* project. -Jeremiah On Dec 15, 2023 at 5:57:31 AM, Maxim Muzafarov <mmu...@apache.org> wrote: > 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. > > > >
