The issue you should look at is CASSANDRA-4206.
This is apparently fixed on 2.0 so upgrading is one option. If you are not
ready to upgrade to 2.0 then you can try increasing in_memory_compaction.
We were hitting this exception on one of our nodes and increasing
in_memory_compaction did fix it.
Scrub is very likely to resolve it. Note that scrub will drop (and log)
invalid items, so pay attention to what it logs and plan on doing a repair
afterwards to pull in a copy from a different node, assuming RF>1
-Tupshin
On Feb 17, 2014 8:54 AM, "Oleg Dulin" wrote:
> Bumping this up -- anyth
Bumping this up -- anything ? anyone ?
On 2014-02-13 16:01:50 +, Oleg Dulin said:
I am getting these exceptions on one of the nodes, quite often, during
compactions:
"java.lang.AssertionError: originally calculated column size of
84562492 but now it is 84562600"
Usually this is on the
I am getting these exceptions on one of the nodes, quite often, during
compactions:
"java.lang.AssertionError: originally calculated column size of
84562492 but now it is 84562600"
Usually this is on the same column family.
I believe this is preventing compactions from completing, and
subs
