Re: CASSANDRA-8527

I think tombstone rows is more appropriate. Calling them deleted rows initially confused me and it took a few reads of the problem for me to work it out. Especially when you put it in context and "tombstone cells" follows.​

Re: CASSANDRA-8527

Sorry, don’t have strong feelings or suggestions regarding naming in logs/warnings. But I agree with this behaviour. — AY On 5 January 2018 at 19:31:58, Alexander Dejanovski (a...@thelastpickle.com) wrote: Right, I think naming it "deleted rows" is misleading because it suggests that 100 ro

Re: CASSANDRA-8527

Right, I think naming it "deleted rows" is misleading because it suggests that 100 rows shadowed by one RT would be counted as 100 tombstones, which is not the case here (those get merged away before getting counted). The patch counts row tombstones, where (after merge) one tombstone shadows a sin

Re: CASSANDRA-8527

Counting the number of range tombstones - sure, that is reasonable. Counting cells/rows shadowed by range tombstones toward the limit, as if they were regular tombstones - arguably not so much. — AY On 5 January 2018 at 18:53:45, Jon Haddad (j...@jonhaddad.com) wrote: I think it’s reasonable t

Re: CASSANDRA-8527

I think it’s reasonable to count the number of range tombstones towards the total tombstone count / threshold. I agree the number of rows shadowed by the tombstones should be tracked separately, and we should probably think a bit more about how to add configuration / limits around this withou

Re: CASSANDRA-8527

Hi Aleksey, ok we'll split the work and only deal with row level tombstones in CASSANDRA-8527 and create a follow up ticket to work on the separate counts you're suggesting. My understanding of what you say is that you would not include range

Re: CASSANDRA-8527

As Jeff says, the number of actual tombstones is no less relevant than the number of cells and rows shadowed by them. And the way row and cell tombstones affect a read query can be very different from the way a big range tombstone might: you potentially have to retain every (regular) tombstone i

Re: CASSANDRA-8527

Hi folks, thanks for the feedback so far. @Jeff, there are two distinct cases here : 1. The range tombstones created on a partial primary key (that doesn't include the last column of the PK for example) : a single tombstone can shadow many rows 2. The range tombstones created on the

Re: CASSANDRA-8527

I think that's a good idea for 4.x, but not so for current branches. I think as long as we document it well for 4.0 upgrades it's not so much of a problem. Obviously there will be cases of queries failing that were previously succeeding but we can already use tombstone_failure|warn_threshold to tun

Re: CASSANDRA-8527

Maybe I should rephrase my words but I think you got that thread. Singleton is one big thing and possibly we can use powermock, or totally get rid of it. But without mock, I'm frustrated to work on so-called unit test cases. On Thu, Dec 21, 2017 at 2:28 PM, Jeff Jirsa wrote: > On Thu, Dec 21, 20

Re: CASSANDRA-8527

On Thu, Dec 21, 2017 at 12:33 PM, Qingcun Zhou wrote: > I brought up Mockito topic couple of months ago but some committers don't > think we should introduce more dependencies. > > I don't see any indication of this in the dev@ archives. There was a comment from a contributor who said they weren'

Re: CASSANDRA-8527

On Tue, Dec 19, 2017 at 11:07 PM, Alexander Dejanovski < a...@thelastpickle.com> wrote: > Hi folks, > > I'm working on CASSANDRA-8527 > and would need to > discuss a few things. > > The ticket makes it visible in tracing and metrics that rows

Re: CASSANDRA-8527

The question isn’t so much about reporting them (we should), it’s about the behavior of tombstone_warn_threshold and tombstone_failure_threshold. The patch changes the behavior to include the number of rows that are passed over due to the range tombstones. We’re interested in feedback on if it

Re: CASSANDRA-8527

+1 to report range tombstones. This one is quite tricky indeed to track +1 to Mockito too, with the reserve that it should be used wisely On Thu, Dec 21, 2017 at 9:11 PM, Jon Haddad wrote: > I had suggested to Alex we kick this discussion over to the ML because the > change will have a signific

Re: CASSANDRA-8527

I brought up Mockito topic couple of months ago but some committers don't think we should introduce more dependencies. On Thu, Dec 21, 2017 at 12:11 PM, Jon Haddad wrote: > I had suggested to Alex we kick this discussion over to the ML because the > change will have a significant impact on the b

Re: CASSANDRA-8527

I had suggested to Alex we kick this discussion over to the ML because the change will have a significant impact on the behavior of Cassandra when doing reads with range tombstones that cover a lot of rows. The behavior now is a little weird, a single tombstone could shadow hundreds of thousand