Re: problem with bootstrap

[Patrik Modesto]

On Fri, Mar 11, 2011 at 22:31, Aaron Morton  wrote:
> The assertion is interesting. Can you reproduce it with logging at debug and 
> post the results? Could you try to reproduce it with a clean cluster?

It was on a clean cluster last time. Anyway I started clean cluster
again, repeated the same steps with DEBUG enabled. This is the part of
log when the AssertionError happend:

DEBUG 08:32:50,513 reading RangeSliceCommand{keyspace='Context',
column_family='Url', super_column=null,
predicate=SlicePredicate(slice_range:SliceRange(start:80 01 00 01 00
00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 07
0C 00 01 0B 00 03 00 00 00 03 55 72 6C 00 0C 00 02 0C 00 02 0B 00 01
00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65
5F 73 6C 69 63 65 73 00 00 00 07 0C 00 01 0B 00 03 00 00 00 03 55 72
6C 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00,
reversed:false, count:2147483647)),
range=(4839275280018186837186594882659755,53884050462475230985987955197486389848],
max_keys=100} from /10.0.18.99
DEBUG 08:32:50,513 reading RangeSliceCommand{keyspace='Context',
column_family='Url', super_column=null,
predicate=SlicePredicate(slice_range:SliceRange(start:80 01 00 01 00
00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 07
0C 00 01 0B 00 03 00 00 00 03 55 72 6C 00 0C 00 02 0C 00 02 0B 00 01
00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65
5F 73 6C 69 63 65 73 00 00 00 07 0C 00 01 0B 00 03 00 00 00 03 55 72
6C 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00,
reversed:false, count:2147483647)),
range=(4839275280018186837186594882659755,53884050462475230985987955197486389848],
max_keys=100} from /10.0.18.129
DEBUG 08:32:50,515 Processing response on a callback from 159@/10.0.18.99
DEBUG 08:32:50,515 Processing response on a callback from 160@/10.0.18.129
ERROR 08:32:50,518 Fatal exception in thread
Thread[RequestResponseStage:3,5,main]
java.lang.AssertionError
at 
org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

It happens on every node I run the request on, the others report
nothing on that particular request.

HTH,
P.

secondary indexes on data imported by json2sstable

[Terje Marthinussen]

Hi,

Should it be expected that secondary indexes are automatically regenerated
when importing data using json2sstable?
Or is there some manual procedure that needs to be done to generate them?

Regards,
Terje

Re: secondary indexes on data imported by json2sstable

[Norman Maurer]

I would expect they get created on the fly while importing. If not I think
its a bug...

Bye,
Norman


2011/3/14 Terje Marthinussen 

> Hi,
>
> Should it be expected that secondary indexes are automatically regenerated
> when importing data using json2sstable?
> Or is there some manual procedure that needs to be done to generate them?
>
> Regards,
> Terje
>

Re: Double ColumnType and comparing

[Eric Charles]

Or maybe convert double to long, just as hector's DoubleSerializer does
https://github.com/rantav/hector/blob/master/core/src/main/java/me/prettyprint/cassandra/serializers/DoubleSerializer.java
I was happy to  use it here.
Tks,
- Eric

On 14/03/2011 02:52, aaron morton wrote:

There is nothing in the 0.8 trunk to add double support.

Could you shift the decimal point and use ints / longs ? Double is not a 
precise type, so there is a possibility of the value changing as it's 
serialised and deserialised around.

You were on the right track with extending abstract type. You would also need 
to work out a precise binary representation for the numbers.

Hope that helps.
Aaron
On 14 Mar 2011, at 13:36, Paul Teasdale wrote:


I am quite new to Cassandra and am trying to model a simple Column Family which 
uses Doubles as column names:

Datalines: { // ColumnFamilly
dataline-1:{ // row key
23.5: 'someValue',
23.6: 'someValue',
...
4334.99: 'someValue'
},
dataline-2:{
10.5: 'someValue',
12.6: 'someValue',
...
23334.99: 'someValue'
},
...
dataline-n:{
10.5: 'someValue',
12.6: 'someValue',
...
23334.99: 'someValue'
   }
}

In declaring this column family, I need to specify a 'CompareWith' attribute 
for a Double type, but the only available values I found for this attribute are:

  * BytesType
  * AsciiType
  * UTF8Type
  * LongType
  * LexicalUUIDType
  * TimeUUIDType

Is there any support anywere for double values (there has to be something)? And if 
not, does this mean we need to extend  
org.apache.cassandra.db.marshal.AbstractType?

package  com.mycom.types;

class  DoubleType extends org.apache.cassandra.db.marshal.AbstractType  
{
  public int compare(ByteBuffer o1, ByteBuffer o2){
// trivial implementation
Double d1  = o1.getDouble(0);
   Double d2 = o2.getDoube(0);
   return d1.compareTo(d2);
  } 
  //...
}

And declare the column family:



Thanks,
Paul

Re: On 0.6.6 to 0.7.3 migration, DC-aware traffic and minimising data transfer

[Chris Burroughs]

On 03/11/2011 03:46 PM, Jonathan Ellis wrote:
> Repairs is not yet WAN-optimized but is still cheap if your replicas
> are close to consistent since only merkle trees + inconsistent ranges
> are sent over the network.
> 

What is the ticket number for WAN optimized repair?

Conflict resolution in Cassandra

[Milind Parikh]

https://docs.google.com/document/d/13Yc2t4d07290TdiRmSTchuAk9sbp4BeqOpqeYhbcDFM/edit?hl=en

There was an excellent session on vector clocks and synchronous writes in
cassandra. Here are my gleanings out of it.

