Where I see this a lot is: 1. DBA notices it in logs 2. Everyone says code works fine no errors 3. Weeks of combing all apps find out 3 teams are doing fire and forget futures... 4. Convince each team they really need to handle futures 5. Couple months before you figure out who was the culprit by the time he deploys hit production.
Would save everyone a ton of brain cells if we just logged it. Regards, Ryan Svihla > On Aug 3, 2016, at 4:21 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > > I haven't verified, so i'm not 100% certain, but I believe you'd get back an > exception to the client. Yes, this belongs in the DB, but I don't think > you're totally blind to what went wrong. > > My guess is this exception in the Python driver (but other drivers should > have a similar exception): > https://github.com/datastax/python-driver/blob/master/cassandra/protocol.py#L288 > >> On Wed, Aug 3, 2016 at 1:59 PM Ryan Svihla <r...@foundev.pro> wrote: >> Made a Jira about it already >> https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-12231 >> >> Regards, >> >> Ryan Svihla >> >>> On Aug 3, 2016, at 2:58 PM, Kevin Burton <bur...@spinn3r.com> wrote: >>> >>> It seems these are basically impossible to track down. >>> >>> https://support.datastax.com/hc/en-us/articles/207267063-Mutation-of-x-bytes-is-too-large-for-the-maxiumum-size-of-y- >>> >>> has some information but their work around is to increase the transaction >>> log. There's no way to find out WHAT client or what CQL is causing the >>> large mutation. >>> >>> Any thoughts on how to mitigate this? >>> >>> Kevin >>> >>> -- >>> We’re hiring if you know of any awesome Java Devops or Linux Operations >>> Engineers! >>> >>> Founder/CEO Spinn3r.com >>> Location: San Francisco, CA >>> blog: http://burtonator.wordpress.com >>> … or check out my Google+ profile >>>
