[ 
https://issues.apache.org/jira/browse/CASSANDRA-13085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150839#comment-16150839
 ] 

Jason Rust commented on CASSANDRA-13085:
----------------------------------------

We've also hit this issue when trying to deploy C* on windows.  If a new 
directory is chosen it might make sense to also use that as the default in the 
HeapUtils class, the only other class that references and tries to write to the 
CASSANDRA_HOME folder.

A less-invasive workaround I've found is to set CASSANDRA_HOME to the data 
directory as the very last line of cassandra-env.ps1.  This allows the 
libraries to be sourced from the real CASSANDRA_HOME, but then overwrites the 
variable before C* actually launches.

> Cassandra fails to start because WindowsFailedSnapshotTracker can not write 
> to CASSANDRA_HOME
> ---------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13085
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13085
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local Write-Read Paths, Packaging
>         Environment: might be windows only considering the classname
>            Reporter: Pieter-Jan Pintens
>              Labels: windows
>
> We are currently trying to package Cassandra with our application.
> In windows our server does not want to start because it want to write to 
> CASSANDRA_HOME\.toDelete, since we install to 'C:\program files\...' this is 
> not possible when started under a non privileged user. We were hoping that 
> setting pointers for the data and log dir to a writable location (somewhere 
> under user home) would be enough to start cassandra but this component wants 
> to write to a path that we cannot modify.
> For us there are a couple of solutions:
> 1) the location can be specified using a system property like data and log 
> dirs
> 2) this file is written to the data location
> Our current work arround would be to patch this class file but that is hard 
> to maintain.
> {noformat}
> Exception (java.lang.RuntimeException) encountered during startup: Failed to 
> cre
> ate failed snapshot tracking file [.toDelete]. Aborting
> java.lang.RuntimeException: Failed to create failed snapshot tracking file 
> [.toDelete]. Aborting 
>         at 
> org.apache.cassandra.db.WindowsFailedSnapshotTracker.deleteOldSnapshots(WindowsFailedSnapshotTracker.java:98)
>         at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:186)
>         at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
>         at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
>         at com.id.cassandra.wrapper.Main.main(Unknown Source)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>         at java.lang.reflect.Method.invoke(Unknown Source)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to