Hi,
Cassandra starts JVM as "$JAVA -ea -cp $CLASSPATH...".
Looks like $JAVA is coming is empty in your case, hence the error "exec -ea
not found".
Do you not have java installed? Please install it and set JAVA_HOME
appropriately and retry.
Cheers.
On Mon, Sep 12, 2011 at 8:23 AM, Hernán Queved
>
> Hi, all.
>
> I´m new at this and haven´t been able to install cassandra in debian
> 6. After uncompressing the tar and creating var/log and var/lib
> directories, the command bin/cassandra -f results in message "exec:
> 357 -ea not found" preventing cassandra from run the process README
> file
thanks, it does seem possible that this is due to accessing unmapped buffer:
the following code will always generate SEGV.
import java.lang.reflect.Method;
import java.nio.*;
import java.nio.channels.FileChannel;
import java.io.*;
public class TestRandomAccess {
public static void main(Stri
The problem would be because we're trying to access a mappedbytebuffer
that has been unmapped, not because of OS deletion semantics.
On Sun, Sep 11, 2011 at 2:12 PM, Yang wrote:
> unfortunately it appeared again, I confirmed it appeared with the
> -XX:-UseCompressedOops .
>
> so, if it's due to
You should be using the off heap row cache option. That way you avoid GC
overhead and the rows are stored in a compact serialized form that means you
get more cache entries in RAM. Trade off is slightly more CPU for
deserialization etc.
Adrian
On Sunday, September 11, 2011, aaron morton wrote:
>
If the row cache is enabled the read path will not use the sstables. Depending
on the workload I would then look at setting *low* memtable flush settings to
use as much memory as possible for the row cache. If the row is in the row
cache the read path will not look at SSTables.
Then set the ro
Hi, all.
I´m new at this and haven´t been able to install cassandra in debian
6. After uncompressing the tar and creating var/log and var/lib
directories, the command bin/cassandra -f results in message "exec:
357 -ea not found" preventing cassandra from run the process README
file says it is supp
unfortunately it appeared again, I confirmed it appeared with the
-XX:-UseCompressedOops .
so, if it's due to accessing unmapped file, the problem should
disappear if I use direct random access file, I'll try that.
also if a process A (not only java) has a file mmapped, and another
process delet
