Hi Steve, Thanks for your reply, sorry for the delay in getting back to you. We're actually doing something very similar already, using Hector's EmbeddedServerHelper (it's basically the same, maybe it came from the same code). Unfortunately whilst writing this our internet went down and I sometimes need to develop offline anyway, so using an external Cassandra instance isn't really an option.
I've had a try using the maven-cassandra-plugin and don't seem to be having the problem any more, plus it's a neater solution anyway. Conan On 23 April 2012 15:51, Steve Neely <sne...@rallydev.com> wrote: > We used a modified version of Ran's embedded Cassandra for a while: > http://prettyprint.me/2010/02/14/running-cassandra-as-an-embedded-service/which > worked well for us. You have way more control over that. > > Recently, we switched to having a single Cassandra installation that runs > all the time. Kind of like you'd treat a regular relational DB. Just fire > up Cassandra, leave it running and point your tests at that instance. Seems > like starting up your data store every time you execute integration tests > will slow them down and isn't really helpful. > > BTW, you may want to scrub the test data out of Cassandra when you're test > suite finishes. > > -- Steve > > > > On Mon, Apr 23, 2012 at 8:41 AM, Conan Cook <conan.c...@amee.com> wrote: > >> Hi, >> >> I'm experiencing a problem running a suite of integration tests on >> Windows 7, using Cassandra 1.0.9 and Java 1.6.0_31. A new cassandra >> instance is spun up for each test class and shut down afterwards, using the >> Maven Failsafe plugin. The problem is that the Commitlog file seems to be >> kept open, and so subsequent test classes fail to delete it. Here is the >> stack trace: >> >> java.io.IOException: Failed to delete >> D:\amee.realtime.api\server\engine\tmp\var\lib\cassandra\commitlog\CommitLog-1335190398587.log >> at >> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:54) >> at >> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:220) >> at >> org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:216) >> ... >> >> I've tried to delete the file when shutting down Cassandra and before >> firing up a new one. I've tried setting the failsafe plugin's forkMode to >> both "once" and "always", so that it fires up a new JVM for each test or a >> single JVM for all tests; the results are similar. Debugging through the >> code takes me right down to the native method call in the windows >> filesystem class in the JVM, and an access denied error is returned; I'm >> also unable to delete it manually through Windows Explorer or a terminal >> window at that point (with the JVM suspended), and running Process Explorer >> indicates that a Java process has a handle open to that file. >> >> I've read a number of posts and mails mentioning this problem and there >> is a JIRA saying a similar problem is fixed ( >> https://issues.apache.org/jira/browse/CASSANDRA-1348). I've tried a >> number of things to clean up the Commitlog file after each test is >> complete, and have followed the recommendations made here (I'm also using >> Hector's EmbeddedServerHelper to start/stop Cassandra): >> http://stackoverflow.com/questions/7944287/how-to-cleanup-embedded-cassandra-after-unittest >> >> Does anyone have any ideas on how to avoid this issue? I don't have any >> way of knowing what it is that's holding onto this file other than a Java >> process. >> >> Thanks! >> >> >> Conan >> >> >
