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. >>>> >>>> >
