Aleksey Yeschenko commented on CASSANDRA-14353:

A part of me thinks that the extra two catch-rethrows in {{DataResolver}} are 
unnecessary - we've only ever hit assertions in notoriously tricky 
{{onMergedRangeTombstoneMarkers()}}, not in 
{{onMergedPartitionLevelDeletion()}} or {{onMergedRows()}}. That part of me 
thinks we should just preserve the old behaviour, which would also get rid of 

But overall I'm ambivalent. I feel very strongly about 
{{onMergedRangeTombstoneMarkers()}} catch/retrhow block staying, but the other 
two can go, if you like. It can also stay if you like. Feel free to decide on 

+1 either way, the change to bring back over oversized mutation handling is 
fine too (made a note to add the missing test for it).

> Fix some regressions caused by 14058
> ------------------------------------
>                 Key: CASSANDRA-14353
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14353
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Blake Eggleston
>            Assignee: Blake Eggleston
>            Priority: Major
>             Fix For: 4.0
> As [~iamaleksey] pointed out, CASSANDRA-14058 introduced a few regressions:
> {quote}
> Noticed a couple regressions when merging up CASSANDRA-14330:
> 1. {{DataResolver}} no longer uses 
> {{cassandra.drop_oversized_readrepair_mutations}} prop - and 
> {{DROP_OVERSIZED_READ_REPAIR_MUTATIONS}} constant is now unused, and the 
> feature is missing.
> 2. {{RowIteratorMergeListener}} re-thrown {{AssertionError}} no longer 
> includes the responses. This should be restored, as without it debugging RR 
> issues is an even worse, potentially impossible, nightmare.
> Nit: In {{DataResolver}}, {{repairResults}} field is now unused.
> {quote}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to