> Can you please elaborate on the specials of truncate? I think ed was talking about this config setting in 1.2 https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L484
> It works, only sometimes it silently fails (1 in 400 runs of the truncate, > actually). The data is left in place ? Are you making the calls very quickly? If you add a pause does it help ? > At the same time the truncate fails I see system ks compaction. Additionally, > it seems there is quite a lot of these system ks compactions (the numbers in > the filenames go up pretty fast to thousands). In 1.2 truncate updates a system table, which always flush after updates. Cheers ----------------- Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 12/04/2013, at 3:12 AM, Ondřej Černoš <cern...@gmail.com> wrote: > Hi, > > I have JNA (cassandra only complains about obsolete version - Obsolete > version of JNA present; unable to read errno. Upgrade to JNA 3.2.7 or later - > I have stock centos version 3.2.4). > > Usage of separate CFs for each test run is difficult to set up. > > Can you please elaborate on the specials of truncate? > > regards, > Ondřej Černoš > > > > On Thu, Apr 11, 2013 at 5:04 PM, Edward Capriolo <edlinuxg...@gmail.com> > wrote: > If you do not have JNA truncate has to fork an 'ln -s'' command for the > snapshots. I think that makes it un-predicatable. Truncate has its own > timeout value now (separate from the other timeouts). If possible I think it > is better to make each test use it's own CF and avoid truncate entirely. > > > On Thu, Apr 11, 2013 at 9:48 AM, Ondřej Černoš <cern...@gmail.com> wrote: > Hi, > > I use C* 1.2.3 and CQL3. > > I integrated cassandra into our testing environment. In order to make the > tests repeatable I truncate all the tables that need to be empty before the > test run via ssh session to the host cassandra runs on and by running cqlsh > where I issue the truncate. > > It works, only sometimes it silently fails (1 in 400 runs of the truncate, > actually). > > At the same time the truncate fails I see system ks compaction. Additionally, > it seems there is quite a lot of these system ks compactions (the numbers in > the filenames go up pretty fast to thousands). > > I googled truncate and found out there were some issues with race conditions > and with slowing down if truncate is used frequently (as is my case, where > truncate is run before each test in quite a big test suite). > > Any hints? > > Regards, > Ondřej Černoš > >