/***
sent from my android...please pardon occasional typos as I respond @ the
speed of thought
/

Re: secondary indexes on data imported by json2sstable

[Jonathan Ellis]

You'd need to drop and recreate the index (but see
https://issues.apache.org/jira/browse/CASSANDRA-2320 when doing this).

On Mon, Mar 14, 2011 at 6:07 AM, Terje Marthinussen
 wrote:
> Hi,
> Should it be expected that secondary indexes are automatically regenerated
> when importing data using json2sstable?
> Or is there some manual procedure that needs to be done to generate them?
> Regards,
> Terje



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: Double ColumnType and comparing

[Jonathan Ellis]

We'd be happy to commit a patch contributing a DoubleType.

On Sun, Mar 13, 2011 at 7:36 PM, Paul Teasdale  wrote:
> I am quite new to Cassandra and am trying to model a simple Column Family
> which uses Doubles as column names:
> Datalines: { // ColumnFamilly
> dataline-1:{ // row key
> 23.5: 'someValue',
> 23.6: 'someValue',
> ...
>                4334.99: 'someValue'
> },
> dataline-2:{
> 10.5: 'someValue',
> 12.6: 'someValue',
> ...
>                23334.99: 'someValue'
> },
> ...
> dataline-n:{
> 10.5: 'someValue',
> 12.6: 'someValue',
> ...
>                23334.99: 'someValue'
>           }
> }
> In declaring this column family, I need to specify a 'CompareWith' attribute
> for a Double type, but the only available values I found for this attribute
> are:
>  * BytesType
>  * AsciiType
>  * UTF8Type
>  * LongType
>  * LexicalUUIDType
>  * TimeUUIDType
> Is there any support anywere for double values (there has to be something)?
> And if not, does this mean we need to extend
>  org.apache.cassandra.db.marshal.AbstractType?
> package  com.mycom.types;
> class  DoubleType extends
> org.apache.cassandra.db.marshal.AbstractType {
>      public int compare(ByteBuffer o1, ByteBuffer o2){
>        // trivial implementation
>            Double d1  = o1.getDouble(0);
>   Double d2 = o2.getDoube(0);
>   return d1.compareTo(d2);
>      }
>      //...
> }
> And declare the column family:
> 
> Thanks,
> Paul
>
>
>
>
>
>
>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: Double ColumnType and comparing

[David Boxenhorn]

I you do it, I'd recommend BigDecimal. It's an exact type, and usually what
you want.

On Mon, Mar 14, 2011 at 3:40 PM, Jonathan Ellis  wrote:

> We'd be happy to commit a patch contributing a DoubleType.
>
> On Sun, Mar 13, 2011 at 7:36 PM, Paul Teasdale 
> wrote:
> > I am quite new to Cassandra and am trying to model a simple Column Family
> > which uses Doubles as column names:
> > Datalines: { // ColumnFamilly
> > dataline-1:{ // row key
> > 23.5: 'someValue',
> > 23.6: 'someValue',
> > ...
> >4334.99: 'someValue'
> > },
> > dataline-2:{
> > 10.5: 'someValue',
> > 12.6: 'someValue',
> > ...
> >23334.99: 'someValue'
> > },
> > ...
> > dataline-n:{
> > 10.5: 'someValue',
> > 12.6: 'someValue',
> > ...
> >23334.99: 'someValue'
> >   }
> > }
> > In declaring this column family, I need to specify a 'CompareWith'
> attribute
> > for a Double type, but the only available values I found for this
> attribute
> > are:
> >  * BytesType
> >  * AsciiType
> >  * UTF8Type
> >  * LongType
> >  * LexicalUUIDType
> >  * TimeUUIDType
> > Is there any support anywere for double values (there has to be
> something)?
> > And if not, does this mean we need to extend
> >  org.apache.cassandra.db.marshal.AbstractType?
> > package  com.mycom.types;
> > class  DoubleType extends
> > org.apache.cassandra.db.marshal.AbstractType {
> >  public int compare(ByteBuffer o1, ByteBuffer o2){
> >// trivial implementation
> >Double d1  = o1.getDouble(0);
> >   Double d2 = o2.getDoube(0);
> >   return d1.compareTo(d2);
> >  }
> >  //...
> > }
> > And declare the column family:
> >  Name="Datalines"/>
> > Thanks,
> > Paul
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
>

Re: reducing disk usage advice

[Sylvain Lebresne]

On Sun, Mar 13, 2011 at 7:10 PM, Karl Hiramoto  wrote:
>
> Hi,
>
> I'm looking for advice on reducing disk usage.   I've ran out of disk space 
> two days in a row while running a  nightly scheduled nodetool repair && 
> nodetool compact  cronjob.
>
> I have 6 nodes RF=3  each with 300 GB drives at a hosting company.   
> GCGraceSeconds = 26 (3.1 days)
>
> Every column in the database has a TTL of 86400 (24 hours)   to handle 
> deletion of stale data.   50% of the time the data is only written once, read 
> 0 or many times then expires. The other 50% of the time it's written multiple 
> times, resetting the TTL to 24 hours each time.

As it turns out, the compaction algorithm is pretty much the worst
possible for this use case. Because we compact files that have a
similar size, the older a column gets, the less often it is compacted.
If you always set a fixed TTL for all columns, you would want to do
some compaction of recent sstable, for the sake of not having too many
sstables, but you also want to compact old sstable, that are
guaranteed to just go away. And for those, it's actually fine to
compact them alone (only for the sake of purging).
But as compaction works, you will end up with big sstables of stuffs
that are expired, and you may even not be able to compact simply
because compaction "thinks" it doesn't have enough room.

But I do think that your use case (having a CF where are columns have
the same TTL and you only rely on it for deletion) is a very useful
one, and we should handle it better. In particular, CASSANDRA-1610
could be an easy way to get this.

CASSANDRA-1537 is probably also a partial but possibly sufficient
solution. That's also probably easier than CASSANDRA-1610 and I'll try
to give it a shot asap, that had been on my todo list way too long.

> One question,  since I use a TTL is it safe to set GCGraceSeconds  to 0?   I 
> don't manually delete ever, I just rely on the TTL for deletion, so are 
> forgotten deletes an issue?

The rule is this. Say you think that m is a reasonable value for
GCGraceSeconds. That is, you make sure that you'll always put back up
failing nodes and run repair within m seconds. Then, if you always use
a TTL of n (in your case 24 hours), the actual GCGraceSeconds that you
should set is m - n.

So putting a GCGrace of 0 in you would would be roughly equivalent to
set a GCGrace of 24h on a "normal" CF. That's probably a bit low.

--
Sylvain


>
>
>
> cfstats:
>  Read Count: 32052
>     Read Latency: 3.1280378135529765 ms.
>     Write Count: 9704525
>     Write Latency: 0.009527474760485443 ms.
>     Pending Tasks: 0
>     Column Family: Offer
>     SSTable count: 12
>     Space used (live): 59865089091
>     Space used (total): 76111577830
>     Memtable Columns Count: 39355
>     Memtable Data Size: 14726313
>     Memtable Switch Count: 414
>     Read Count: 32052
>     Read Latency: 3.128 ms.
>     Write Count: 9704525
>     Write Latency: 0.010 ms.
>     Pending Tasks: 0
>     Key cache capacity: 1000
>     Key cache size: 1000
>     Key cache hit rate: 2.4805931214280473E-4
>     Row cache: disabled
>     Compacted row minimum size: 36
>     Compacted row maximum size: 1597
>     Compacted row mean size: 1319
>

Map-Reduce on top of cassandra

[Or Yanay]

Hi All,

I am trying to write some map-reduce tasks so I can find out stuff like - how 
many records have X status?
I am using 0.7.0 and have 5 nodes with ~100G of data on each node.

I have written the code based on the word_count example and the map-reduce is 
running successfully BUT is extremely slow (about 2 hours for the simplest key 
count).

I am now looking to track down the slowness and tune my process, or explore 
alternative ways to achieve the same goal.

Can anyone point me to a way to tune my map-reduce job?
Does anyone have any experience exploring Cassandra data with Hadoop cluster 
configuration? ( As suggested in 
http://wiki.apache.org/cassandra/HadoopSupport#ClusterConfig)

Thanks,
Orr

problems while TimeUUIDType-index-querying with two expressions

[Johannes Hoerle]

Hi all,

in order to improve our queries, we started to use IndexedSliceQueries from the 
hector project (https://github.com/zznate/hector-examples). I followed the 
instructions for creating IndexedSlicesQuery with GetIndexedSlices.java.
I created the corresponding CF with in a keyspace called "Keyspace1" ( "create 
keyspace  Keyspace1;") with:
"create column family Indexed1 with column_type='Standard' and 
comparator='UTF8Type' and keys_cached=20 and read_repair_chance=1.0 and 
rows_cached=2 and column_metadata=[{column_name: birthdate, 
validation_class: LongType, index_name: dateIndex, index_type: 
KEYS},{column_name: birthmonth, validation_class: LongType, index_name: 
monthIndex, index_type: KEYS}];"
and the example GetIndexedSlices.java worked fine.

Output of CF Indexed1:
---
[default@Keyspace1] list Indexed1;
Using default limit of 100
---
RowKey: fake_key_12
=> (column=birthdate, value=1974, timestamp=1300110485826059)
=> (column=birthmonth, value=0, timestamp=1300110485826060)
=> (column=fake_column_0, value=66616b655f76616c75655f305f3132, 
timestamp=1300110485826056)
=> (column=fake_column_1, value=66616b655f76616c75655f315f3132, 
timestamp=1300110485826057)
=> (column=fake_column_2, value=66616b655f76616c75655f325f3132, 
timestamp=1300110485826058)
---
RowKey: fake_key_8
=> (column=birthdate, value=1974, timestamp=1300110485826039)
=> (column=birthmonth, value=8, timestamp=1300110485826040)
=> (column=fake_column_0, value=66616b655f76616c75655f305f38, 
timestamp=1300110485826036)
=> (column=fake_column_1, value=66616b655f76616c75655f315f38, 
timestamp=1300110485826037)
=> (column=fake_column_2, value=66616b655f76616c75655f325f38, 
timestamp=1300110485826038)
---



Now to the problem:
As we have another column format in our cluster (using TimeUUIDType as 
comparator in CF definition) I adapted the application to our schema on a 
cassandra-0.7.3 cluster.
We use a manually defined UUID for a mandator id index 
(--1000--) and another one for a userid index 
(0001--1000--). It can be created with:
"create column family ByUser with column_type='Standard' and 
comparator='TimeUUIDType' and keys_cached=20 and read_repair_chance=1.0 and 
rows_cached=2 and column_metadata=[{column_name: 
--1000--, validation_class: BytesType, index_name: 
mandatorIndex, index_type: KEYS}, {column_name: 
0001--1000--, validation_class: BytesType, index_name: 
useridIndex, index_type: KEYS}];"


which looks in the cluster using cassandra-cli like this:

[default@Keyspace1] describe keyspace;
Keyspace: Keyspace1:
  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Replication Factor: 1
  Column Families:
ColumnFamily: ByUser
  Columns sorted by: org.apache.cassandra.db.marshal.TimeUUIDType
  Row cache size / save period: 2.0/0
  Key cache size / save period: 20.0/14400
  Memtable thresholds: 0.2953125/63/1440
  GC grace seconds: 864000
  Compaction min/max thresholds: 4/32
  Read repair chance: 0.01
  Built indexes: [ByUser.mandatorIndex, ByUser.useridIndex]
  Column Metadata:
Column Name: 0001--1000--
  Validation Class: org.apache.cassandra.db.marshal.BytesType
  Index Name: useridIndex
  Index Type: KEYS
Column Name: --1000--
  Validation Class: org.apache.cassandra.db.marshal.BytesType
  Index Name: mandatorIndex
  Index Type: KEYS
ColumnFamily: Indexed1
  Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
  Row cache size / save period: 2.0/0
  Key cache size / save period: 20.0/14400
  Memtable thresholds: 0.2953125/63/1440
  GC grace seconds: 864000
  Compaction min/max thresholds: 4/32
  Read repair chance: 0.01
  Built indexes: [Indexed1.dateIndex, Indexed1.monthIndex]
  Column Metadata:
Column Name: birthmonth (birthmonth)
  Validation Class: org.apache.cassandra.db.marshal.LongType
  Index Name: monthIndex
  Index Type: KEYS
Column Name: birthdate (birthdate)
  Validation Class: org.apache.cassandra.db.marshal.LongType
  Index Name: dateIndex
  Index Type: KEYS
[default@Keyspace1] list ByUser;
Using default limit of 100
---
RowKey: testMandator!!user01
=> (column=--1000--, 
value=746573744d616e6461746f72, timestamp=1300111213321000)
=> (column=0001--1000--, value=757365723031, 
timestamp=1300111213322000)
=> (column=f064b480-495e-11e0-abc4-0024e89fa587, value=3135, 
timestamp=1300111213561000)

1 Row Returned.

the values of the index colums --1000-- and 
0001--1000-- represent "testMandato

Out of Memory every 2 weeks

[Jean-Yves LEBLEU]

Sorry to create a new thread about Out of Memory problem, but I
checked all other threads and did not find the answer.

We have a running cluster of 2 cassandra nodes replication factor = 2
on red hat 4.8 32 bits with 4 G of memory  where we run periodicaly
out of memory (every 2 weeks)  and both nodes are crashing (trace at
the end of the file).

We are running 0.6.12 (do not had the time to upgrade to 0.7.3) and we
followed the memory configuration from the wiki :

memtable_throughput_in_mb * 3 * number of hot CFs + 1G + internal caches

memtable_throughput_in_mb = 16
We have 11 column families

So if my calculation is right, I need  16*3*11 + 1G + internal caches
: 528 Mbytes + 1G + internal caches, so more than 1,5 G of heap memory

We start with 2G

Here is the cassandra.in.sh parameters

JVM_OPTS=" \
-ea \
-Xms2000M \
-Xmx2000M \
-XX:+UseParNewGC \
-XX:+UseConcMarkSweepGC \
-XX:+CMSParallelRemarkEnabled \
-XX:SurvivorRatio=8 \
-XX:MaxTenuringThreshold=1 \
-XX:CMSInitiatingOccupancyFraction=75 \
-XX:+UseCMSInitiatingOccupancyOnly \
-XX:+HeapDumpOnOutOfMemoryError \


The question is I don't really understand the configuration problem,
if some body have any clue of what we could do, or what we should
monitor to avoid the problem, as it is very difficult to reproduce the
problem as it does not happen very often.

Thanks for any help.
Jean-Yves


<-below the stack trace
-->


INFO [FLUSH-WRITER-POOL:1] 2011-03-04 17:59:45,952 Memtable.java (line 152)
Writing Memtable-HintsColumnFamily@15830055(2280 bytes, 240 operations)
 INFO [FLUSH-WRITER-POOL:1] 2011-03-04 17:59:45,972 Memtable.java (line 166)
Completed flushing
/opt/database/data/system/HintsColumnFamily-164-Data.db (255 bytes)
 INFO [FLUSH-TIMER] 2011-03-04 18:17:47,802 ColumnFamilyStore.java (line 478)
VoiceMail has reached its threshold; switching in a fresh Memtable at
CommitLogContext(file='/opt/database/commitlog/CommitLog-1297775500410.log',
position=10407973)
 INFO [FLUSH-TIMER] 2011-03-04 18:17:47,803 ColumnFamilyStore.java (line 748)
Enqueuing flush of Memtable-VoiceMail@29468188(3000 bytes, 120 operations)
 INFO [FLUSH-WRITER-POOL:1] 2011-03-04 18:17:47,803 Memtable.java (line 152)
Writing Memtable-VoiceMail@29468188(3000 bytes, 120 operations)
ERROR [FLUSH-WRITER-POOL:1] 2011-03-04 18:17:47,824 CassandraDaemon.java (line
87) Uncaught exception in thread Thread[FLUSH-WRITER-POOL:1,5,main]
java.lang.OutOfMemoryError
at java.io.RandomAccessFile.readBytes(Native Method)
at java.io.RandomAccessFile.read(RandomAccessFile.java:322)
at
org.apache.cassandra.io.util.BufferedRandomAccessFile.fillBuffer(BufferedRandomAccessFile.java:209)
at
org.apache.cassandra.io.util.BufferedRandomAccessFile.seek(BufferedRandomAccessFile.java:246)
at
org.apache.cassandra.io.util.BufferedRandomAccessFile.writeAtMost(BufferedRandomAccessFile.java:389)
at
org.apache.cassandra.io.util.BufferedRandomAccessFile.write(BufferedRandomAccessFile.java:365)
at java.io.DataOutputStream.writeUTF(DataOutputStream.java:384)
at java.io.RandomAccessFile.writeUTF(RandomAccessFile.java:1064)
at org.apache.cassandra.io.SSTableWriter.append(SSTableWriter.java:94)
at
org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:162)
at org.apache.cassandra.db.Memtable.access$000(Memtable.java:46)
at org.apache.cassandra.db.Memtable$1.runMayThrow(Memtable.java:178)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
 INFO [main] 2011-03-07 17:46:09,454 CLibrary.java (line 47) JNA not found.
Native methods will be disabled.
 INFO [main] 2011-03-07 17:46:09,768 DatabaseDescriptor.java (line 277)
DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard

Re: Map-Reduce on top of cassandra

[Jeremy Hanna]

Can you go into the #cassandra channel and ask your question?  See if 
jeromatron or driftx are around.  That way there can be a back and forth about 
settings and things.

http://webchat.freenode.net/?channels=#cassandra

On Mar 14, 2011, at 10:06 AM, Or Yanay wrote:

> Hi All,
>  
> I am trying to write some map-reduce tasks so I can find out stuff like – how 
> many records have X status?
> I am using 0.7.0 and have 5 nodes with ~100G of data on each node.
>  
> I have written the code based on the word_count example and the map-reduce is 
> running successfully BUT is extremely slow (about 2 hours for the simplest 
> key count).
>  
> I am now looking to track down the slowness and tune my process, or explore 
> alternative ways to achieve the same goal.
>  
> Can anyone point me to a way to tune my map-reduce job?
> Does anyone have any experience exploring Cassandra data with Hadoop cluster 
> configuration? ( As suggested 
> inhttp://wiki.apache.org/cassandra/HadoopSupport#ClusterConfig)
>  
> Thanks,
> Orr
>  

Re: On 0.6.6 to 0.7.3 migration, DC-aware traffic and minimising data transfer

[Jedd Rashbrooke]

 Jonathon, thank you for your answers here.

 To explain this bit ...

On 11 March 2011 20:46, Jonathan Ellis  wrote:
> On Thu, Mar 10, 2011 at 6:06 AM, Jedd Rashbrooke  wrote:
>>  Copying a cluster between AWS DC's:
>>  We have ~ 150-250GB per node, with a Replication Factor of 4.
>>  I ack that 0.6 -> 0.7 is necessarily STW, so in an attempt to
>>  minimise that outage period I was wondering if it's possible to
>>  drain & stop the cluster, then copy over only the 1st, 5th, 9th,
>>  and 13th nodes' worth of data (which should be a full copy of
>>  all our actual data - we are nicely partitioned, despite the
>>  disparity in GB per node) and have Cassandra re-populate the
>>  new destination 16 nodes from those four data sets.  If this is
>>  feasible, is it likely to be more expensive (in terms of time the
>>  new cluster is unresponsive as it rebuilds) than just copying
>>  across all 16 sets of data - about 2.7TB.
>
> I'm confused.  You're trying to upgrade and add a DC at the same time?

 Yeah, I know, it's probably not the sanest route - but the hardware
 (virtualised, Amazonish EC2 that it is) will be the same between
 the two sites, so that reduces some of the usual roll in / roll out
 migration risk.

 But more importantly for us it would mean we'd have just the
 one major outage, rather than two (relocation and 0.6 -> 0.7)

 cheers,
 Jedd.

Re: Out of Memory every 2 weeks

[Robert Coli]

On Mon, Mar 14, 2011 at 8:27 AM, Jean-Yves LEBLEU  wrote:
> Sorry to create a new thread about Out of Memory problem, but I
> checked all other threads and did not find the answer.
> [...]
> The question is I don't really understand the configuration problem,
> if some body have any clue of what we could do, or what we should
> monitor to avoid the problem, as it is very difficult to reproduce the
> problem as it does not happen very often.

a) Estimate approximately how long it takes your nodes to begin to be
memory starved.
b) Wait until they are in this state, but still usable. There is
usually a "pre-fail" state where the node is just "performing very
badly" but JMX is still available.
c) "nodetool -h localhost cfstats > /tmp/my.node.with.low.free.heap.txt"
d) examine output of c) to determine which row caches and key caches
to reduce in size, in that order of priority.
e) repeat until a) no longer happens.

If you graph heap usage together with CPU usage, it will probably be
easier for you to determine when you are in state b), or are about to
be.

=Rob

Re: Out of Memory every 2 weeks

[Jean-Yves LEBLEU]

Thank you,
I am going to try that.

Fron scribe to cassandra

[salidu andrea]

Hi all,

On the wiki pages i read an example (wirtten in java) to store data
from scribe. I tried to

write the same code in php without success. there is someone here who
tried to do the same?

tks in advanced

javasilk

Re: On 0.6.6 to 0.7.3 migration, DC-aware traffic and minimising data transfer

[Robert Coli]

On Mon, Mar 14, 2011 at 8:39 AM, Jedd Rashbrooke  wrote:
>  But more importantly for us it would mean we'd have just the
>  one major outage, rather than two (relocation and 0.6 -> 0.7)

Take zero major outages instead? :D

a) Set up new cluster on new version.
b) Fork application writes, so all writes go to both clusters.
c) Backfill old data to new cluster via API writes.
d) Flip the switch to read from the new cluster.
e) Turn off old cluster.

=Rob

Re: On 0.6.6 to 0.7.3 migration, DC-aware traffic and minimising data transfer

[David Boxenhorn]

How do you write to two versions of Cassandra from the same client? Two
versions of Hector?

On Mon, Mar 14, 2011 at 6:46 PM, Robert Coli  wrote:

> On Mon, Mar 14, 2011 at 8:39 AM, Jedd Rashbrooke 
> wrote:
> >  But more importantly for us it would mean we'd have just the
> >  one major outage, rather than two (relocation and 0.6 -> 0.7)
>
> Take zero major outages instead? :D
>
> a) Set up new cluster on new version.
> b) Fork application writes, so all writes go to both clusters.
> c) Backfill old data to new cluster via API writes.
> d) Flip the switch to read from the new cluster.
> e) Turn off old cluster.
>
> =Rob
>

Re: Seed

[mcasandra]

Tyler Hobbs-2 wrote:
> 
> Seeds:
> Never use a node's own address as a seed if you are bootstrapping it by
> setting autobootstrap to true! 
> 

I came accross this on the wiki. Can someone please help me understand this
with some example?

--
View this message in context: 
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Seed-tp6162837p6169871.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive at 
Nabble.com.

Re: Double ColumnType and comparing

[Norman Maurer]

I will have a look at what it takes to implement it..

Bye,
Norman


2011/3/14 David Boxenhorn 

> I you do it, I'd recommend BigDecimal. It's an exact type, and usually what
> you want.
>
> On Mon, Mar 14, 2011 at 3:40 PM, Jonathan Ellis  wrote:
>
>> We'd be happy to commit a patch contributing a DoubleType.
>>
>> On Sun, Mar 13, 2011 at 7:36 PM, Paul Teasdale 
>> wrote:
>> > I am quite new to Cassandra and am trying to model a simple Column
>> Family
>> > which uses Doubles as column names:
>> > Datalines: { // ColumnFamilly
>> > dataline-1:{ // row key
>> > 23.5: 'someValue',
>> > 23.6: 'someValue',
>> > ...
>> >4334.99: 'someValue'
>> > },
>> > dataline-2:{
>> > 10.5: 'someValue',
>> > 12.6: 'someValue',
>> > ...
>> >23334.99: 'someValue'
>> > },
>> > ...
>> > dataline-n:{
>> > 10.5: 'someValue',
>> > 12.6: 'someValue',
>> > ...
>> >23334.99: 'someValue'
>> >   }
>> > }
>> > In declaring this column family, I need to specify a 'CompareWith'
>> attribute
>> > for a Double type, but the only available values I found for this
>> attribute
>> > are:
>> >  * BytesType
>> >  * AsciiType
>> >  * UTF8Type
>> >  * LongType
>> >  * LexicalUUIDType
>> >  * TimeUUIDType
>> > Is there any support anywere for double values (there has to be
>> something)?
>> > And if not, does this mean we need to extend
>> >  org.apache.cassandra.db.marshal.AbstractType?
>> > package  com.mycom.types;
>> > class  DoubleType extends
>> > org.apache.cassandra.db.marshal.AbstractType {
>> >  public int compare(ByteBuffer o1, ByteBuffer o2){
>> >// trivial implementation
>> >Double d1  = o1.getDouble(0);
>> >   Double d2 = o2.getDoube(0);
>> >   return d1.compareTo(d2);
>> >  }
>> >  //...
>> > }
>> > And declare the column family:
>> > > Name="Datalines"/>
>> > Thanks,
>> > Paul
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of DataStax, the source for professional Cassandra support
>> http://www.datastax.com
>>
>
>

Increase flush writer queue

[Daniel Doubleday]

Hi all,

on 0.6: 

we are facing increased write latencies every now and then when an unfortunate 
write command thread becomes the flush writer for a mem table because of an 
already running mem table flush.

I was thinking of setting the work queue in CFS.flushWriterPool to 

new LinkedBlockingQueue(3) // because 3 is my favorite number

instead of

new 
LinkedBlockingQueue(DatabaseDescriptor.getAllDataFileLocations().length)

while leaving the max threads at 1 (we have only one date dir)

I'm not afraid to OOM. We have enough heap to hold the extra 2 mem tables.

Anybody did this and got in trouble?

PS: I know that 0.7 makes this configurable (but also increases writer 
concurrency while I would rather only queue).

Thanks,
Daniel

Re: Map-Reduce on top of cassandra

[Jeremy Hanna]

Just for the sake of updating this thread - Orr didn't yet have task trackers 
on the Cassandra nodes so most of the time was likely due to copying the ~100G 
of data to the hadoop cluster prior to processing.  They're going to try after 
installing task trackers on the nodes.

On Mar 14, 2011, at 10:06 AM, Or Yanay wrote:

> Hi All,
>  
> I am trying to write some map-reduce tasks so I can find out stuff like – how 
> many records have X status?
> I am using 0.7.0 and have 5 nodes with ~100G of data on each node.
>  
> I have written the code based on the word_count example and the map-reduce is 
> running successfully BUT is extremely slow (about 2 hours for the simplest 
> key count).
>  
> I am now looking to track down the slowness and tune my process, or explore 
> alternative ways to achieve the same goal.
>  
> Can anyone point me to a way to tune my map-reduce job?
> Does anyone have any experience exploring Cassandra data with Hadoop cluster 
> configuration? ( As suggested 
> inhttp://wiki.apache.org/cassandra/HadoopSupport#ClusterConfig)
>  
> Thanks,
> Orr
>  

Linux HugePages and mmap

[mcasandra]

Currently, in cassandra.yaml disk_access_mode is set to "auto" but the
recommendation seems to be to use 'mmap_index_only'.

If we use HugePages then do we still need to worry about setting
disk_access_mode to mmap? I am planning to enable HugePages and use
-XX:+UseLargePages option in JVM. I had a very good experience using
HugePages with Oracle.


--
View this message in context: 
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Linux-HugePages-and-mmap-tp6170193p6170193.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive at 
Nabble.com.

Re: reducing disk usage advice

[Karl Hiramoto]

On 03/14/11 15:33, Sylvain Lebresne wrote:
>
> CASSANDRA-1537 is probably also a partial but possibly sufficient
> solution. That's also probably easier than CASSANDRA-1610 and I'll try
> to give it a shot asap, that had been on my todo list way too long.
>
Thanks, eager to see CASSANDRA-1610 someday.   What  I've been doing the
last day has been multiple restarts across the cluster when one node's
data/ dir gets to 150GB.  restarting cassandra brings the nodes data/
directory down to around 60GB, I see cassandra deleteing a lot of
SSTables on startup.


One question,  since I use a TTL is it safe to set GCGraceSeconds  to 0?   I 
don't manually delete ever, I just rely on the TTL for deletion, so are 
forgotten deletes an issue?


> The rule is this. Say you think that m is a reasonable value for
> GCGraceSeconds. That is, you make sure that you'll always put back up
> failing nodes and run repair within m seconds. Then, if you always use
> a TTL of n (in your case 24 hours), the actual GCGraceSeconds that you
> should set is m - n.
>
> So putting a GCGrace of 0 in you would would be roughly equivalent to
> set a GCGrace of 24h on a "normal" CF. That's probably a bit low.
>
What do you mean by "normal"?  If I were to set GCGrace to 0 would  risk
data corruption?  Wouldn't setting GCGrace to 0 help reduce disk space
pressure?


Thanks,
Karl

Re: Strange behaivour

[ruslan usifov]

I detect that this was after change schema and it hung on waitpid syscall.
What can i do with this?

Re: Increase flush writer queue

[Jonathan Ellis]

Sure, that should be fine.

On Mon, Mar 14, 2011 at 1:03 PM, Daniel Doubleday
 wrote:
> Hi all,
>
> on 0.6:
>
> we are facing increased write latencies every now and then when an 
> unfortunate write command thread becomes the flush writer for a mem table 
> because of an already running mem table flush.
>
> I was thinking of setting the work queue in CFS.flushWriterPool to
>
> new LinkedBlockingQueue(3) // because 3 is my favorite number
>
> instead of
>
> new 
> LinkedBlockingQueue(DatabaseDescriptor.getAllDataFileLocations().length)
>
> while leaving the max threads at 1 (we have only one date dir)
>
> I'm not afraid to OOM. We have enough heap to hold the extra 2 mem tables.
>
> Anybody did this and got in trouble?
>
> PS: I know that 0.7 makes this configurable (but also increases writer 
> concurrency while I would rather only queue).
>
> Thanks,
> Daniel



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: Linux HugePages and mmap

[Jonathan Ellis]

On Mon, Mar 14, 2011 at 1:59 PM, mcasandra  wrote:
> Currently, in cassandra.yaml disk_access_mode is set to "auto" but the
> recommendation seems to be to use 'mmap_index_only'.

Wrong.  The recommendation is to leave it on auto.

> If we use HugePages then do we still need to worry about setting
> disk_access_mode to mmap? I am planning to enable HugePages and use
> -XX:+UseLargePages option in JVM. I had a very good experience using
> HugePages with Oracle.

HugePages has nothing to do with disk access mode.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: Linux HugePages and mmap

[mcasandra]

Jonathan Ellis-3 wrote:
> 
> Wrong.  The recommendation is to leave it on auto.
> 
this is where I see mmap recommended for index. 
http://wiki.apache.org/cassandra/StorageConfiguration
http://wiki.apache.org/cassandra/StorageConfiguration 



Jonathan Ellis-3 wrote:
> 
> HugePages has nothing to do with disk access mode.
> 
Can you explain little more? Isn't mmap pinning the process memory in RAM
similar to HugePages?


--
View this message in context: 
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Linux-HugePages-and-mmap-tp6170193p6170423.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive at 
Nabble.com.

Re: Increase flush writer queue

[Brandon Williams]

On Mon, Mar 14, 2011 at 1:03 PM, Daniel Doubleday
wrote:

> I was thinking of setting the work queue in CFS.flushWriterPool to
>
> new LinkedBlockingQueue(3) // because 3 is my favorite number
>
> instead of
>
> new
> LinkedBlockingQueue(DatabaseDescriptor.getAllDataFileLocations().length)
>

Alternately, you could add two more data directories on the same mount point
to avoid having to float a patch and do a custom deployment.

-Brandon

calculating initial_token

[Sasha Dolgy]

Sorry for being a bit daft ... Wanted a bit of validation or rejection ...

If I have a 6 node cluster, replication factor 2 (don't think this is
applicable to the token decision) is the following sufficient and
correct for determining the tokens:

#!/bin/bash
for nodes in {0..5};
do
echo "$nodes*(2^127/5)" | bc;
done




Gives me a result of:

0
34028236692093846346337460743176821145
68056473384187692692674921486353642290
102084710076281539039012382229530463435
136112946768375385385349842972707284580
170141183460469231731687303715884105725

My ring right now is:


10.0.0.2  Up Normal  225 KB  40.78%
24053088190195663439419935163232881936
10.0.0.3Up Normal  201.21 KB   19.17%
56667357399723182105247119364967854254
10.0.0.4   Up Normal  213.15 KB   17.61%
86624712919272143003828971968762407027
10.0.0.5   Up Normal  214.54 KB   11.22%
105714724128406151241468359303513100912
10.0.0.6  Up Normal  206.39 KB   5.61%
115259729732973155360288052970888447854
10.0.0.7Up Normal  247.68 KB   5.61%
124804735337540159479107746638263794797

If my new tokens are correct:

1.  cassandra.yaml is updated on each node with new token
2.  node is restarted and a nodetool repair is run, or is a nodetool
loadbalance run

Thanks in advance ... been staring at
http://wiki.apache.org/cassandra/Operations#Token_selection for too
long

-- 
Sasha Dolgy
sasha.do...@gmail.com

Calculate memory used for keycache

[ruslan usifov]

Hello


How is it possible calculate this value? I think that key size, if we use
RandomPartitioner will 16 bytes so keycache will took 16*(num of keycache
elements) bytes ??

Re: Write speed roughly 1/10 of expected.

[Steven Liu]

Re: Mr. Schuller,

The test documents are very small (a few lines of text each). Test data
model is standard CF with each document correponding to a row containing
9-12 columns. We are using a single client for sequential batch_insert
(probably maps to batch mutate in phpcassa), so it is very possible that
that's the bottleneck.

Re: Mr. Hobbs,

Did you mean "which has the benefit of THRIFT-638, while 0.7.a.2 does not"
(instead of 0.7.a.3)? 0.7.a.3 was the latest version of phpcassa we could
find on github. We installed 0.7.a.3 with its C extension and didn't see an
improvement. Is there a newer version with THRIFT-638 fix?

Steve


On Fri, Mar 11, 2011 at 4:55 PM, Tyler Hobbs  wrote:

> (I have no idea how fast phpcassa is.)
>>
>
> The current master branch (which has the benefit of 
> THRIFT-638,
> while 0.7.a.3 does not) can insert about 3k individual rows a second against
> a local Cassandra instance.
>
> --
> Tyler Hobbs
> Software Engineer, DataStax 
> Maintainer of the pycassa  Cassandra
> Python client library
>
>

Re: Out of Memory every 2 weeks

[Peter Schuller]

> I am going to try that.

Also, you may want to augment your VM options with:

-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimestamps

That way there should hopefully be some corroborating evidence as to
the nature of the heap growth over time.

-- 
/ Peter Schuller

Re: Strange behaivour

[Peter Schuller]

Can you try a 'strace -fp PID' when it's in the state of spinning with
system CPU time? I'm wondering whether it's stuck in a single syscall
or just spinning around one or a set of syscalls.

I have very vague recollections of a discussion on the list a few
months ago about triggering a kernel bug that involved being stuck in
system cpu spin... but I may be mis-remembering.

--
/ Peter Schuller

Re: Calculate memory used for keycache

[Peter Schuller]

> How is it possible calculate this value? I think that key size, if we use
> RandomPartitioner will 16 bytes so keycache will took 16*(num of keycache
> elements) bytes ??

The easiest way right now is probably empirical testing. The issue is
that the "memory use" must include overhead associated with the data
structures involved, as well as longer-term effects like fragmentation
in old-space in the GC (similarly to malloc/free).

-- 
/ Peter Schuller

Re: Calculate memory used for keycache

[Narendra Sharma]

Sometime back I looked at the code to find that out. Following is the
result. There will be some additional overhead for internal DS for
ConcurrentLinkedHashMap.

 * (<8 bytes for position i.e. value> +  +
<16 bytes for token (RP)> + <8 byte reference for DecoratedKey> + <8 bytes
for descriptor reference>)

Thanks,
Naren

On Mon, Mar 14, 2011 at 1:29 PM, ruslan usifov wrote:

> Hello
>
>
> How is it possible calculate this value? I think that key size, if we use
> RandomPartitioner will 16 bytes so keycache will took 16*(num of keycache
> elements) bytes ??
>

Re: calculating initial_token

[Narendra Sharma]

On the same page there is a section on Load Balance that talks about python
script to compute tokens. I believe your question is more about assigning
new tokens and not compute tokens.

1. "nodetool loadbalance" will result in recomputation of tokens. It will
pick tokens based on the load and not the once assigned by you.
2. You can either use decommission and bootstrap with new tokens OR Use
"nodetool move"

Thanks,
Naren

On Mon, Mar 14, 2011 at 1:18 PM, Sasha Dolgy  wrote:

> Sorry for being a bit daft ... Wanted a bit of validation or rejection ...
>
> If I have a 6 node cluster, replication factor 2 (don't think this is
> applicable to the token decision) is the following sufficient and
> correct for determining the tokens:
>
> #!/bin/bash
> for nodes in {0..5};
> do
>echo "$nodes*(2^127/5)" | bc;
> done
>
>
>
>
> Gives me a result of:
>
> 0
> 34028236692093846346337460743176821145
> 68056473384187692692674921486353642290
> 102084710076281539039012382229530463435
> 136112946768375385385349842972707284580
> 170141183460469231731687303715884105725
>
> My ring right now is:
>
>
> 10.0.0.2  Up Normal  225 KB  40.78%
> 24053088190195663439419935163232881936
> 10.0.0.3Up Normal  201.21 KB   19.17%
> 56667357399723182105247119364967854254
> 10.0.0.4   Up Normal  213.15 KB   17.61%
> 86624712919272143003828971968762407027
> 10.0.0.5   Up Normal  214.54 KB   11.22%
> 105714724128406151241468359303513100912
> 10.0.0.6  Up Normal  206.39 KB   5.61%
> 115259729732973155360288052970888447854
> 10.0.0.7Up Normal  247.68 KB   5.61%
> 124804735337540159479107746638263794797
>
> If my new tokens are correct:
>
> 1.  cassandra.yaml is updated on each node with new token
> 2.  node is restarted and a nodetool repair is run, or is a nodetool
> loadbalance run
>
> Thanks in advance ... been staring at
> http://wiki.apache.org/cassandra/Operations#Token_selection for too
> long
>
> --
> Sasha Dolgy
> sasha.do...@gmail.com
>

Re: calculating initial_token

[Sasha Dolgy]

ah, you know ... i have been reading it wrong.  the output shows a
nice fancy column called "Owns" but i've only ever seen the percentage
... the amount of data or "load" is even ... doh.  thanks for the
reply.  cheers
-sd

On Mon, Mar 14, 2011 at 10:47 PM, Narendra Sharma
 wrote:
> On the same page there is a section on Load Balance that talks about python
> script to compute tokens. I believe your question is more about assigning
> new tokens and not compute tokens.
>
> 1. "nodetool loadbalance" will result in recomputation of tokens. It will
> pick tokens based on the load and not the once assigned by you.
> 2. You can either use decommission and bootstrap with new tokens OR Use
> "nodetool move"
>
> Thanks,
> Naren
>
> On Mon, Mar 14, 2011 at 1:18 PM, Sasha Dolgy  wrote:
>>
>> Sorry for being a bit daft ... Wanted a bit of validation or rejection ...
>>
>> If I have a 6 node cluster, replication factor 2 (don't think this is
>> applicable to the token decision) is the following sufficient and
>> correct for determining the tokens:
>>
>> #!/bin/bash
>> for nodes in {0..5};
>> do
>>    echo "$nodes*(2^127/5)" | bc;
>> done
>>
>>
>>
>>
>> Gives me a result of:
>>
>> 0
>> 34028236692093846346337460743176821145
>> 68056473384187692692674921486353642290
>> 102084710076281539039012382229530463435
>> 136112946768375385385349842972707284580
>> 170141183460469231731687303715884105725
>>
>> My ring right now is:
>>
>>
>> 10.0.0.2  Up     Normal  225 KB          40.78%
>> 24053088190195663439419935163232881936
>> 10.0.0.3    Up     Normal  201.21 KB       19.17%
>> 56667357399723182105247119364967854254
>> 10.0.0.4   Up     Normal  213.15 KB       17.61%
>> 86624712919272143003828971968762407027
>> 10.0.0.5   Up     Normal  214.54 KB       11.22%
>> 105714724128406151241468359303513100912
>> 10.0.0.6  Up     Normal  206.39 KB       5.61%
>> 115259729732973155360288052970888447854
>> 10.0.0.7    Up     Normal  247.68 KB       5.61%
>> 124804735337540159479107746638263794797
>>
>> If my new tokens are correct:
>>
>> 1.  cassandra.yaml is updated on each node with new token
>> 2.  node is restarted and a nodetool repair is run, or is a nodetool
>> loadbalance run
>>
>> Thanks in advance ... been staring at
>> http://wiki.apache.org/cassandra/Operations#Token_selection for too
>> long
>>
>> --
>> Sasha Dolgy
>> sasha.do...@gmail.com
>
>



-- 
Sasha Dolgy
sasha.do...@gmail.com

Re: Linux HugePages and mmap

[Jonathan Ellis]

On Mon, Mar 14, 2011 at 3:01 PM, mcasandra  wrote:
>
> Jonathan Ellis-3 wrote:
>>
>> Wrong.  The recommendation is to leave it on auto.
>>
> this is where I see mmap recommended for index.
> http://wiki.apache.org/cassandra/StorageConfiguration

FTFY.

>> HugePages has nothing to do with disk access mode.
>>
> Can you explain little more? Isn't mmap pinning the process memory in RAM
> similar to HugePages?

mmap is about mapping address space to data files.

HugePages affects how the kernel tracks address space via TLB.  It
does NOT affect what is actually mapped there.

http://wiki.apache.org/cassandra/FAQ#mmap
http://lwn.net/Articles/374424/

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: nodetool loadbalance

[Sasha Dolgy]

With my six node cluster ... nodetool loadbalance should be run on one
node or all six?  I run it on one and the ownership percentage gets
even more unbalanced.  So... in the spirit of the evening, I run it on
another node . as you see, the ownership % keeps increasing and
the token numbers keep increasing.  is this expected?  I would have
hoped that the behaviour would be a little bit different.  Maybe I've
missed something big



Address Status State   LoadOwnsToken

124804735337540159479107746638263794797
10.0.0.1  Up Normal  225 KB  40.78%
24053088190195663439419935163232881936
10.0.0.2Up Normal  201.21 KB   19.17%
56667357399723182105247119364967854254
10.0.0.3   Up Normal  213.15 KB   17.61%
86624712919272143003828971968762407027
10.0.0.4   Up Normal  214.54 KB   11.22%
105714724128406151241468359303513100912
10.0.0.5  Up Normal  206.39 KB   5.61%
115259729732973155360288052970888447854
10.0.0.6Up Normal  242.93 KB   5.61%
124804735337540159479107746638263794797


Address Status State   LoadOwnsToken

124804735337540159479107746638263794797
10.0.0.2Up Normal  206.15 KB   59.95%
56667357399723182105247119364967854254
10.0.0.3   Up Normal  218.1 KB17.61%
86624712919272143003828971968762407027
10.0.0.4   Up Normal  219.48 KB   11.22%
105714724128406151241468359303513100912
10.0.0.5  Up Normal  216.31 KB   5.61%
115259729732973155360288052970888447854
10.0.0.1  Up Normal  224.32 KB   2.81%
120032232535256657419697899804576121325
10.0.0.6Up Normal  242.93 KB   2.81%
124804735337540159479107746638263794797


Address Status State   LoadOwnsToken

124804735337540159479107746638263794797
10.0.0.3   Up Normal  218.1 KB77.56%
86624712919272143003828971968762407027
10.0.0.4   Up Normal  225.71 KB   11.22%
105714724128406151241468359303513100912
10.0.0.5  Up Normal  216.31 KB   5.61%
115259729732973155360288052970888447854
10.0.0.1  Up Normal  224.32 KB   2.81%
120032232535256657419697899804576121325
10.0.0.2Up Normal  201.21 KB   1.40%
122418483936398408449402823221419958061
10.0.0.6Up Normal  242.93 KB   1.40%
124804735337540159479107746638263794797

Address Status State   LoadOwnsToken

124804735337540159479107746638263794797
10.0.0.4   Up Normal  225.71 KB   88.78%
105714724128406151241468359303513100912
10.0.0.5  Up Normal  225.61 KB   5.61%
115259729732973155360288052970888447854
10.0.0.1  Up Normal  224.32 KB   2.81%
120032232535256657419697899804576121325
10.0.0.2Up Normal  201.21 KB   1.40%
122418483936398408449402823221419958061
10.0.0.3   Up Normal  218.13 KB   0.70%
123611609636969283964255284929841876429
10.0.0.6Up Normal  242.93 KB   0.70%
124804735337540159479107746638263794797


Address Status State   LoadOwnsToken

124804735337540159479107746638263794797
10.0.0.5  Up Leaving 225.61 KB   94.39%
115259729732973155360288052970888447854
10.0.0.1  Up Normal  214.39 KB   2.81%
120032232535256657419697899804576121325
10.0.0.2Up Normal  201.21 KB   1.40%
122418483936398408449402823221419958061
10.0.0.3   Up Normal  218.13 KB   0.70%
123611609636969283964255284929841876429
10.0.0.4   Up Normal  220.77 KB   0.35%
124208172487254721721681515784052835613
10.0.0.6Up Normal  248.08 KB   0.35%
124804735337540159479107746638263794797



124804735337540159479107746638263794797
10.0.0.1  Up Normal  214.39 KB   97.19%
120032232535256657419697899804576121325
10.0.0.2Up Normal  205.47 KB   1.40%
122418483936398408449402823221419958061
10.0.0.3   Up Normal  218.13 KB   0.70%
123611609636969283964255284929841876429
10.0.0.4   Up Normal  220.77 KB   0.35%
124208172487254721721681515784052835613
10.0.0.5  Up Normal  220.63 KB   0.18%
124506453912397440600394631211158315205
10.0.0.6Up Normal  248.08 KB   0.18%
124804735337540159479107746638263794797


97.19% ... awesome.


On Mon, Mar 14, 2011 at 10:47 PM, Narendra Sharma
 wrote:
> On the same page there is a section on Load Balance that talks about python
> script to compute tokens. I believe your question is more about assigning
> new tokens and not compute tokens.
>
> 1. "nodetool loadbalance" will result in recomputation of tokens. It will
> pick tokens based on the load and not the once assigned by you.
> 2. You can either use decommission and bootstrap with new tokens OR Use
> "nodetool move"
>
> Thanks,
> Naren

Re: Linux HugePages and mmap

[mcasandra]

Thanks! I think it still is a good idea to enable HiugePages and use
UseLargePageSize option in JVM. What do you think?

--
View this message in context: 
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Linux-HugePages-and-mmap-tp6170193p6171008.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive at 
Nabble.com.

Re: nodetool loadbalance

[Jonathan Ellis]

You should read http://wiki.apache.org/cassandra/Operations before
running loadbalance.

On Mon, Mar 14, 2011 at 5:27 PM, Sasha Dolgy  wrote:
> With my six node cluster ... nodetool loadbalance should be run on one
> node or all six?  I run it on one and the ownership percentage gets
> even more unbalanced.  So... in the spirit of the evening, I run it on
> another node . as you see, the ownership % keeps increasing and
> the token numbers keep increasing.  is this expected?  I would have
> hoped that the behaviour would be a little bit different.  Maybe I've
> missed something big
>
>
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.1  Up     Normal  225 KB          40.78%
> 24053088190195663439419935163232881936
> 10.0.0.2    Up     Normal  201.21 KB       19.17%
> 56667357399723182105247119364967854254
> 10.0.0.3   Up     Normal  213.15 KB       17.61%
> 86624712919272143003828971968762407027
> 10.0.0.4   Up     Normal  214.54 KB       11.22%
> 105714724128406151241468359303513100912
> 10.0.0.5  Up     Normal  206.39 KB       5.61%
> 115259729732973155360288052970888447854
> 10.0.0.6    Up     Normal  242.93 KB       5.61%
> 124804735337540159479107746638263794797
>
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.2    Up     Normal  206.15 KB       59.95%
> 56667357399723182105247119364967854254
> 10.0.0.3   Up     Normal  218.1 KB        17.61%
> 86624712919272143003828971968762407027
> 10.0.0.4   Up     Normal  219.48 KB       11.22%
> 105714724128406151241468359303513100912
> 10.0.0.5  Up     Normal  216.31 KB       5.61%
> 115259729732973155360288052970888447854
> 10.0.0.1  Up     Normal  224.32 KB       2.81%
> 120032232535256657419697899804576121325
> 10.0.0.6    Up     Normal  242.93 KB       2.81%
> 124804735337540159479107746638263794797
>
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.3   Up     Normal  218.1 KB        77.56%
> 86624712919272143003828971968762407027
> 10.0.0.4   Up     Normal  225.71 KB       11.22%
> 105714724128406151241468359303513100912
> 10.0.0.5  Up     Normal  216.31 KB       5.61%
> 115259729732973155360288052970888447854
> 10.0.0.1  Up     Normal  224.32 KB       2.81%
> 120032232535256657419697899804576121325
> 10.0.0.2    Up     Normal  201.21 KB       1.40%
> 122418483936398408449402823221419958061
> 10.0.0.6    Up     Normal  242.93 KB       1.40%
> 124804735337540159479107746638263794797
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.4   Up     Normal  225.71 KB       88.78%
> 105714724128406151241468359303513100912
> 10.0.0.5  Up     Normal  225.61 KB       5.61%
> 115259729732973155360288052970888447854
> 10.0.0.1  Up     Normal  224.32 KB       2.81%
> 120032232535256657419697899804576121325
> 10.0.0.2    Up     Normal  201.21 KB       1.40%
> 122418483936398408449402823221419958061
> 10.0.0.3   Up     Normal  218.13 KB       0.70%
> 123611609636969283964255284929841876429
> 10.0.0.6    Up     Normal  242.93 KB       0.70%
> 124804735337540159479107746638263794797
>
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.5  Up     Leaving 225.61 KB       94.39%
> 115259729732973155360288052970888447854
> 10.0.0.1  Up     Normal  214.39 KB       2.81%
> 120032232535256657419697899804576121325
> 10.0.0.2    Up     Normal  201.21 KB       1.40%
> 122418483936398408449402823221419958061
> 10.0.0.3   Up     Normal  218.13 KB       0.70%
> 123611609636969283964255284929841876429
> 10.0.0.4   Up     Normal  220.77 KB       0.35%
> 124208172487254721721681515784052835613
> 10.0.0.6    Up     Normal  248.08 KB       0.35%
> 124804735337540159479107746638263794797
>
>
>
> 124804735337540159479107746638263794797
> 10.0.0.1  Up     Normal  214.39 KB       97.19%
> 120032232535256657419697899804576121325
> 10.0.0.2    Up     Normal  205.47 KB       1.40%
> 122418483936398408449402823221419958061
> 10.0.0.3   Up     Normal  218.13 KB       0.70%
> 123611609636969283964255284929841876429
> 10.0.0.4   Up     Normal  220.77 KB       0.35%
> 124208172487254721721681515784052835613
> 10.0.0.5  Up     Normal  220.63 KB       0.18%
> 124506453912397440600394631211158315205
> 10.0.0.6    Up     Normal  248.08 KB       0.18%
> 124804735337540159479107746638263794797
>
>
> 97.19% ... awesome.
>
>
> On Mon, Mar 14, 2011 at 10:47 PM, Narendra Sharma
>  wrote:
>> On the same page there is a section on Load Balance that talks about python
>> script to compute tokens. I believe your question is more about assigning
>> new tokens and not compute tokens.
>>
>> 1. "nodetool loadbalance" will result in recomputation of tokens. It will
>> pick tokens based on the load and not the once assigned by you.
>> 2. You can either use decommission and bootst

Re: nodetool loadbalance

[Sasha Dolgy]

Using the tokens I generated earlier, i ran nodetool move 
on each node and things look much better for the Owns % ...


Address Status State   LoadOwnsToken

170141183460469231731687303715884105725
10.0.0.1  Up Normal  234.51 KB   0.00%   0
10.0.0.2Up Normal  224.13 KB   20.00%
34028236692093846346337460743176821145
10.0.0.3  Up Normal  238.3 KB40.00%
102084710076281539039012382229530463435
10.0.0.4   Up Normal  222.93 KB   12.65%
123611609636969283964255284929841876429
10.0.0.5   Up Normal  238.04 KB   7.35%
136112946768375385385349842972707284580
10.0.0.6Up Normal  235.92 KB   20.00%
170141183460469231731687303715884105725

All of these nodes had been brought online using auto_bootstrap, with
exception for the very first one, which was a seed for the rest.  Is
this a necessary task that has to be performed on all nodes as new
nodes are added ... to maintain a good balance ... in that the tokens
don't re-balance themselves?

Or, as this is a test environment with low load, there isn't enough
good data for the bootstrap to determine where best to put the new
node token?

-sd


On Mon, Mar 14, 2011 at 11:27 PM, Sasha Dolgy  wrote:
> With my six node cluster ... nodetool loadbalance should be run on one
> node or all six?  I run it on one and the ownership percentage gets
> even more unbalanced.  So... in the spirit of the evening, I run it on
> another node . as you see, the ownership % keeps increasing and
> the token numbers keep increasing.  is this expected?  I would have
> hoped that the behaviour would be a little bit different.  Maybe I've
> missed something big
>
>
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.1  Up     Normal  225 KB          40.78%
> 24053088190195663439419935163232881936
> 10.0.0.2    Up     Normal  201.21 KB       19.17%
> 56667357399723182105247119364967854254
> 10.0.0.3   Up     Normal  213.15 KB       17.61%
> 86624712919272143003828971968762407027
> 10.0.0.4   Up     Normal  214.54 KB       11.22%
> 105714724128406151241468359303513100912
> 10.0.0.5  Up     Normal  206.39 KB       5.61%
> 115259729732973155360288052970888447854
> 10.0.0.6    Up     Normal  242.93 KB       5.61%
> 124804735337540159479107746638263794797
>
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.2    Up     Normal  206.15 KB       59.95%
> 56667357399723182105247119364967854254
> 10.0.0.3   Up     Normal  218.1 KB        17.61%
> 86624712919272143003828971968762407027
> 10.0.0.4   Up     Normal  219.48 KB       11.22%
> 105714724128406151241468359303513100912
> 10.0.0.5  Up     Normal  216.31 KB       5.61%
> 115259729732973155360288052970888447854
> 10.0.0.1  Up     Normal  224.32 KB       2.81%
> 120032232535256657419697899804576121325
> 10.0.0.6    Up     Normal  242.93 KB       2.81%
> 124804735337540159479107746638263794797
>
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.3   Up     Normal  218.1 KB        77.56%
> 86624712919272143003828971968762407027
> 10.0.0.4   Up     Normal  225.71 KB       11.22%
> 105714724128406151241468359303513100912
> 10.0.0.5  Up     Normal  216.31 KB       5.61%
> 115259729732973155360288052970888447854
> 10.0.0.1  Up     Normal  224.32 KB       2.81%
> 120032232535256657419697899804576121325
> 10.0.0.2    Up     Normal  201.21 KB       1.40%
> 122418483936398408449402823221419958061
> 10.0.0.6    Up     Normal  242.93 KB       1.40%
> 124804735337540159479107746638263794797
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.4   Up     Normal  225.71 KB       88.78%
> 105714724128406151241468359303513100912
> 10.0.0.5  Up     Normal  225.61 KB       5.61%
> 115259729732973155360288052970888447854
> 10.0.0.1  Up     Normal  224.32 KB       2.81%
> 120032232535256657419697899804576121325
> 10.0.0.2    Up     Normal  201.21 KB       1.40%
> 122418483936398408449402823221419958061
> 10.0.0.3   Up     Normal  218.13 KB       0.70%
> 123611609636969283964255284929841876429
> 10.0.0.6    Up     Normal  242.93 KB       0.70%
> 124804735337540159479107746638263794797
>
>
> Address         Status State   Load            Owns    Token
>
> 124804735337540159479107746638263794797
> 10.0.0.5  Up     Leaving 225.61 KB       94.39%
> 115259729732973155360288052970888447854
> 10.0.0.1  Up     Normal  214.39 KB       2.81%
> 120032232535256657419697899804576121325
> 10.0.0.2    Up     Normal  201.21 KB       1.40%
> 122418483936398408449402823221419958061
> 10.0.0.3   Up     Normal  218.13 KB       0.70%
> 123611609636969283964255284929841876429
> 10.0.0.4   Up     Normal  220.77 KB       0.35%
> 124208172487254721721681515784052835613
> 10.0.0.6    Up     Normal  248.08 KB       0.35%
> 1248047353375401594791077466382

Re: nodetool loadbalance

[Sasha Dolgy]

Yes, a lot of what is on the wiki makes perfect sense when read the right
way.  suppose there arent enough pictures or before/after info online to
help the knowledge flow.
On Mar 14, 2011 11:52 PM, "Jonathan Ellis"  wrote:
> You should read http://wiki.apache.org/cassandra/Operations before
> running loadbalance.
>
> On Mon, Mar 14, 2011 at 5:27 PM, Sasha Dolgy  wrote:
>> With my six node cluster ... nodetool loadbalance should be run on one
>> node or all six?  I run it on one and the ownership percentage gets
>> even more unbalanced.  So... in the spirit of the evening, I run it on
>> another node . as you see, the ownership % keeps increasing and
>> the token numbers keep increasing.  is this expected?  I would have
>> hoped that the behaviour would be a little bit different.  Maybe I've
>> missed something big
>>
>>
>>
>> Address Status State   LoadOwnsToken
>>
>> 124804735337540159479107746638263794797
>> 10.0.0.1  Up Normal  225 KB  40.78%
>> 24053088190195663439419935163232881936
>> 10.0.0.2Up Normal  201.21 KB   19.17%
>> 56667357399723182105247119364967854254
>> 10.0.0.3   Up Normal  213.15 KB   17.61%
>> 86624712919272143003828971968762407027
>> 10.0.0.4   Up Normal  214.54 KB   11.22%
>> 105714724128406151241468359303513100912
>> 10.0.0.5  Up Normal  206.39 KB   5.61%
>> 115259729732973155360288052970888447854
>> 10.0.0.6Up Normal  242.93 KB   5.61%
>> 124804735337540159479107746638263794797
>>
>>
>> Address Status State   LoadOwnsToken
>>
>> 124804735337540159479107746638263794797
>> 10.0.0.2Up Normal  206.15 KB   59.95%
>> 56667357399723182105247119364967854254
>> 10.0.0.3   Up Normal  218.1 KB17.61%
>> 86624712919272143003828971968762407027
>> 10.0.0.4   Up Normal  219.48 KB   11.22%
>> 105714724128406151241468359303513100912
>> 10.0.0.5  Up Normal  216.31 KB   5.61%
>> 115259729732973155360288052970888447854
>> 10.0.0.1  Up Normal  224.32 KB   2.81%
>> 120032232535256657419697899804576121325
>> 10.0.0.6Up Normal  242.93 KB   2.81%
>> 124804735337540159479107746638263794797
>>
>>
>> Address Status State   LoadOwnsToken
>>
>> 124804735337540159479107746638263794797
>> 10.0.0.3   Up Normal  218.1 KB77.56%
>> 86624712919272143003828971968762407027
>> 10.0.0.4   Up Normal  225.71 KB   11.22%
>> 105714724128406151241468359303513100912
>> 10.0.0.5  Up Normal  216.31 KB   5.61%
>> 115259729732973155360288052970888447854
>> 10.0.0.1  Up Normal  224.32 KB   2.81%
>> 120032232535256657419697899804576121325
>> 10.0.0.2Up Normal  201.21 KB   1.40%
>> 122418483936398408449402823221419958061
>> 10.0.0.6Up Normal  242.93 KB   1.40%
>> 124804735337540159479107746638263794797
>>
>> Address Status State   LoadOwnsToken
>>
>> 124804735337540159479107746638263794797
>> 10.0.0.4   Up Normal  225.71 KB   88.78%
>> 105714724128406151241468359303513100912
>> 10.0.0.5  Up Normal  225.61 KB   5.61%
>> 115259729732973155360288052970888447854
>> 10.0.0.1  Up Normal  224.32 KB   2.81%
>> 120032232535256657419697899804576121325
>> 10.0.0.2Up Normal  201.21 KB   1.40%
>> 122418483936398408449402823221419958061
>> 10.0.0.3   Up Normal  218.13 KB   0.70%
>> 123611609636969283964255284929841876429
>> 10.0.0.6Up Normal  242.93 KB   0.70%
>> 124804735337540159479107746638263794797
>>
>>
>> Address Status State   LoadOwnsToken
>>
>> 124804735337540159479107746638263794797
>> 10.0.0.5  Up Leaving 225.61 KB   94.39%
>> 115259729732973155360288052970888447854
>> 10.0.0.1  Up Normal  214.39 KB   2.81%
>> 120032232535256657419697899804576121325
>> 10.0.0.2Up Normal  201.21 KB   1.40%
>> 122418483936398408449402823221419958061
>> 10.0.0.3   Up Normal  218.13 KB   0.70%
>> 123611609636969283964255284929841876429
>> 10.0.0.4   Up Normal  220.77 KB   0.35%
>> 124208172487254721721681515784052835613
>> 10.0.0.6Up Normal  248.08 KB   0.35%
>> 124804735337540159479107746638263794797
>>
>>
>>
>> 124804735337540159479107746638263794797
>> 10.0.0.1  Up Normal  214.39 KB   97.19%
>> 120032232535256657419697899804576121325
>> 10.0.0.2Up Normal  205.47 KB   1.40%
>> 122418483936398408449402823221419958061
>> 10.0.0.3   Up Normal  218.13 KB   0.70%
>> 123611609636969283964255284929841876429
>> 10.0.0.4   Up Normal  220.77 KB   0.35%
>> 124208172487254721721681515784052835613
>> 10.0.0.5  Up Normal  220.63 KB   0.18%
>> 124506453912397440600394631211158315205
>> 10.0.0.6Up Normal  248.08 KB   0.18%
>> 124804735337540159479107746638263794797
>>
>>
>> 97.19% ... awesome.
>>
>>
>> On Mon, Mar 14, 2011 at 10:47 PM, Narendra Sharma
>>  wrote:
>>> On the same page there is a section on L

Re: Write speed roughly 1/10 of expected.

[Tyler Hobbs]

>
> Re: Mr. Hobbs,
>
> Did you mean "which has the benefit of THRIFT-638, while 0.7.a.2 does not"
> (instead of 0.7.a.3)? 0.7.a.3 was the latest version of phpcassa we could
> find on github. We installed 0.7.a.3 with its C extension and didn't see an
> improvement. Is there a newer version with THRIFT-638 fix?
>

Neither 0.7.a.2 or 0.7.a.3 include the fix for THRIFT-638.  The fix *is*
included in the master branch, and a release with this fix included should
happen sometime soon.

-- 
Tyler Hobbs
Software Engineer, DataStax 
Maintainer of the pycassa  Cassandra
Python client library

Re: calculating initial_token

[Narendra Sharma]

The %age (owns) is just the arc length in terms of %age of tokens a node
owns out of the total token space. It doesn't reflect the actual data.

The size (load) is the real current load.

-Naren


On Mon, Mar 14, 2011 at 2:59 PM, Sasha Dolgy  wrote:

> ah, you know ... i have been reading it wrong.  the output shows a
> nice fancy column called "Owns" but i've only ever seen the percentage
> ... the amount of data or "load" is even ... doh.  thanks for the
> reply.  cheers
> -sd
>
> On Mon, Mar 14, 2011 at 10:47 PM, Narendra Sharma
>  wrote:
> > On the same page there is a section on Load Balance that talks about
> python
> > script to compute tokens. I believe your question is more about assigning
> > new tokens and not compute tokens.
> >
> > 1. "nodetool loadbalance" will result in recomputation of tokens. It will
> > pick tokens based on the load and not the once assigned by you.
> > 2. You can either use decommission and bootstrap with new tokens OR Use
> > "nodetool move"
> >
> > Thanks,
> > Naren
> >
> > On Mon, Mar 14, 2011 at 1:18 PM, Sasha Dolgy  wrote:
> >>
> >> Sorry for being a bit daft ... Wanted a bit of validation or rejection
> ...
> >>
> >> If I have a 6 node cluster, replication factor 2 (don't think this is
> >> applicable to the token decision) is the following sufficient and
> >> correct for determining the tokens:
> >>
> >> #!/bin/bash
> >> for nodes in {0..5};
> >> do
> >>echo "$nodes*(2^127/5)" | bc;
> >> done
> >>
> >>
> >>
> >>
> >> Gives me a result of:
> >>
> >> 0
> >> 34028236692093846346337460743176821145
> >> 68056473384187692692674921486353642290
> >> 102084710076281539039012382229530463435
> >> 136112946768375385385349842972707284580
> >> 170141183460469231731687303715884105725
> >>
> >> My ring right now is:
> >>
> >>
> >> 10.0.0.2  Up Normal  225 KB  40.78%
> >> 24053088190195663439419935163232881936
> >> 10.0.0.3Up Normal  201.21 KB   19.17%
> >> 56667357399723182105247119364967854254
> >> 10.0.0.4   Up Normal  213.15 KB   17.61%
> >> 86624712919272143003828971968762407027
> >> 10.0.0.5   Up Normal  214.54 KB   11.22%
> >> 105714724128406151241468359303513100912
> >> 10.0.0.6  Up Normal  206.39 KB   5.61%
> >> 115259729732973155360288052970888447854
> >> 10.0.0.7Up Normal  247.68 KB   5.61%
> >> 124804735337540159479107746638263794797
> >>
> >> If my new tokens are correct:
> >>
> >> 1.  cassandra.yaml is updated on each node with new token
> >> 2.  node is restarted and a nodetool repair is run, or is a nodetool
> >> loadbalance run
> >>
> >> Thanks in advance ... been staring at
> >> http://wiki.apache.org/cassandra/Operations#Token_selection for too
> >> long
> >>
> >> --
> >> Sasha Dolgy
> >> sasha.do...@gmail.com
> >
> >
>
>
>
> --
> Sasha Dolgy
> sasha.do...@gmail.com
>

Re: problem with bootstrap

[aaron morton]

Thanks, will try to look into it. 

Aaron

On 14 Mar 2011, at 20:43, Patrik Modesto wrote:

> On Fri, Mar 11, 2011 at 22:31, Aaron Morton  wrote:
>> The assertion is interesting. Can you reproduce it with logging at debug and 
>> post the results? Could you try to reproduce it with a clean cluster?
> 
> It was on a clean cluster last time. Anyway I started clean cluster
> again, repeated the same steps with DEBUG enabled. This is the part of
> log when the AssertionError happend:
> 
> DEBUG 08:32:50,513 reading RangeSliceCommand{keyspace='Context',
> column_family='Url', super_column=null,
> predicate=SlicePredicate(slice_range:SliceRange(start:80 01 00 01 00
> 00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 07
> 0C 00 01 0B 00 03 00 00 00 03 55 72 6C 00 0C 00 02 0C 00 02 0B 00 01
> 00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65
> 5F 73 6C 69 63 65 73 00 00 00 07 0C 00 01 0B 00 03 00 00 00 03 55 72
> 6C 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00,
> reversed:false, count:2147483647)),
> range=(4839275280018186837186594882659755,53884050462475230985987955197486389848],
> max_keys=100} from /10.0.18.99
> DEBUG 08:32:50,513 reading RangeSliceCommand{keyspace='Context',
> column_family='Url', super_column=null,
> predicate=SlicePredicate(slice_range:SliceRange(start:80 01 00 01 00
> 00 00 10 67 65 74 5F 72 61 6E 67 65 5F 73 6C 69 63 65 73 00 00 00 07
> 0C 00 01 0B 00 03 00 00 00 03 55 72 6C 00 0C 00 02 0C 00 02 0B 00 01
> 00 00 00 00, finish:80 01 00 01 00 00 00 10 67 65 74 5F 72 61 6E 67 65
> 5F 73 6C 69 63 65 73 00 00 00 07 0C 00 01 0B 00 03 00 00 00 03 55 72
> 6C 00 0C 00 02 0C 00 02 0B 00 01 00 00 00 00 0B 00 02 00 00 00 00,
> reversed:false, count:2147483647)),
> range=(4839275280018186837186594882659755,53884050462475230985987955197486389848],
> max_keys=100} from /10.0.18.129
> DEBUG 08:32:50,515 Processing response on a callback from 159@/10.0.18.99
> DEBUG 08:32:50,515 Processing response on a callback from 160@/10.0.18.129
> ERROR 08:32:50,518 Fatal exception in thread
> Thread[RequestResponseStage:3,5,main]
> java.lang.AssertionError
>at 
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
>at 
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
>at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>at java.lang.Thread.run(Thread.java:662)
> 
> It happens on every node I run the request on, the others report
> nothing on that particular request.
> 
> HTH,
> P.

Re: Seed

[aaron morton]

What page is that from ? 

Aaron
On 15 Mar 2011, at 06:20, mcasandra wrote:

> 
> Tyler Hobbs-2 wrote:
>> 
>> Seeds:
>> Never use a node's own address as a seed if you are bootstrapping it by
>> setting autobootstrap to true! 
>> 
> 
> I came accross this on the wiki. Can someone please help me understand this
> with some example?
> 
> --
> View this message in context: 
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Seed-tp6162837p6169871.html
> Sent from the cassandra-u...@incubator.apache.org mailing list archive at 
> Nabble.com.

Re: problems while TimeUUIDType-index-querying with two expressions

[aaron morton]

It's failing to when comparing two TimeUUID values because on of them is not 
properly formatted. In this case it's comparing a stored value with the value 
passed in the get_indexed_slice() query expression. 

I'm going to assume it's the value passed for the expression. 

When you create the IndexedSlicesQuery this is incorrect

IndexedSlicesQuery indexQuery = HFactory
.createIndexedSlicesQuery(keyspace,
stringSerializer, bytesSerializer, 
bytesSerializer);

Use a UUIDSerializer for the last param and then pass the UUID you want to 
build the expressing. Rather than the string/byte thing you are passing

Hope that helps.
Aaron

On 15 Mar 2011, at 04:17, Johannes Hoerle wrote:

> Hi all,
>  
> in order to improve our queries, we started to use IndexedSliceQueries from 
> the hector project (https://github.com/zznate/hector-examples). I followed 
> the instructions for creating IndexedSlicesQuery with GetIndexedSlices.java. 
> I created the corresponding CF with in a keyspace called “Keyspace1” ( 
> “create keyspace  Keyspace1;”) with:
> "create column family Indexed1 with column_type='Standard' and 
> comparator='UTF8Type' and keys_cached=20 and read_repair_chance=1.0 and 
> rows_cached=2 and column_metadata=[{column_name: birthdate, 
> validation_class: LongType, index_name: dateIndex, index_type: 
> KEYS},{column_name: birthmonth, validation_class: LongType, index_name: 
> monthIndex, index_type: KEYS}];"
> and the example GetIndexedSlices.java worked fine. 
>  
> Output of CF Indexed1:
> ---
> [default@Keyspace1] list Indexed1;
> Using default limit of 100
> ---
> RowKey: fake_key_12
> => (column=birthdate, value=1974, timestamp=1300110485826059)
> => (column=birthmonth, value=0, timestamp=1300110485826060)
> => (column=fake_column_0, value=66616b655f76616c75655f305f3132, 
> timestamp=1300110485826056)
> => (column=fake_column_1, value=66616b655f76616c75655f315f3132, 
> timestamp=1300110485826057)
> => (column=fake_column_2, value=66616b655f76616c75655f325f3132, 
> timestamp=1300110485826058)
> ---
> RowKey: fake_key_8
> => (column=birthdate, value=1974, timestamp=1300110485826039)
> => (column=birthmonth, value=8, timestamp=1300110485826040)
> => (column=fake_column_0, value=66616b655f76616c75655f305f38, 
> timestamp=1300110485826036)
> => (column=fake_column_1, value=66616b655f76616c75655f315f38, 
> timestamp=1300110485826037)
> => (column=fake_column_2, value=66616b655f76616c75655f325f38, 
> timestamp=1300110485826038)
> ---
> 
>  
>  
> Now to the problem:
> As we have another column format in our cluster (using TimeUUIDType as 
> comparator in CF definition) I adapted the application to our schema on a 
> cassandra-0.7.3 cluster. 
> We use a manually defined UUID for a mandator id index 
> (--1000--) and another one for a userid index 
> (0001--1000--). It can be created with:
> "create column family ByUser with column_type='Standard' and 
> comparator='TimeUUIDType' and keys_cached=20 and read_repair_chance=1.0 
> and rows_cached=2 and column_metadata=[{column_name: 
> --1000--, validation_class: BytesType, 
> index_name: mandatorIndex, index_type: KEYS}, {column_name: 
> 0001--1000--, validation_class: BytesType, 
> index_name: useridIndex, index_type: KEYS}];"
>  
>  
> which looks in the cluster using cassandra-cli like this:
>  
> [default@Keyspace1] describe keyspace;
> Keyspace: Keyspace1:
>   Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
> Replication Factor: 1
>   Column Families:
> ColumnFamily: ByUser
>   Columns sorted by: org.apache.cassandra.db.marshal.TimeUUIDType
>   Row cache size / save period: 2.0/0
>   Key cache size / save period: 20.0/14400
>   Memtable thresholds: 0.2953125/63/1440
>   GC grace seconds: 864000
>   Compaction min/max thresholds: 4/32
>   Read repair chance: 0.01
>   Built indexes: [ByUser.mandatorIndex, ByUser.useridIndex]
>   Column Metadata:
> Column Name: 0001--1000--
>   Validation Class: org.apache.cassandra.db.marshal.BytesType
>   Index Name: useridIndex
>   Index Type: KEYS
> Column Name: --1000--
>   Validation Class: org.apache.cassandra.db.marshal.BytesType
>   Index Name: mandatorIndex
>   Index Type: KEYS
> ColumnFamily: Indexed1
>   Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
>   Row cache size / save period: 2.0/0
>   Key cache size / save period: 20.0/14400
>   Memtable thresholds: 0.2953125/63/1440
>   GC grace seconds: 864000
>   Compaction min/max thresholds: 4/32
>   Read repair chance: 0.01
>   Built indexes: [Indexed1.dateIndex, Indexed1.month

Re: calculating initial_token

[aaron morton]

Once the node has started once, it will not use the value for initial_token in 
cassandra.yaml.

Use nodetool move to assign a new token to the node. nodetool loadbalance is 
generally a bad idea www.spidertracks.com

 Aaron
On 15 Mar 2011, at 13:04, Narendra Sharma wrote:

> The %age (owns) is just the arc length in terms of %age of tokens a node owns 
> out of the total token space. It doesn't reflect the actual data.
> 
> The size (load) is the real current load.
> 
> -Naren
> 
> 
> On Mon, Mar 14, 2011 at 2:59 PM, Sasha Dolgy  wrote:
> ah, you know ... i have been reading it wrong.  the output shows a
> nice fancy column called "Owns" but i've only ever seen the percentage
> ... the amount of data or "load" is even ... doh.  thanks for the
> reply.  cheers
> -sd
> 
> On Mon, Mar 14, 2011 at 10:47 PM, Narendra Sharma
>  wrote:
> > On the same page there is a section on Load Balance that talks about python
> > script to compute tokens. I believe your question is more about assigning
> > new tokens and not compute tokens.
> >
> > 1. "nodetool loadbalance" will result in recomputation of tokens. It will
> > pick tokens based on the load and not the once assigned by you.
> > 2. You can either use decommission and bootstrap with new tokens OR Use
> > "nodetool move"
> >
> > Thanks,
> > Naren
> >
> > On Mon, Mar 14, 2011 at 1:18 PM, Sasha Dolgy  wrote:
> >>
> >> Sorry for being a bit daft ... Wanted a bit of validation or rejection ...
> >>
> >> If I have a 6 node cluster, replication factor 2 (don't think this is
> >> applicable to the token decision) is the following sufficient and
> >> correct for determining the tokens:
> >>
> >> #!/bin/bash
> >> for nodes in {0..5};
> >> do
> >>echo "$nodes*(2^127/5)" | bc;
> >> done
> >>
> >>
> >>
> >>
> >> Gives me a result of:
> >>
> >> 0
> >> 34028236692093846346337460743176821145
> >> 68056473384187692692674921486353642290
> >> 102084710076281539039012382229530463435
> >> 136112946768375385385349842972707284580
> >> 170141183460469231731687303715884105725
> >>
> >> My ring right now is:
> >>
> >>
> >> 10.0.0.2  Up Normal  225 KB  40.78%
> >> 24053088190195663439419935163232881936
> >> 10.0.0.3Up Normal  201.21 KB   19.17%
> >> 56667357399723182105247119364967854254
> >> 10.0.0.4   Up Normal  213.15 KB   17.61%
> >> 86624712919272143003828971968762407027
> >> 10.0.0.5   Up Normal  214.54 KB   11.22%
> >> 105714724128406151241468359303513100912
> >> 10.0.0.6  Up Normal  206.39 KB   5.61%
> >> 115259729732973155360288052970888447854
> >> 10.0.0.7Up Normal  247.68 KB   5.61%
> >> 124804735337540159479107746638263794797
> >>
> >> If my new tokens are correct:
> >>
> >> 1.  cassandra.yaml is updated on each node with new token
> >> 2.  node is restarted and a nodetool repair is run, or is a nodetool
> >> loadbalance run
> >>
> >> Thanks in advance ... been staring at
> >> http://wiki.apache.org/cassandra/Operations#Token_selection for too
> >> long
> >>
> >> --
> >> Sasha Dolgy
> >> sasha.do...@gmail.com
> >
> >
> 
> 
> 
> --
> Sasha Dolgy
> sasha.do...@gmail.com
> 

Re: Calculate memory used for keycache

[Robert Coli]

On Mon, Mar 14, 2011 at 1:19 PM, Peter Schuller
 wrote:
>> How is it possible calculate this value? I think that key size, if we use
>> RandomPartitioner will 16 bytes so keycache will took 16*(num of keycache
>> elements) bytes ??
>
> The easiest way right now is probably empirical testing. The issue is
> that the "memory use" must include overhead associated with the data
> structures involved, as well as longer-term effects like fragmentation
> in old-space in the GC (similarly to malloc/free).

In 0.7 and trunk, there is "nodetool clear[row|key]cache", so your
testing could be of the form :

a) start cluster
b) read enough keys to populate your caches per CF
c) measure memory usage
d) clear cache
e) measure memory usage

=Rob

Re: problems while TimeUUIDType-index-querying with two expressions

[Jonathan Ellis]

Sounds like we should send an InvalidRequestException then.

On Mon, Mar 14, 2011 at 8:06 PM, aaron morton  wrote:
> It's failing to when comparing two TimeUUID values because on of them is not
> properly formatted. In this case it's comparing a stored value with the
> value passed in the get_indexed_slice() query expression.
> I'm going to assume it's the value passed for the expression.
> When you create the IndexedSlicesQuery this is incorrect
> IndexedSlicesQuery indexQuery = HFactory
> .createIndexedSlicesQuery(keyspace,
> stringSerializer, bytesSerializer, bytesSerializer);
> Use a UUIDSerializer for the last param and then pass the UUID you want to
> build the expressing. Rather than the string/byte thing you are passing
> Hope that helps.
> Aaron
> On 15 Mar 2011, at 04:17, Johannes Hoerle wrote:
>
> Hi all,
>
> in order to improve our queries, we started to use IndexedSliceQueries from
> the hector project (https://github.com/zznate/hector-examples). I followed
> the instructions for creating IndexedSlicesQuery with
> GetIndexedSlices.java.
> I created the corresponding CF with in a keyspace called “Keyspace1” (
> “create keyspace  Keyspace1;”) with:
> "create column family Indexed1 with column_type='Standard' and
> comparator='UTF8Type' and keys_cached=20 and read_repair_chance=1.0 and
> rows_cached=2 and column_metadata=[{column_name: birthdate,
> validation_class: LongType, index_name: dateIndex, index_type:
> KEYS},{column_name: birthmonth, validation_class: LongType, index_name:
> monthIndex, index_type: KEYS}];"
> and the example GetIndexedSlices.java worked fine.
>
> Output of CF Indexed1:
> ---
> [default@Keyspace1] list Indexed1;
> Using default limit of 100
> ---
> RowKey: fake_key_12
> => (column=birthdate, value=1974, timestamp=1300110485826059)
> => (column=birthmonth, value=0, timestamp=1300110485826060)
> => (column=fake_column_0, value=66616b655f76616c75655f305f3132,
> timestamp=1300110485826056)
> => (column=fake_column_1, value=66616b655f76616c75655f315f3132,
> timestamp=1300110485826057)
> => (column=fake_column_2, value=66616b655f76616c75655f325f3132,
> timestamp=1300110485826058)
> ---
> RowKey: fake_key_8
> => (column=birthdate, value=1974, timestamp=1300110485826039)
> => (column=birthmonth, value=8, timestamp=1300110485826040)
> => (column=fake_column_0, value=66616b655f76616c75655f305f38,
> timestamp=1300110485826036)
> => (column=fake_column_1, value=66616b655f76616c75655f315f38,
> timestamp=1300110485826037)
> => (column=fake_column_2, value=66616b655f76616c75655f325f38,
> timestamp=1300110485826038)
> ---
> 
>
>
> Now to the problem:
> As we have another column format in our cluster (using TimeUUIDType as
> comparator in CF definition) I adapted the application to our schema on a
> cassandra-0.7.3 cluster.
> We use a manually defined UUID for a mandator id index
> (--1000--) and another one for a userid index
> (0001--1000--). It can be created with:
> "create column family ByUser with column_type='Standard' and
> comparator='TimeUUIDType' and keys_cached=20 and read_repair_chance=1.0
> and rows_cached=2 and column_metadata=[{column_name:
> --1000--, validation_class: BytesType,
> index_name: mandatorIndex, index_type: KEYS}, {column_name:
> 0001--1000--, validation_class: BytesType,
> index_name: useridIndex, index_type: KEYS}];"
>
>
> which looks in the cluster using cassandra-cli like this:
>
> [default@Keyspace1] describe keyspace;
> Keyspace: Keyspace1:
>   Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>     Replication Factor: 1
>   Column Families:
>     ColumnFamily: ByUser
>       Columns sorted by: org.apache.cassandra.db.marshal.TimeUUIDType
>       Row cache size / save period: 2.0/0
>       Key cache size / save period: 20.0/14400
>       Memtable thresholds: 0.2953125/63/1440
>       GC grace seconds: 864000
>       Compaction min/max thresholds: 4/32
>       Read repair chance: 0.01
>       Built indexes: [ByUser.mandatorIndex, ByUser.useridIndex]
>       Column Metadata:
>         Column Name: 0001--1000--
>           Validation Class: org.apache.cassandra.db.marshal.BytesType
>           Index Name: useridIndex
>           Index Type: KEYS
>         Column Name: --1000--
>           Validation Class: org.apache.cassandra.db.marshal.BytesType
>           Index Name: mandatorIndex
>           Index Type: KEYS
>     ColumnFamily: Indexed1
>       Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
>       Row cache size / save period: 2.0/0
>       Key cache size / save period: 20.0/14400
>       Memtable thresholds: 0.2953125/63/1440
>       GC grace seconds: 864000
>       Compaction min/max thresholds: 4/32
>       Read repair chance: 0.01
>       Built i

running all unit tests

[Jeffrey Wang]

Hey all,

We're applying some patches to our own branch of Cassandra, and we are 
wondering if there is a good way to run all the unit tests. Just having JUnit 
run all the test classes seems to result in a lot of errors that are hard to 
fix, so I'm hoping there's an easy way to do this. Thanks!

-Jeffrey

Re: problems while TimeUUIDType-index-querying with two expressions

[aaron morton]

Perfectly reasonable, created 
https://issues.apache.org/jira/browse/CASSANDRA-2328

Aaron
On 15 Mar 2011, at 16:52, Jonathan Ellis wrote:

> Sounds like we should send an InvalidRequestException then.
> 
> On Mon, Mar 14, 2011 at 8:06 PM, aaron morton  wrote:
>> It's failing to when comparing two TimeUUID values because on of them is not
>> properly formatted. In this case it's comparing a stored value with the
>> value passed in the get_indexed_slice() query expression.
>> I'm going to assume it's the value passed for the expression.
>> When you create the IndexedSlicesQuery this is incorrect
>> IndexedSlicesQuery indexQuery = HFactory
>> .createIndexedSlicesQuery(keyspace,
>> stringSerializer, bytesSerializer, bytesSerializer);
>> Use a UUIDSerializer for the last param and then pass the UUID you want to
>> build the expressing. Rather than the string/byte thing you are passing
>> Hope that helps.
>> Aaron
>> On 15 Mar 2011, at 04:17, Johannes Hoerle wrote:
>> 
>> Hi all,
>> 
>> in order to improve our queries, we started to use IndexedSliceQueries from
>> the hector project (https://github.com/zznate/hector-examples). I followed
>> the instructions for creating IndexedSlicesQuery with
>> GetIndexedSlices.java.
>> I created the corresponding CF with in a keyspace called “Keyspace1” (
>> “create keyspace  Keyspace1;”) with:
>> "create column family Indexed1 with column_type='Standard' and
>> comparator='UTF8Type' and keys_cached=20 and read_repair_chance=1.0 and
>> rows_cached=2 and column_metadata=[{column_name: birthdate,
>> validation_class: LongType, index_name: dateIndex, index_type:
>> KEYS},{column_name: birthmonth, validation_class: LongType, index_name:
>> monthIndex, index_type: KEYS}];"
>> and the example GetIndexedSlices.java worked fine.
>> 
>> Output of CF Indexed1:
>> ---
>> [default@Keyspace1] list Indexed1;
>> Using default limit of 100
>> ---
>> RowKey: fake_key_12
>> => (column=birthdate, value=1974, timestamp=1300110485826059)
>> => (column=birthmonth, value=0, timestamp=1300110485826060)
>> => (column=fake_column_0, value=66616b655f76616c75655f305f3132,
>> timestamp=1300110485826056)
>> => (column=fake_column_1, value=66616b655f76616c75655f315f3132,
>> timestamp=1300110485826057)
>> => (column=fake_column_2, value=66616b655f76616c75655f325f3132,
>> timestamp=1300110485826058)
>> ---
>> RowKey: fake_key_8
>> => (column=birthdate, value=1974, timestamp=1300110485826039)
>> => (column=birthmonth, value=8, timestamp=1300110485826040)
>> => (column=fake_column_0, value=66616b655f76616c75655f305f38,
>> timestamp=1300110485826036)
>> => (column=fake_column_1, value=66616b655f76616c75655f315f38,
>> timestamp=1300110485826037)
>> => (column=fake_column_2, value=66616b655f76616c75655f325f38,
>> timestamp=1300110485826038)
>> ---
>> 
>> 
>> 
>> Now to the problem:
>> As we have another column format in our cluster (using TimeUUIDType as
>> comparator in CF definition) I adapted the application to our schema on a
>> cassandra-0.7.3 cluster.
>> We use a manually defined UUID for a mandator id index
>> (--1000--) and another one for a userid index
>> (0001--1000--). It can be created with:
>> "create column family ByUser with column_type='Standard' and
>> comparator='TimeUUIDType' and keys_cached=20 and read_repair_chance=1.0
>> and rows_cached=2 and column_metadata=[{column_name:
>> --1000--, validation_class: BytesType,
>> index_name: mandatorIndex, index_type: KEYS}, {column_name:
>> 0001--1000--, validation_class: BytesType,
>> index_name: useridIndex, index_type: KEYS}];"
>> 
>> 
>> which looks in the cluster using cassandra-cli like this:
>> 
>> [default@Keyspace1] describe keyspace;
>> Keyspace: Keyspace1:
>>   Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
>> Replication Factor: 1
>>   Column Families:
>> ColumnFamily: ByUser
>>   Columns sorted by: org.apache.cassandra.db.marshal.TimeUUIDType
>>   Row cache size / save period: 2.0/0
>>   Key cache size / save period: 20.0/14400
>>   Memtable thresholds: 0.2953125/63/1440
>>   GC grace seconds: 864000
>>   Compaction min/max thresholds: 4/32
>>   Read repair chance: 0.01
>>   Built indexes: [ByUser.mandatorIndex, ByUser.useridIndex]
>>   Column Metadata:
>> Column Name: 0001--1000--
>>   Validation Class: org.apache.cassandra.db.marshal.BytesType
>>   Index Name: useridIndex
>>   Index Type: KEYS
>> Column Name: --1000--
>>   Validation Class: org.apache.cassandra.db.marshal.BytesType
>>   Index Name: mandatorIndex
>>   Index Type: KEYS
>> ColumnFamily: Indexed1
>>   Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
>>   Row cache