What I do, is that I have VmWare player with VM running Cassandra localy on my laptop. This is useful when there is no internet connection and works fine for me.
*Tamar Fraenkel * Senior Software Engineer, TOK Media [image: Inline image 1] ta...@tok-media.com Tel: +972 2 6409736 Mob: +972 54 8356490 Fax: +972 2 5612956 On Tue, May 8, 2012 at 7:46 PM, Conan Cook <conan.c...@amee.com> wrote: > 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 >>> >>> >> >
<<tokLogo.png>>
