That code path was added to protect against invalid gossip states For this logger to be issued, the coordinator receiving the query must identify a set of replicas holding the data to serve the read, and one of the selected replicas must disagree that it’s a replica based on its view of the token ring
This probably means that at least one node in your cluster has an invalid view of the ring - if you issue a “nodetool ring” from every host and compare them, you’ll probably notice one or more is wrong It’s also possible this happens for a few seconds during adding / moving / removing hosts If you weren’t changing the topology of the cluster, it’s likely the case that bouncing the cluster fixes it (Im unsure of the defaults and not able to look it up, but cassandra can log or log and drop the read - you probably want to drop the read log, which is the right solution so it doesn’t accidentally return a missing / empty result set as a valid query result, instead it’ll force it to read from other replicas or time out) > On Oct 20, 2023, at 10:57 PM, Jaydeep Chovatia <chovatia.jayd...@gmail.com> > wrote: > > > Hi, > I am using Cassandra 4.0.6 in production, and receiving the following error. > This indicates that Cassandra nodes have mismatch in token-owership. > Has anyone seen this issue before? > Received a read request from /XX.XX.XXX.XXX:YYYYY for a range that is not > owned by the current replica Read(keyspace.table columns=*/[c1] rowFilter= > limits=LIMIT 100 key=7BE78B90-AD66-406B-AA05-6A062F72F542:0 > filter=slice(slices=ALL, reversed=false), nowInSec=1697751757). > Jaydeep
