Re: [VOTE] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

+1 for reasons stated in the discussion. Kind Regards, Brandon On Sun, Aug 4, 2024 at 1:18 AM Yifan Cai wrote: > > Hi, > > I am proposing backporting CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0. > > There is a discussion thread on the topic. In summary, the backport would > benefit Cassandra

Re: [DISCUSS] inotify for detection of manually removed snapshots

> If you have a lot of snapshots and have for example a metric monitoring them > and their sizes, if you don’t cache it, creating the metric can cause > performance degradation. We added the cache because we saw this happen to > databases more than once. I mean, I believe you, I'm just surprised

Re: [VOTE] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

+1. I'm ultimately in favor of setting the precedent of allowing low-risk ecosystem interop changes in non-trunk. On Wed, Aug 7, 2024, at 2:10 PM, Dinesh Joshi wrote: > +1 > > I think this is a low risk change which is going to avoid duplication of > effort so it is worth it. > > On Sat, Aug

Re: [DISCUSS] inotify for detection of manually removed snapshots

On Wed, Aug 7, 2024 at 6:39 PM Yifan Cai wrote: > With WatcherService, when events are missed (which is to be expected), you > will still need to list the files. It seems to me that WatcherService > doesn't offer significant benefits in this case. > Yeah I think we leave it out eventually. Rega

Re: [VOTE] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

+1 I think this is a low risk change which is going to avoid duplication of effort so it is worth it. On Sat, Aug 3, 2024 at 11:19 PM Yifan Cai wrote: > Hi, > > I am proposing backporting CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0. > > There is a discussion thread >

Re: [DISCUSS] state of lz4-java

reply below. - since the project is Apache licensed we could fork / adopt for our needs? > I’m not familiar enough with the hurdles we’d have to surmount around the > licensing but at least it’s a compatible license. Maybe Mick knows more > about what would be required for this route? > It's "C

Re: [DISCUSS] inotify for detection of manually removed snapshots

With WatcherService, when events are missed (which is to be expected), you will still need to list the files. It seems to me that WatcherService doesn't offer significant benefits in this case. Regarding listing directory with a refresh flag, my concern is the potential for abuse. End-users might/

Re: [DISCUSS] inotify for detection of manually removed snapshots

Yes, for example as reported here https://issues.apache.org/jira/browse/CASSANDRA-13338 People who are charting this in monitoring dashboards might also hit this. On Wed, Aug 7, 2024 at 2:59 PM J. D. Jordan wrote: > If you have a lot of snapshots and have for example a metric monitoring > them

Re: [DISCUSS] inotify for detection of manually removed snapshots

If you have a lot of snapshots and have for example a metric monitoring them and their sizes, if you don’t cache it, creating the metric can cause performance degradation. We added the cache because we saw this happen to databases more than once. > On Aug 7, 2024, at 7:54 AM, Josh McKenzie wro

Re: [DISCUSS] inotify for detection of manually removed snapshots

I would go with the mbean change option. I would add a new “list” function with a new parameter to the mbean that allows specifying if it should refresh the cache before returning the list. No need to do the inotify stuff just for nodetool listsnapshot to be always correct. Then add a new parame

Re: [DISCUSS] inotify for detection of manually removed snapshots

> Snapshot metadata are currently stored in memory / they are cached so we do > not need to go to disk every single time we want to list them, the more > snapshots we have, the worse it is. Are we enumerating our snapshots somewhere on the hot path, or is this performance concern misplaced? On

[DISCUSS] inotify for detection of manually removed snapshots

Snapshot metadata are currently stored in memory / they are cached so we do not need to go to disk every single time we want to list them, the more snapshots we have, the worse it is. When a snapshot is _manually_ removed from disk, not from nodetool clearsnapshot, just by rm -rf on a respective s