Yes.. Logging it is far far far far better.
I think a lot of devs don't have experience working in actual production
environments. YES the client should probably handle it, but WHICH client.
This is why you log things. Log the statement that was aborted (at least
the first 100 bytes),
On Wed, A
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).
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
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:
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 wrote:
>
> It seems these are basically impossible to track down.
>
> https://support.datastax.com/hc/en-us/articles/2072
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 wh
