conclusion to
deprecate the row cache.
Thanks,
German
From: Jon Haddad
Sent: Monday, December 18, 2023 10:31 AM
To: dev@cassandra.apache.org
Subject: [EXTERNAL] Re: Future direction for the row cache and OHC
implementation
You don't often get email f
Sure, I’d love to work with you on this.
—
Jon Haddad
Rustyrazorblade Consulting
rustyrazorblade.com
On Mon, Dec 18, 2023 at 8:30 AM Ariel Weisberg wrote:
> Hi,
>
> Thanks for the generous offer. Before you do that can you give me a chance
> to add back support for Caffeine for the row cache s
Hi,
Thanks for the generous offer. Before you do that can you give me a chance to
add back support for Caffeine for the row cache so you can test the option of
switching back to an on-heap row cache?
Ariel
On Thu, Dec 14, 2023, at 9:28 PM, Jon Haddad wrote:
> I think we should probably figure
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
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
> 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 n
>
> 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
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 we
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 w
I think we should probably figure out how much value it actually provides
by getting some benchmarks around a few use cases along with some
profiling. tlp-stress has a --rowcache flag that I added a while back to
be able to do this exact test. I was looking for a use case to profile and
write up
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.
> On Dec 14, 2023, at 5:35 PM, Paulo Motta wrote:
>
> This could be a potential hook for out-of-process caching.
>
> Would something like this be valuable/feasible?
It is certainly feasible. I am not sure about its value.
Dinesh
I like Dinesh's middle ground proposal, since this feature has valid uses.
I'm not familiar with the row caching module, but would it make sense to
take this opportunity to expose this feature as an optional Row Caching
Module, disabled by default with an optional on-heap Caffeine
implementation?
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 C
>
> 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
> On Dec 14, 2023, at 1:51 PM, Dinesh Joshi wrote:
>
>
>>
>> On Dec 14, 2023, at 10:32 AM, Ariel Weisberg wrote:
>>
>> 1. Fork OHC and start publishing under a new package name and continue to
>> use it
>
> Who would fork it? Where would you fork it? My first instinct is that this
> wo
> On Dec 14, 2023, at 10:32 AM, Ariel Weisberg wrote:
>
> 1. Fork OHC and start publishing under a new package name and continue to use
> it
Who would fork it? Where would you fork it? My first instinct is that this
would not be viable path forward.
> 2. Replace OHC with a different cache imp
Hi,
Now seems like a good time to discuss the future direction of the row cache and
its only implementation OHC (https://github.com/snazy/ohc).
OHC is currently unmaintained and we don’t have the ability to release maven
artifacts for it or commit to the original repo. I have reached out to the
18 matches
Mail list logo
