Thanks Meg! Yes, we have already identified the problematics stables (there are 2 out of ~740). They are in one of our keyspaces not in system.
I’m not sure what connection request exceptions you are talking about? This? ERROR [SharedPool-Worker-3] 2017-03-28 23:50:33,998 Message.java:621 - Unexpected exception during request; channel = [id: 0x2366241f, L:/10.7.150.165:9042 - R:/10.179.229.62:32119] java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered partition That seems more like a data issue than a driver issue, no? > On Mar 29, 2017, at 11:56 AM, Meg Mara <mm...@digitalriver.com> wrote: > > Hi Eric, > > I am not sure why the commit logs were growing so much but I do have some > suggestions regarding the Unexpected exception during request and about > upgradesstables. I had recently upgraded from 2.2.5 to 3.0.10 and faced the > same issue with nodetool upgradesstables not converting all SStables. To > convert them all, you can run "nodetool upgradesstables -a" and then do a > check to see which sstables are still in old format. In your /cassandra/data/ > directory use the find command to search for older format sstables named as > -la- . This command should work "find . -name "la*" | grep -v snapshots". > > Then run "nodetool upgradesstables keyspace_name" for each of the keyspaces > listed. For me, primarily the system columnfamilies were left in older format. > > And about that connection request exceptions, they could be caused if the > connecting client is on an older incompatible java driver. Upgrade the java > driver to be compatible with your Cassandra version. Hope that helps. > > Thanks, > Meg Mara
