incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Neely <sne...@rallydev.com>
Subject Re: Failing to delete commitlog at startup/shutdown (Windows)
Date Mon, 23 Apr 2012 14:51:55 GMT
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.cook@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
>
>

Mime
View raw message