cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-6476) Assertion error in MessagingService.addCallback
Date Tue, 22 Apr 2014 21:06:20 GMT


Brandon Williams updated CASSANDRA-6476:

    Attachment: 6476.txt

Half a backport from CASSANDRA-6948 to only affect replace.

> Assertion error in MessagingService.addCallback
> -----------------------------------------------
>                 Key: CASSANDRA-6476
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 2.0.2 DCE, Cassandra 1.2.15
>            Reporter: Theo Hultberg
>            Assignee: Brandon Williams
>         Attachments: 6476.txt
> Two of the three Cassandra nodes in one of our clusters just started behaving very strange
about an hour ago. Within a minute of each other they started logging AssertionErrors (see
stack traces here: over and over again. The client
lost connection with the nodes at roughly the same time. The nodes were still up, and even
if no clients were connected to them they continued logging the same errors over and over.
> The errors are in the native transport (specifically MessagingService.addCallback) which
makes me suspect that it has something to do with a test that we started running this afternoon.
I've just implemented support for frame compression in my CQL driver cql-rb. About two hours
before this happened I deployed a version of the application which enabled Snappy compression
on all frames larger than 64 bytes. It's not impossible that there is a bug somewhere in the
driver or compression library that caused this -- but at the same time, it feels like it shouldn't
be possible to make C* a zombie with a bad frame.
> Restarting seems to have got them back running again, but I suspect they will go down
again sooner or later.

This message was sent by Atlassian JIRA

View raw message