On a related note, I still need to file a Jira just to make it easier to find large cells in general, I've had 2 customers now with a bunch of 10mb+ writes (single cell) they weren't expecting and tracking that down is equally challenging (Spark in both cases made it doable, but slow to find).
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 >>>
