Gotcha; wasn't sure given the earlier phrasing. Makes sense. Dinesh's compromise position makes sense to me.
On Fri, Dec 15, 2023, at 11:21 PM, Ariel Weisberg wrote: > Hi, > > I did get one response from Robert indicating that he didn’t want to do the > work to contribute it. > > I offered to do the work and asked for permission to contribute it and no > response. Followed up later with a ping and also no response. > > Ariel > > On Fri, Dec 15, 2023, at 9:58 PM, Josh McKenzie wrote: >>> I have reached out to the original maintainer about it and it seems like if >>> we want to keep using it we will need to start releasing it under a new >>> package from a different repo. >> >>> the current maintainer is not interested in donating it to the ASF >> Is that the case Ariel or could you just not reach Robert? >> >> On Fri, Dec 15, 2023, at 11:55 AM, Jeremiah Jordan wrote: >>>> 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. >>>>> >>>>> >> >
