Re: Getting DigestMismatchExceptions despite setting read repair chances to zero

2017-10-27 Thread Jeff Jirsa
> On Oct 27, 2017, at 3:08 AM, Artur Siekielski wrote: > > I noticed that the DecoratedKey printed in the stack trace can be for a > different table. The arguments are a token and a partition key and they can > be the same for multiple tables. Is there a way to know for which

Re: Getting DigestMismatchExceptions despite setting read repair chances to zero

2017-10-27 Thread Artur Siekielski
I noticed that the DecoratedKey printed in the stack trace can be for a different table. The arguments are a token and a partition key and they can be the same for multiple tables. Is there a way to know for which table the DigestMismatchException happens? Can the AsyncRepairRunner be

Re: Getting DigestMismatchExceptions despite setting read repair chances to zero

2017-10-26 Thread Artur Siekielski
It was set to the default 99PERCENTILE, I changed it to NONE but the exceptions are still logged (for the same table). I'm assuming node restarts are not required for that ALTER. On 10/26/2017 05:13 PM, Jeff Jirsa wrote: Is speculative retry enabled?

Re: Getting DigestMismatchExceptions despite setting read repair chances to zero

2017-10-26 Thread Jeff Jirsa
Is speculative retry enabled? -- Jeff Jirsa > On Oct 26, 2017, at 3:19 AM, Artur Siekielski wrote: > > Hi, > > we have one table for which reads and writes are done with CL=ONE. The table > contains counters. We wanted to disable async read repair for the table (to > lessen

Getting DigestMismatchExceptions despite setting read repair chances to zero

2017-10-26 Thread Artur Siekielski
Hi, we have one table for which reads and writes are done with CL=ONE. The table contains counters. We wanted to disable async read repair for the table (to lessen cluster load and to avoid DigestMismatchExceptions in debug.log). After altering the table with read_repair_chance=0,