Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D35E490B2 for ; Tue, 8 May 2012 16:46:55 +0000 (UTC) Received: (qmail 99153 invoked by uid 500); 8 May 2012 16:46:53 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 99130 invoked by uid 500); 8 May 2012 16:46:53 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 99114 invoked by uid 99); 8 May 2012 16:46:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2012 16:46:53 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of conan.cook@amee.cc designates 209.85.161.172 as permitted sender) Received: from [209.85.161.172] (HELO mail-gg0-f172.google.com) (209.85.161.172) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2012 16:46:47 +0000 Received: by ggmi1 with SMTP id i1so1934160ggm.31 for ; Tue, 08 May 2012 09:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amee.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SBMyi8eFdoROhL1nQsu/1pjN7mB5gaT4eBingFoV4jw=; b=CT2rL/0RoYz/sGCXCDuaOU08C6Gi2TF0cembwWrn0pxJUq76MIkVrQGHG/LHgHDHh9 3xVAeJL9UQdUNub162Rp1Qdbx8wdUhdF5IsV42JWDUZodgaHpUtxTLjVZQmsaoqC1jpc xTVcl9MzQk5OmUSV1dOGGJmWK9ATmEGC/uqfk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=SBMyi8eFdoROhL1nQsu/1pjN7mB5gaT4eBingFoV4jw=; b=oIRlpBqudyJXqWPq/0u1V/W+/CPFzkTkPlW+3VYwvrHUMWM8h+nXNwo+zC1HJl+z73 ZPwCqhKGF238Z72ICsemwx2oMxiqVkq8dBwYxqdw8UBpyChUgZIVW5LUmaFiynPGE4CP gQtzdEGj1WB5Uim7kB+4bVTZEM2jFgJTDXcle6xr02oro/X2yXLJQSNucQl/RRZV4/5U sJoqocfz5l/ontc24v+ugdYZm5XBwtPwE/Jy8cTEP5CAYkz+BMWKjfHjsiVfiTXgPkvZ PfPe/1eDbPq6pHhBX/wpxFf0IlDUyREugjNoQpTiUU1E3fQz8ASpbAiA48uoH0dfmj7p Yr+Q== MIME-Version: 1.0 Received: by 10.236.179.40 with SMTP id g28mr24463131yhm.86.1336495586088; Tue, 08 May 2012 09:46:26 -0700 (PDT) Received: by 10.100.165.18 with HTTP; Tue, 8 May 2012 09:46:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 May 2012 17:46:26 +0100 Message-ID: Subject: Re: Failing to delete commitlog at startup/shutdown (Windows) From: Conan Cook To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=20cf303ddc2ca7152904bf89204d X-Gm-Message-State: ALoCoQn3fVKxSxv8Do6lIxIi2KJw/gx7o2GJG9iCOZob+VQ/G/T0tyN9rEE6Qrg+aOyeIdS54wj+ --20cf303ddc2ca7152904bf89204d Content-Type: text/plain; charset=ISO-8859-1 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 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 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 >> >> > --20cf303ddc2ca7152904bf89204d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Steve,

Thanks for your reply, sorry for the delay in = getting back to you. =A0We're actually doing something very similar alr= eady, using Hector's EmbeddedServerHelper (it's basically the same,= maybe it came from the same code). =A0Unfortunately whilst writing this ou= r internet went down and I sometimes need to develop offline anyway, so usi= ng an external Cassandra instance isn't really an option. =A0

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 s= olution anyway.

Conan

On 23 April 2012 15:51, Steve Neely <snee= ly@rallydev.com> wrote:
We used a modified version of Ran's embedded Cassandra for a while= :=A0http://prettyprint.me/2010/02/14/running-= cassandra-as-an-embedded-service/ which worked well for us. You have wa= y more control over that.

Recently, we switched to having a single=A0Cassandra=A0= 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 tes= ts 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 Cassand= ra when you're test suite finishes.
=
-- Steve



On Mon, Apr 2= 3, 2012 at 8:41 AM, Conan Cook <conan.cook@amee.com> wrote= :
Hi,

I'm experiencing a problem running a suite of integration tests o= n Windows 7, using Cassandra 1.0.9 and Java 1.6.0_31. =A0A new cassandra in= stance is spun up for each test class and shut down afterwards, using the M= aven Failsafe plugin. =A0The problem is that the Commitlog file seems to be= kept open, and so subsequent test classes fail to delete it. =A0Here is th= e stack trace:

java.io.IOException: Failed to delete D:\amee.real= time.api\server\engine\tmp\var\lib\cassandra\commitlog\CommitLog-1335190398= 587.log
at org.apach= e.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:54)
at org.apache.cassandra.i= o.util.FileUtils.deleteRecursive(FileUtils.java:220)
at org.apache.cassandra.io.util.FileUtils= .deleteRecursive(FileUtils.java:216)
...

I've tried to delete the file w= hen shutting down Cassandra and before firing up a new one. =A0I've tri= ed 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. =A0Debugging through the code = takes me right down to the native method call in the windows filesystem cla= ss 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 tha= t a Java process has a handle open to that file.=A0

I've read a number of posts and mails mentioning th= is problem and there is a JIRA saying a similar problem is fixed (https://issues.apache.org/jira/browse/CASSANDRA-1348). =A0I've tri= ed a number of things to clean up the Commitlog file after each test is com= plete, and have followed the recommendations made here (I'm also using = Hector's EmbeddedServerHelper to start/stop Cassandra):=A0http://stackoverflow.com/questions/794428= 7/how-to-cleanup-embedded-cassandra-after-unittest

Does anyone have any ideas on how to avoid this issue? = =A0I don't have any way of knowing what it is that's holding onto t= his file other than a Java process.

Thanks!


Conan



--20cf303ddc2ca7152904bf89204d--