launch failure with current git (svn?)
I was using svn cassandra from about a week ago, and it worked for me;
but then I updated to today's and got the below error after rebuild.
Help, please: Should I apply some known config file change, or just
revert, or ?
The version failing is
https://svn.apache.org/repos/asf/cassandra/tr...@989392
PS: I'm working on Perl client code, so this really is a dev@ question. :-)
+ exec /usr/bin/java -ea -XX:+UseThreadPriorities
-XX:ThreadPriorityPolicy=42 -Xms2G -Xmx2G
-XX:+HeapDumpOnOutOfMemoryError -Xss128k -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=80
-Dcom.sun.management.jmxremote.port=8089
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dlog4j.configuration=log4j-server.properties -Dcassandra-foreground=yes
-cp
/home/chip/cassandra/conf:bin/../build/classes:bin/../lib/antlr-3.1.3.jar:bin/../lib/avro-1.4.0-sources~r986959.jar:bin/../lib/avro-1.4.0~r986959.jar:bin/../lib/clhm-production.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-collections-3.2.1.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/guava-r05.jar:bin/../lib/hadoop-core-0.20.1.jar:bin/../lib/high-scale-lib.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jetty-6.1.21.jar:bin/../lib/jetty-util-6.1.21.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/jug-2.0.0.jar:bin/../lib/libthrift-r959516.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.5.8.jar:bin/../lib/slf4j-log4j12-1.5.8.jar:bin/../lib/snakeyaml-1.6.jar
org.apache.cassandra.thrift.CassandraDaemon
INFO 18:35:49,194 JNA not found. Native methods will be disabled.
INFO 18:35:49,299 DiskAccessMode 'auto' determined to be mmap,
indexAccessMode is mmap
INFO 18:35:49,403 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Statistics-e-1-<>
INFO 18:35:49,417 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Statistics-e-2-<>
INFO 18:35:49,432 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Schema-e-5-<>
INFO 18:35:49,437 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Migrations-e-5-<>
INFO 18:35:49,441 Sampling index for
/var/lib/cassandra/precious_roy/data/system/LocationInfo-e-1-<>
INFO 18:35:49,442 Sampling index for
/var/lib/cassandra/precious_roy/data/system/LocationInfo-e-2-<>
INFO 18:35:49,470 Loading schema version
29946d4a-afec-11df-ba37-e700f669bcfc
ERROR 18:35:49,636 Exception encountered during startup.
org.apache.avro.AvroTypeException: Found
{"type":"record","name":"CfDef","namespace":"org.apache.cassandra.config.avro","fields":[{"name":"keyspace","type":"string"},{"name":"name","type":"string"},{"name":"column_type","type":["string","null"]},{"name":"clock_type","type":["string","null"]},{"name":"comparator_type","type":["string","null"]},{"name":"subcomparator_type","type":["string","null"]},{"name":"reconciler","type":["string","null"]},{"name":"comment","type":["string","null"]},{"name":"row_cache_size","type":["double","null"]},{"name":"preload_row_cache","type":["boolean","null"]},{"name":"key_cache_size","type":["double","null"]},{"name":"read_repair_chance","type":["double","null"]},{"name":"gc_grace_seconds","type":["int","null"]},{"name":"column_metadata","type":[{"type":"array","items":{"type":"record","name":"ColumnDef","fields":[{"name":"name","type":"bytes"},{"name":"validation_class","type":"string"},{"name":"index_type","type":[{"type":"enum","name":"IndexType","symbols":["KEYS"]},"null"]},{"name":"index_name","type":["string","null"]}]}},"null"]},{"name":"id","type":["int","null"]}]},
expecting
{"type":"record","name":"CfDef","namespace":"org.apache.cassandra.config.avro","fields":[{"name":"keyspace","type":"string"},{"name":"name","type":"string"},{"name":"column_type","type":["string","null"]},{"name":"clock_type","type":["string","null"]},{"name":"comparator_type","type":["string","null"]},{"name":"subcomparator_type","type":["string","null"]},{"name":"reconciler","type":["string","null"]},{"name":"comment","type":["string","null"]},{"name":"row_cache_size","type":["double","null"]},{"name":"preload_row_cache","type":["boolean","null"]},{"name":"key_cache_size","type":["double","null"]},{"name":"read_repair_chance","type":["double","null"]},{"name":"gc_grace_seconds","type":["int","null"]},{"name":"default_validation_class","type":["string","null"]},{"name":"id","type":["int","null"]},{"name":"column_metadata","type":[{"type":"array","items":{"type":"record","name":"ColumnDef","fields":[{"name":"name","type":"bytes"},{"name":"validation_class","type":"string"},{"name":"index_type","type":[{"type":"enum","name":"IndexType","symbols":["KEYS"]},"null"]},{"name":"index_name","type":["string","null"]}]}},"null"]}]}
at
org.apache.avro.io.ResolvingDecoder.doAction(Re
Re: launch failure with current git (svn?)
Thanks, will try that
On 8/25/2010 7:33 PM, Jonathan Ellis wrote:
maybe adding the new default validator is breaking it?
https://issues.apache.org/jira/browse/CASSANDRA-891 in which case
blowing away system keyspace and re-initializing your schema should
fix it
adding new optional fields isn't supposed to break avro serialization tho :(
On Wed, Aug 25, 2010 at 8:39 PM, Chip Salzenberg wrote:
I was using svn cassandra from about a week ago, and it worked for me; but
then I updated to today's and got the below error after rebuild.
Help, please: Should I apply some known config file change, or just revert,
or ?
The version failing is
https://svn.apache.org/repos/asf/cassandra/tr...@989392
PS: I'm working on Perl client code, so this really is a dev@ question. :-)
+ exec /usr/bin/java -ea -XX:+UseThreadPriorities
-XX:ThreadPriorityPolicy=42 -Xms2G -Xmx2G -XX:+HeapDumpOnOutOfMemoryError
-Xss128k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=80
-Dcom.sun.management.jmxremote.port=8089
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dlog4j.configuration=log4j-server.properties -Dcassandra-foreground=yes -cp
/home/chip/cassandra/conf:bin/../build/classes:bin/../lib/antlr-3.1.3.jar:bin/../lib/avro-1.4.0-sources~r986959.jar:bin/../lib/avro-1.4.0~r986959.jar:bin/../lib/clhm-production.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-collections-3.2.1.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/guava-r05.jar:bin/../lib/hadoop-core-0.20.1.jar:bin/../lib/high-scale-lib.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jetty-6.1.21.jar:bin/../lib/jetty-util-6.1.21.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/jug-2.0.0.jar:bin/../lib/libthrift-r959516.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.5.8.jar:bin/../lib/slf4j-log4j12-1.5.8.jar:bin/../lib/snakeyaml-1.6.jar
org.apache.cassandra.thrift.CassandraDaemon
INFO 18:35:49,194 JNA not found. Native methods will be disabled.
INFO 18:35:49,299 DiskAccessMode 'auto' determined to be mmap,
indexAccessMode is mmap
INFO 18:35:49,403 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Statistics-e-1-<>
INFO 18:35:49,417 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Statistics-e-2-<>
INFO 18:35:49,432 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Schema-e-5-<>
INFO 18:35:49,437 Sampling index for
/var/lib/cassandra/precious_roy/data/system/Migrations-e-5-<>
INFO 18:35:49,441 Sampling index for
/var/lib/cassandra/precious_roy/data/system/LocationInfo-e-1-<>
INFO 18:35:49,442 Sampling index for
/var/lib/cassandra/precious_roy/data/system/LocationInfo-e-2-<>
INFO 18:35:49,470 Loading schema version
29946d4a-afec-11df-ba37-e700f669bcfc
ERROR 18:35:49,636 Exception encountered during startup.
org.apache.avro.AvroTypeException: Found
{"type":"record","name":"CfDef","namespace":"org.apache.cassandra.config.avro","fields":[{"name":"keyspace","type":"string"},{"name":"name","type":"string"},{"name":"column_type","type":["string","null"]},{"name":"clock_type","type":["string","null"]},{"name":"comparator_type","type":["string","null"]},{"name":"subcomparator_type","type":["string","null"]},{"name":"reconciler","type":["string","null"]},{"name":"comment","type":["string","null"]},{"name":"row_cache_size","type":["double","null"]},{"name":"preload_row_cache","type":["boolean","null"]},{"name":"key_cache_size","type":["double","null"]},{"name":"read_repair_chance","type":["double","null"]},{"name":"gc_grace_seconds","type":["int","null"]},{"name":"column_metadata","type":[{"type":"array","items":{"type":"record","name":"ColumnDef","fields":[{"name":"name","type":"bytes"},{"name":"validation_class","type":"string"},{"name":"index_type","type":[{&quo
0.7.0beta2 with 128G memory = bizarre tiny files. help?
I recently tested 0.7.0beta2 with good results on a reasonably powerful
machine: 8 Xeon cores (16 if you count hyperthreads), 64G memory, and
some nice HP RAID. So far so good. But when I took the same config and
moved it to a basically identical box with 128G of memory, cassandra
started responding to writes by creating a plethora of teeny tiny
sstables -- something it had not done before. For example:
INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,881 Memtable.java (line
150) Writing memtable-standa...@950886315(651 bytes, 18 operations)
INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,882 ColumnFamilyStore.java
(line 459) switching in a fresh Memtable for Standard1 at
CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
position=27598)
INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,883 ColumnFamilyStore.java
(line 771) Enqueuing flush of memtable-standa...@1383310803(384 bytes,
10 operations)
INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,902 Memtable.java (line
157) Completed flushing
/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db
INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,903 Memtable.java (line
150) Writing memtable-standa...@996627145(360 bytes, 10 operations)
INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java
(line 459) switching in a fresh Memtable for Standard1 at
CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
position=31446)
INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java
(line 771) Enqueuing flush of memtable-standa...@1909350010(957 bytes,
26 operations)
INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,932 Memtable.java (line
157) Completed flushing
/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-8-Data.db
INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,933 Memtable.java (line
150) Writing memtable-standa...@1383310803(384 bytes, 10 operations)
INFO [CompactionExecutor:1] 2010-10-27 01:53:27,934
CompactionManager.java (line 233) Compacting
[org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-5-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-6-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-8-Data.db')]
INFO [MUTATION_STAGE:17] 2010-10-27 01:53:27,936 ColumnFamilyStore.java
(line 459) switching in a fresh Memtable for Standard1 at
CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
position=33074)
INFO [MUTATION_STAGE:17] 2010-10-27 01:53:27,936 ColumnFamilyStore.java
(line 771) Enqueuing flush of memtable-standa...@595066677(396 bytes, 11
operations)
INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:28,037 Memtable.java (line
157) Completed flushing
/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-9-Data.db
I tried lowering the available memory reported by bin/cassandra:
system_memory_in_mb=`free -m | awk '/Mem:/ {print $2}'`
[ "$system_memory_in_mb" -gt 65536 ] &&
system_memory_in_mb=65536 # new
Didn't help. I also tried maually setting the max memtable sizes:
binary_memtable_throughput_in_mb: 512
memtable_throughput_in_mb: 4096
Didn't help.
Help?
Re: 0.7.0beta2 with 128G memory = bizarre tiny files. help?
I should add that the disk free space also changed, so the data
directory had a lot more space available than before:
/dev/cciss/c0d1 2.8T 202M 2.6T 1% /var/lib/cassandra/data
On 10/27/2010 2:17 AM, Chip Salzenberg wrote:
> I recently tested 0.7.0beta2 with good results on a reasonably powerful
> machine: 8 Xeon cores (16 if you count hyperthreads), 64G memory, and
> some nice HP RAID. So far so good. But when I took the same config and
> moved it to a basically identical box with 128G of memory, cassandra
> started responding to writes by creating a plethora of teeny tiny
> sstables -- something it had not done before. For example:
>
> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,881 Memtable.java (line
> 150) Writing memtable-standa...@950886315(651 bytes, 18 operations)
> INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,882 ColumnFamilyStore.java
> (line 459) switching in a fresh Memtable for Standard1 at
> CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
> position=27598)
> INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,883 ColumnFamilyStore.java
> (line 771) Enqueuing flush of memtable-standa...@1383310803(384 bytes,
> 10 operations)
> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,902 Memtable.java (line
> 157) Completed flushing
> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db
> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,903 Memtable.java (line
> 150) Writing memtable-standa...@996627145(360 bytes, 10 operations)
> INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java
> (line 459) switching in a fresh Memtable for Standard1 at
> CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
> position=31446)
> INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java
> (line 771) Enqueuing flush of memtable-standa...@1909350010(957 bytes,
> 26 operations)
> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,932 Memtable.java (line
> 157) Completed flushing
> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-8-Data.db
> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,933 Memtable.java (line
> 150) Writing memtable-standa...@1383310803(384 bytes, 10 operations)
> INFO [CompactionExecutor:1] 2010-10-27 01:53:27,934
> CompactionManager.java (line 233) Compacting
> [org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-5-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-6-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-8-Data.db')]
> INFO [MUTATION_STAGE:17] 2010-10-27 01:53:27,936 ColumnFamilyStore.java
> (line 459) switching in a fresh Memtable for Standard1 at
> CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
> position=33074)
> INFO [MUTATION_STAGE:17] 2010-10-27 01:53:27,936 ColumnFamilyStore.java
> (line 771) Enqueuing flush of memtable-standa...@595066677(396 bytes, 11
> operations)
> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:28,037 Memtable.java (line
> 157) Completed flushing
> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-9-Data.db
>
> I tried lowering the available memory reported by bin/cassandra:
>
> system_memory_in_mb=`free -m | awk '/Mem:/ {print $2}'`
> [ "$system_memory_in_mb" -gt 65536 ] &&
> system_memory_in_mb=65536 #<<<< new
>
> Didn't help. I also tried maually setting the max memtable sizes:
>
> binary_memtable_throughput_in_mb: 512
> memtable_throughput_in_mb: 4096
>
> Didn't help.
>
> Help?
>
Re: 0.7.0beta2 with 128G memory = bizarre tiny files. help?
Are these values available in JMX? If so, which ones are they? I'd
prefer not to possibly destroy the evidence by upgrading.
On 10/27/2010 6:50 AM, Jonathan Ellis wrote:
> Connect with the cli and run "show keyspaces." It sounds like
> Cassandra somehow picked ludicrously low memtable thresholds. There
> will be a line like
>
> Memtable thresholds: 0.2953125/63/60
>
> This may not be in the b2 cli, in which case you will need to upgrade
> to the nightly from
> http://hudson.zones.apache.org/hudson/job/Cassandra/lastSuccessfulBuild/artifact/cassandra/build/
> (essentially the same as rc1 being voted on).
>
> On Wed, Oct 27, 2010 at 4:17 AM, Chip Salzenberg wrote:
>> I recently tested 0.7.0beta2 with good results on a reasonably powerful
>> machine: 8 Xeon cores (16 if you count hyperthreads), 64G memory, and
>> some nice HP RAID. So far so good. But when I took the same config and
>> moved it to a basically identical box with 128G of memory, cassandra
>> started responding to writes by creating a plethora of teeny tiny
>> sstables -- something it had not done before. For example:
>>
>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,881 Memtable.java (line
>> 150) Writing memtable-standa...@950886315(651 bytes, 18 operations)
>> INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,882 ColumnFamilyStore.java
>> (line 459) switching in a fresh Memtable for Standard1 at
>> CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
>> position=27598)
>> INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,883 ColumnFamilyStore.java
>> (line 771) Enqueuing flush of memtable-standa...@1383310803(384 bytes,
>> 10 operations)
>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,902 Memtable.java (line
>> 157) Completed flushing
>> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db
>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,903 Memtable.java (line
>> 150) Writing memtable-standa...@996627145(360 bytes, 10 operations)
>> INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java
>> (line 459) switching in a fresh Memtable for Standard1 at
>> CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
>> position=31446)
>> INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java
>> (line 771) Enqueuing flush of memtable-standa...@1909350010(957 bytes,
>> 26 operations)
>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,932 Memtable.java (line
>> 157) Completed flushing
>> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-8-Data.db
>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,933 Memtable.java (line
>> 150) Writing memtable-standa...@1383310803(384 bytes, 10 operations)
>> INFO [CompactionExecutor:1] 2010-10-27 01:53:27,934
>> CompactionManager.java (line 233) Compacting
>> [org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-5-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-6-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-8-Data.db')]
>> INFO [MUTATION_STAGE:17] 2010-10-27 01:53:27,936 ColumnFamilyStore.java
>> (line 459) switching in a fresh Memtable for Standard1 at
>> CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log',
>> position=33074)
>> INFO [MUTATION_STAGE:17] 2010-10-27 01:53:27,936 ColumnFamilyStore.java
>> (line 771) Enqueuing flush of memtable-standa...@595066677(396 bytes, 11
>> operations)
>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:28,037 Memtable.java (line
>> 157) Completed flushing
>> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-9-Data.db
>>
>> I tried lowering the available memory reported by bin/cassandra:
>>
>>system_memory_in_mb=`free -m | awk '/Mem:/ {print $2}'`
>>[ "$system_memory_in_mb" -gt 65536 ] &&
>> system_memory_in_mb=65536 #<<<< new
>>
>> Didn't help. I also tried maually setting the max memtable sizes:
>>
>>binary_memtable_throughput_in_mb: 512
>>memtable_throughput_in_mb: 4096
>>
>> Didn't help.
>>
>> Help?
>>
>
>
0.7.0beta2 spinning/wedged after aggressive overnight writing
I set 60 clients to aggressively inserting into a 0.7.0beta2 standard keyspace overnight. This morning, its heap usage is maxed, it's using 400% CPU (which is a lot less than the box has, so that's OK), and it's making progress very... very... slowly. The timestamps near the end the commit logs tell the tale. Help? PS: This is not the 128G machine - this is the 72G machine, and it seemed to work great until 3:40am. INFO [CompactionExecutor:1] 2010-10-27 03:34:31,717 CompactionManager.java (line 305) Compacted to /var/lib/cassandra/data/_chip/Keyspace1/Standard1-tmp-e-155-Data.db. 5,582,588,196 to 5,511,562,149 (~98% of original) bytes for 26,781,501 keys. Time: 916,298ms. INFO [CompactionExecutor:1] 2010-10-27 03:34:31,717 CompactionManager.java (line 233) Compacting [org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-140-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-145-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-150-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-155-Data.db')] INFO [COMMIT-LOG-WRITER] 2010-10-27 03:34:41,359 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288175681359.log INFO [COMMIT-LOG-WRITER] 2010-10-27 03:35:11,025 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288175711025.log INFO [COMMIT-LOG-WRITER] 2010-10-27 03:35:39,775 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288175739775.log INFO [COMMIT-LOG-WRITER] 2010-10-27 03:36:11,619 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288175771619.log INFO [COMMIT-LOG-WRITER] 2010-10-27 03:36:42,251 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288175802251.log INFO [COMMIT-LOG-WRITER] 2010-10-27 03:37:14,466 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288175834466.log INFO [SSTABLE-CLEANUP-TIMER] 2010-10-27 03:37:25,543 SSTable.java (line 145) Deleted /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-153-<> INFO [SSTABLE-CLEANUP-TIMER] 2010-10-27 03:37:26,063 SSTable.java (line 145) Deleted /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-152-<> INFO [SSTABLE-CLEANUP-TIMER] 2010-10-27 03:37:26,679 SSTable.java (line 145) Deleted /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-151-<> INFO [SSTABLE-CLEANUP-TIMER] 2010-10-27 03:37:27,161 SSTable.java (line 145) Deleted /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-154-<> INFO [COMMIT-LOG-WRITER] 2010-10-27 03:37:46,653 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288175866653.log INFO [COMMIT-LOG-WRITER] 2010-10-27 03:40:34,537 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288176034537.log INFO [MUTATION_STAGE:30] 2010-10-27 03:40:36,793 ColumnFamilyStore.java (line 459) switching in a fresh Memtable for Standard1 at CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288176034537.log', position=9607864) INFO [MUTATION_STAGE:30] 2010-10-27 03:40:36,794 ColumnFamilyStore.java (line 771) Enqueuing flush of memtable-standa...@222641915(460325998 bytes, 13109777 operations) INFO [FLUSH-WRITER-POOL:1] 2010-10-27 03:40:36,794 Memtable.java (line 150) Writing memtable-standa...@222641915(460325998 bytes, 13109777 operations) INFO [COMMIT-LOG-WRITER] 2010-10-27 03:41:00,029 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288176060029.log INFO [COMMIT-LOG-WRITER] 2010-10-27 03:43:45,757 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288176225757.log INFO [COMMIT-LOG-WRITER] 2010-10-27 03:46:48,020 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288176408020.log INFO [COMMIT-LOG-WRITER] 2010-10-27 05:01:39,861 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288180899828.log INFO [COMMIT-LOG-WRITER] 2010-10-27 08:01:27,466 CommitLogSegment.java (line 50) Creating new commitlog segment /var/lib/cassandra/commitlog/_chip/CommitLog-1288191687466.log -rw-r--r-- 1 chip 134217796 2010-10-27 03:36 CommitLog-1288175739775.log -rw-r--r-- 1 chip 134217796 2010-10-27 03:36 CommitLog-1288175771619.log -rw-r--r-- 1 chip28 2010-10-27 03:36 CommitLog-1288175802251.log.header -rw-r--r-- 1 chip 134217796 2010-10-27 03:37 CommitLog-1288175802251.log -rw-r--r-
Re: 0.7.0beta2 with 128G memory = bizarre tiny files. help?
OK, after upgrading to "apache-cassandra-2010-10-27_12-30-38", here's what "show keyspaces" says about the relevant keyspace: ColumnFamily: Standard1 Columns sorted by: org.apache.cassandra.db.marshal.BytesType Row cache size / save period: 0.0/0 Key cache size / save period: 20.0/3600 Memtable thresholds: 9.590625/2046/60 GC grace seconds: 864000 Compaction min/max thresholds: 4/32 I created it with "schematool import" off of the stock config in b2. On 10/27/2010 11:36 AM, Jonathan Ellis wrote: > Not in b2. > On Oct 27, 2010 11:08 AM, "Chip Salzenberg" wrote: >> Are these values available in JMX? If so, which ones are they? I'd >> prefer not to possibly destroy the evidence by upgrading. >> >> On 10/27/2010 6:50 AM, Jonathan Ellis wrote: >>> Connect with the cli and run "show keyspaces." It sounds like >>> Cassandra somehow picked ludicrously low memtable thresholds. There >>> will be a line like >>> >>> Memtable thresholds: 0.2953125/63/60 >>> >>> This may not be in the b2 cli, in which case you will need to upgrade >>> to the nightly from >>> > http://hudson.zones.apache.org/hudson/job/Cassandra/lastSuccessfulBuild/artifact/cassandra/build/ >>> (essentially the same as rc1 being voted on). >>> >>> On Wed, Oct 27, 2010 at 4:17 AM, Chip Salzenberg wrote: >>>> I recently tested 0.7.0beta2 with good results on a reasonably powerful >>>> machine: 8 Xeon cores (16 if you count hyperthreads), 64G memory, and >>>> some nice HP RAID. So far so good. But when I took the same config and >>>> moved it to a basically identical box with 128G of memory, cassandra >>>> started responding to writes by creating a plethora of teeny tiny >>>> sstables -- something it had not done before. For example: >>>> >>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,881 Memtable.java (line >>>> 150) Writing memtable-standa...@950886315(651 bytes, 18 operations) >>>> INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,882 ColumnFamilyStore.java >>>> (line 459) switching in a fresh Memtable for Standard1 at >>>> > CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log', >>>> position=27598) >>>> INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,883 ColumnFamilyStore.java >>>> (line 771) Enqueuing flush of memtable-standa...@1383310803(384 bytes, >>>> 10 operations) >>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,902 Memtable.java (line >>>> 157) Completed flushing >>>> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db >>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,903 Memtable.java (line >>>> 150) Writing memtable-standa...@996627145(360 bytes, 10 operations) >>>> INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java >>>> (line 459) switching in a fresh Memtable for Standard1 at >>>> > CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log', >>>> position=31446) >>>> INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java >>>> (line 771) Enqueuing flush of memtable-standa...@1909350010(957 bytes, >>>> 26 operations) >>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,932 Memtable.java (line >>>> 157) Completed flushing >>>> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-8-Data.db >>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,933 Memtable.java (line >>>> 150) Writing memtable-standa...@1383310803(384 bytes, 10 operations) >>>> INFO [CompactionExecutor:1] 2010-10-27 01:53:27,934 >>>> CompactionManager.java (line 233) Compacting >>>> > [org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-5-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-6-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db'),org.apache.cassandra.io.sstable.SSTableReader(path='/var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-8-Data.db')] >>>> INFO [MUTATION_STAGE:17] 2010-10-27 01:53:27,936 ColumnFamilyStore.java >>>> (line 459) switching in a fresh Memtable for Standard1 at >>>> > CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log', >>>> p
Re: 0.7.0beta2 with 128G memory = bizarre tiny files. help?
That's what you're looking at. Sorry for the confusion. I left all the files in place for the upgrade. What I meant was that back when b2 was running, "import" was how I had created Standard1 in the first place. On 10/27/2010 1:54 PM, Jonathan Ellis wrote: > Sorry, I should have been more clear: rc1 is upgrade-in-place > compatible with b2, so I would have liked to see what the settings > were before running it through an export/import cycle. > > These settings look fine and I doubt you will see bizarre tiny files. > > On Wed, Oct 27, 2010 at 2:52 PM, Chip Salzenberg wrote: >> OK, after upgrading to "apache-cassandra-2010-10-27_12-30-38", here's >> what "show keyspaces" says about the relevant keyspace: >> >>ColumnFamily: Standard1 >> Columns sorted by: org.apache.cassandra.db.marshal.BytesType >> Row cache size / save period: 0.0/0 >> Key cache size / save period: 20.0/3600 >> Memtable thresholds: 9.590625/2046/60 >> GC grace seconds: 864000 >> Compaction min/max thresholds: 4/32 >> >> I created it with "schematool import" off of the stock config in b2. >> >> >> On 10/27/2010 11:36 AM, Jonathan Ellis wrote: >>> Not in b2. >>> On Oct 27, 2010 11:08 AM, "Chip Salzenberg" wrote: >>>> Are these values available in JMX? If so, which ones are they? I'd >>>> prefer not to possibly destroy the evidence by upgrading. >>>> >>>> On 10/27/2010 6:50 AM, Jonathan Ellis wrote: >>>>> Connect with the cli and run "show keyspaces." It sounds like >>>>> Cassandra somehow picked ludicrously low memtable thresholds. There >>>>> will be a line like >>>>> >>>>> Memtable thresholds: 0.2953125/63/60 >>>>> >>>>> This may not be in the b2 cli, in which case you will need to upgrade >>>>> to the nightly from >>>>> >>> http://hudson.zones.apache.org/hudson/job/Cassandra/lastSuccessfulBuild/artifact/cassandra/build/ >>>>> (essentially the same as rc1 being voted on). >>>>> >>>>> On Wed, Oct 27, 2010 at 4:17 AM, Chip Salzenberg wrote: >>>>>> I recently tested 0.7.0beta2 with good results on a reasonably powerful >>>>>> machine: 8 Xeon cores (16 if you count hyperthreads), 64G memory, and >>>>>> some nice HP RAID. So far so good. But when I took the same config and >>>>>> moved it to a basically identical box with 128G of memory, cassandra >>>>>> started responding to writes by creating a plethora of teeny tiny >>>>>> sstables -- something it had not done before. For example: >>>>>> >>>>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,881 Memtable.java (line >>>>>> 150) Writing memtable-standa...@950886315(651 bytes, 18 operations) >>>>>> INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,882 ColumnFamilyStore.java >>>>>> (line 459) switching in a fresh Memtable for Standard1 at >>>>>> >>> CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log', >>>>>> position=27598) >>>>>> INFO [MUTATION_STAGE:8] 2010-10-27 01:53:27,883 ColumnFamilyStore.java >>>>>> (line 771) Enqueuing flush of memtable-standa...@1383310803(384 bytes, >>>>>> 10 operations) >>>>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,902 Memtable.java (line >>>>>> 157) Completed flushing >>>>>> /var/lib/cassandra/data/_chip/Keyspace1/Standard1-e-7-Data.db >>>>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,903 Memtable.java (line >>>>>> 150) Writing memtable-standa...@996627145(360 bytes, 10 operations) >>>>>> INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java >>>>>> (line 459) switching in a fresh Memtable for Standard1 at >>>>>> >>> CommitLogContext(file='/var/lib/cassandra/commitlog/_chip/CommitLog-1288169534132.log', >>>>>> position=31446) >>>>>> INFO [MUTATION_STAGE:3] 2010-10-27 01:53:27,927 ColumnFamilyStore.java >>>>>> (line 771) Enqueuing flush of memtable-standa...@1909350010(957 bytes, >>>>>> 26 operations) >>>>>> INFO [FLUSH-WRITER-POOL:1] 2010-10-27 01:53:27,932 Memtable.java (line >>>>>> 157) Completed flushing >>>>>> /var/lib/cassandra/data/_c
Re: 0.7.0beta2 with 128G memory = bizarre tiny files. help?
Since I had to upgrade, I have to fix my Perl client to match the new thrift interface. It'll be later today. Then I can retry. On 10/27/2010 2:09 PM, Jonathan Ellis wrote: > Thanks for the clarification. > > Are you still seeing the tiny files? > > On Wed, Oct 27, 2010 at 4:02 PM, Chip Salzenberg wrote: >> That's what you're looking at. Sorry for the confusion. I left all the >> files in place for the upgrade. What I meant was that back when b2 was >> running, "import" was how I had created Standard1 in the first place. >> >> On 10/27/2010 1:54 PM, Jonathan Ellis wrote: >>> Sorry, I should have been more clear: rc1 is upgrade-in-place >>> compatible with b2, so I would have liked to see what the settings >>> were before running it through an export/import cycle. >>> >>> These settings look fine and I doubt you will see bizarre tiny files. >>> >>> On Wed, Oct 27, 2010 at 2:52 PM, Chip Salzenberg wrote: >>>> OK, after upgrading to "apache-cassandra-2010-10-27_12-30-38", here's >>>> what "show keyspaces" says about the relevant keyspace: >>>> >>>>ColumnFamily: Standard1 >>>> Columns sorted by: org.apache.cassandra.db.marshal.BytesType >>>> Row cache size / save period: 0.0/0 >>>> Key cache size / save period: 20.0/3600 >>>> Memtable thresholds: 9.590625/2046/60 >>>> GC grace seconds: 864000 >>>> Compaction min/max thresholds: 4/32 >>>> >>>> I created it with "schematool import" off of the stock config in b2.
Re: NoSQL, YesCQL?
Short answer: "YES Please, but we will still want a side channel for
minimum overhead."
Long answer: Query languages only work reliably when you have data
binding assistance (insert "Bobby Tables" xkcd here). However, they do
have the wonderful property of evolving aggressively without requiring
upgrades of the driver plumbing. This is, of course, emphatically *not*
true of anything like the current Thrift and Avro interfaces. So that's
why I say "Yes." On the other hand, a very simple interface for very
simple queries has a lot of value, too; see, for example,
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html
So that's why I think we will still want to bypass the full language for
minimum latency in some circumstances.
On 10/28/2010 1:40 PM, Eric Evans wrote:
> I don't know about everyone else, but I've been pretty dissatisfied with
> our API situation for some time.
>
> I used to be of the opinion that The Problem was Thrift and The Answer
> was Avro. I do still prefer Avro over Thrift as dependencies go, but
> I've come to the conclusion that the real problem has more to do with
> the object-oriented RPC pattern that both share in common.
>
> I used to think this was a necessary burden in order to expose the full
> power of our query API in a client agnostic manner, and that it was the
> job of third-party libraries to wrap this layer to create stable
> idiomatic interfaces.
>
> And, I used to think a vibrant ecosystem of these idiomatic libraries
> would emerge, but it hasn't. Truth is we've seen quite a bit of
> proliferation, and very little critical mass.
>
> This shouldn't be construed as criticism levied against library
> maintainers, on the contrary, I think they've done an amazing job all
> things considered. But in my opinion, our RPC interfaces push way too
> many implementation details client-side, making them brittle and
> unstable. This results in unnecessarily complex libraries that are
> forced to move in lock-step with Cassandra releases, that are never
> backward compatible, and which are consistently broken during our
> development cycle. I think we can provide client maintainers and users
> with a better experience than this.
>
> One solution to this is to implement a server-side query language, with
> simple language drivers that manage all of the common functionality in a
> consistent way (statement preparation, connection pooling, etc).
> Library maintainers would then build their idiomatic interfaces on top
> of these, (and I imagine, remove a metric crap-ton of code in the
> process).
>
> To this end I've been playing with exactly that. I have enough to do
> simple reads and writes, and I have stubbed out drivers for Java and
> Python. I'm seeking community feedback to gauge interest, and to
> satisfy the much needed desire to bike-shed. :)
>
> http://github.com/eevans/cassandra/tree/CQL
>
> You need to be sure you're checking out the "CQL" branch.
>
> This is implemented in the Avro interface so you'll need to pass the -a
> flag when launching the daemon.
>
> It is far from complete, and is surely quite buggy at this stage, take
> it as a preview or demonstration; it's meant to be a starting point for
> discussion.
>
> There is a bit of documentation on the syntax, you can see that here:
> http://github.com/eevans/cassandra/blob/CQL/doc/cql/CQL.textile
>
> There are some system tests in test/system/test_cql.py that should give
> you the basic idea, but assuming you have the Avro Python module
> installed you should be able to just...
>
> $ cd drivers/py
> $ python
import cql
conn = cql.Connection('Keyspace1', 'localhost', 9160)
conn.execute('UPDATE Standard1 WITH ROW("k", COL("c", "hello!"));')
print conn.execute('SELECT FROM Standard1 WHERE KEY = "k"')
> [{u'columns': [{u'timestamp': 1288297508761L, u'name': 'c', u'value':
> 'hello!', u'ttl': None}], u'key': 'k'}]
>
> I've been chewing on all of this for a while so I'm brimming with ideas,
> but I'll let the dust settle on this email before going any further. :)
>
> Thoughts?
>
>
>
> P.S. Dear Cliff Moon, I apologize. You were right.
>
Re: NoSQL, YesCQL?
On 10/28/2010 2:56 PM, Eric Evans wrote: > On Thu, 2010-10-28 at 14:46 -0700, Chip Salzenberg wrote: >> Short answer: "YES Please, but we will still want a side channel for >> minimum overhead." > Ok. Though I'm not sure I agree with the "minimum overhead" argument. > > I've only done preliminary tests so far, but this seems on par (if not a > little faster) than Thrift is, and no effort to optimize has been made > (using a socket transport instead of HTTP for example would make a big > difference). I didn't mean to imply that Thrift is fast enough. (Hehe, that would be funny.) Rather, I meant to suggest that any parsed language will inevitably be slower than a direct API for simple queries, so we should also provide such a simple API. If the question is, can the language completely and effectively replace Thrift for Cassandra, the answer is Yes. AFAICT, anyway. >> Long answer: Query languages only work reliably when you have data >> binding assistance (insert "Bobby Tables" xkcd here). However, they >> do >> have the wonderful property of evolving aggressively without requiring >> upgrades of the driver plumbing. This is, of course, emphatically >> *not* >> true of anything like the current Thrift and Avro interfaces. So >> that's >> why I say "Yes." On the other hand, a very simple interface for very >> simple queries has a lot of value, too; see, for example, >> http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html >> >> So that's why I think we will still want to bypass the full language >> for minimum latency in some circumstances. > I'm also not sure I follow here either. Do you mean simple for the > application developer? CQL-using code should be considerably simpler > than the equivalent Thrift/Avro. I'm not concerned about application-coding complexity problems with a language, only about performance in the lowest of low-latency use cases. > Thanks for the feedback! >
Re: NoSQL, YesCQL?
On 10/29/2010 7:13 AM, Ted Zlatanov wrote: > On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg wrote: > > CS> Short answer: "YES Please, but we will still want a side channel for > CS> minimum overhead." > > 100% agreed on both counts. But IIRC the fastest side channel is to > become a Cassandra node. Is that an option? If it were written in C or Perl, maybe. In Java, no.
Re: [VOTE] 0.7.0 beta3
On 11/1/2010 6:01 AM, Eric Evans wrote: > On Thu, 2010-10-28 at 10:55 -0500, Eric Evans wrote: >> The RC1 vote[1] was vetoed due to, (among other things), the desire to >> see more testing after the somewhat disruptive changes made in >> CASSANDRA-1367[2]. Thus, I propose the follow artifacts for release as >> beta3. >> >> SVN: >> https://svn.apache.org/repos/asf/cassandra/branches/cassandra-...@r1028349 >> 0.7.0-beta3 artifacts: http://people.apache.org/~eevans >> >> The vote will be open for the usual 72 hours. > I have 4 binding +1s and one other, and no -1s; the vote passes. I'll > get the artifacts published. I appreciate your creating a debian package before the vote, but now that the vote's passed I don't see it on the project downloads page. Shirley, I can't be the only one who wants a .deb. ?
