date:20120829

[Cassandra Wiki] Trivial Update of Counters by Alexis Wilke

2012-08-29 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Cassandra Wiki for 
change notification.

The Counters page has been changed by Alexis Wilke:
http://wiki.apache.org/cassandra/Counters?action=diffrev1=16rev2=17

Comment:
Fixed a couple of plurial forms, and replace insert with add which is much 
more appropriate for a counter!

  {{{
  [default@test] create column family counterCF with 
default_validation_class=CounterColumnType and replicate_on_write=true;
  }}}
- Setting the `default_validation_class` to `CounterColumnType` indicates that 
the column will be counters. Setting `replicate_on_write=true` will be optional 
starting in 0.8.2, but a bug made it default to false in 0.8.0 and 0.8.1, which 
is unsafe.
+ Setting the `default_validation_class` to `CounterColumnType` indicates that 
the columns will be counters. Setting `replicate_on_write=true` will be 
optional starting in 0.8.2, but a bug made it default to false in 0.8.0 and 
0.8.1, which is unsafe.
  
   Incrementing and accessing counters 
  
@@ -86, +86 @@

  == Technical limitations ==
  
* If a write fails unexpectedly (timeout or loss of connection to the 
coordinator node) the client will not know if the operation has been performed. 
A retry can result in an over count 
[[https://issues.apache.org/jira/browse/CASSANDRA-2495|CASSANDRA-2495]].
-   * Counter removal is intrinsically limited. For instance, if you issue very 
quickly the sequence increment, remove, increment it is possible for the 
removal to be lost (if for some reason the remove happens to be the last 
received messages). Hence, removal of counters is provided for definitive 
removal only, that is when the deleted counter is not increment afterwards. 
This holds for row deletion too: if you delete a row of counters, incrementing 
any counter in that row (that existed before the deletion) will result in an 
undetermined behavior. Note that if you need to reset a counter, one option 
(that is unfortunately not concurrent safe) could be to read its ''value'' and 
insert ''-value''.
+   * Counter removal is intrinsically limited. For instance, if you issue very 
quickly the sequence increment, remove, increment it is possible for the 
removal to be lost (if for some reason the remove happens to be the last 
received messages). Hence, removal of counters is provided for definitive 
removal only, that is when the deleted counter is not increment afterwards. 
This holds for row deletion too: if you delete a row of counters, incrementing 
any counter in that row (that existed before the deletion) will result in an 
undetermined behavior. Note that if you need to reset a counter, one option 
(that is unfortunately not concurrent safe) could be to read its ''value'' and 
add ''-value''.
* `CounterColumnType` may only be set in the `default_validation_class`. A 
column family either contains only counters, or no counters at all.
  
  == Further reading ==
- See [[https://issues.apache.org/jira/browse/CASSANDRA-1072|CASSANDRA-1072]] 
and especially the 
[[https://issues.apache.org/jira/secure/attachment/12459754/Partitionedcountersdesigndoc.pdf|design
 doc]] for further information about how this works internally (but note that 
some of the limitation fixed in these technical documents have been fixed since 
then, for instance all consistency level '''are''' supported, for both reads 
and writes).
+ See [[https://issues.apache.org/jira/browse/CASSANDRA-1072|CASSANDRA-1072]] 
and especially the 
[[https://issues.apache.org/jira/secure/attachment/12459754/Partitionedcountersdesigndoc.pdf|design
 doc]] for further information about how this works internally (but note that 
some of the limitations fixed in these technical documents have been fixed 
since then, for instance all consistency level '''are''' supported, for both 
reads and writes).

[jira] [Updated] (CASSANDRA-4049) Add generic way of adding SSTable components required custom compaction strategy

2012-08-29 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Piotr Kołaczkowski updated CASSANDRA-4049:
--

Attachment: (was: pluggable_custom_components.patch)

 Add generic way of adding SSTable components required custom compaction 
 strategy
 

 Key: CASSANDRA-4049
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Piotr Kołaczkowski
Assignee: Piotr Kołaczkowski
Priority: Minor
  Labels: compaction
 Fix For: 1.1.5

 Attachments: pluggable_custom_components-1.1.4.patch


 CFS compaction strategy coming up in the next DSE release needs to store some 
 important information in Tombstones.db and RemovedKeys.db files, one per 
 sstable. However, currently Cassandra issues warnings when these files are 
 found in the data directory. Additionally, when switched to 
 SizeTieredCompactionStrategy, the files are left in the data directory after 
 compaction.
 The attached patch adds new components to the Component class so Cassandra 
 knows about those files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4049) Add generic way of adding SSTable components required custom compaction strategy

2012-08-29 Thread JIRA


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13443899#comment-13443899
 ] 

Piotr Kołaczkowski commented on CASSANDRA-4049:
---

Ok, rebased. Actually only line numbers changed, there was no conflict.

 Add generic way of adding SSTable components required custom compaction 
 strategy
 

 Key: CASSANDRA-4049
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Piotr Kołaczkowski
Assignee: Piotr Kołaczkowski
Priority: Minor
  Labels: compaction
 Fix For: 1.1.5

 Attachments: pluggable_custom_components-1.1.4.patch


 CFS compaction strategy coming up in the next DSE release needs to store some 
 important information in Tombstones.db and RemovedKeys.db files, one per 
 sstable. However, currently Cassandra issues warnings when these files are 
 found in the data directory. Additionally, when switched to 
 SizeTieredCompactionStrategy, the files are left in the data directory after 
 compaction.
 The attached patch adds new components to the Component class so Cassandra 
 knows about those files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4049) Add generic way of adding SSTable components required custom compaction strategy

2012-08-29 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Piotr Kołaczkowski updated CASSANDRA-4049:
--

Attachment: pluggable_custom_components-1.1.4.patch

 Add generic way of adding SSTable components required custom compaction 
 strategy
 

 Key: CASSANDRA-4049
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Piotr Kołaczkowski
Assignee: Piotr Kołaczkowski
Priority: Minor
  Labels: compaction
 Fix For: 1.1.5

 Attachments: pluggable_custom_components-1.1.4.patch


 CFS compaction strategy coming up in the next DSE release needs to store some 
 important information in Tombstones.db and RemovedKeys.db files, one per 
 sstable. However, currently Cassandra issues warnings when these files are 
 found in the data directory. Additionally, when switched to 
 SizeTieredCompactionStrategy, the files are left in the data directory after 
 compaction.
 The attached patch adds new components to the Component class so Cassandra 
 knows about those files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2897) Secondary indexes without read-before-write

2012-08-29 Thread Sam Tunnicliffe (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sam Tunnicliffe updated CASSANDRA-2897:
---

Attachment: 0003-CASSANDRA-2897.txt

Secondary indexes without read-before-write
---

Key: CASSANDRA-2897
URL: https://issues.apache.org/jira/browse/CASSANDRA-2897
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 0.7.0
Reporter: Sylvain Lebresne
Assignee: Sam Tunnicliffe
Priority: Minor
Labels: secondary_index
Fix For: 1.2.0 beta 1

Attachments:
0001-CASSANDRA-2897-Secondary-indexes-without-read-before-w.txt,
0002-CASSANDRA-2897-Secondary-indexes-without-read-before-w.txt,
0003-CASSANDRA-2897.txt, 2897-apply-cleanup.txt, 41ec9fc-2897.txt

Currently, secondary index updates require a read-before-write to maintain
the index consistency. Keeping the index consistent at all time is not
necessary however. We could let the (secondary) index get inconsistent on
writes and repair those on reads. This would be easy because on reads, we
make sure to request the indexed columns anyway, so we can just skip the row
that are not needed and repair the index at the same time.
This does trade work on writes for work on reads. However, read-before-write
is sufficiently costly that it will likely be a win overall.
There is (at least) two small technical difficulties here though:
# If we repair on read, this will be racy with writes, so we'll probably have
to synchronize there.
# We probably shouldn't only rely on read to repair and we should also have a
task to repair the index for things that are rarely read. It's unclear how to
make that low impact though.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4561) update column family fails

2012-08-29 Thread Pavel Yaskevich (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Yaskevich updated CASSANDRA-4561:
---

Attachment: CASSANDRA-4561.patch

 update column family fails
 --

 Key: CASSANDRA-4561
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
 Attachments: CASSANDRA-4561.patch


 [default@test] show schema;
 create column family Messages
   with column_type = 'Standard'
   and comparator = 'AsciiType'
   and default_validation_class = 'BytesType'
   and key_validation_class = 'AsciiType'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 2
   and max_compaction_threshold = 4
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
   and compression_options = {'chunk_length_kb' : '64', 'sstable_compression' 
 : 'org.apache.cassandra.io.compress.DeflateCompressor'};
 [default@test] update column family Messages with min_compaction_threshold = 
 4 and  max_compaction_threshold = 32;
 a5b7544e-1ef5-3bfd-8770-c09594e37ec2
 Waiting for schema agreement...
 ... schemas agree across the cluster
 [default@test] show schema;
 create column family Messages
   with column_type = 'Standard'
   and comparator = 'AsciiType'
   and default_validation_class = 'BytesType'
   and key_validation_class = 'AsciiType'
   and read_repair_chance = 0.1
   and dclocal_read_repair_chance = 0.0
   and gc_grace = 864000
   and min_compaction_threshold = 2
   and max_compaction_threshold = 4
   and replicate_on_write = true
   and compaction_strategy = 
 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
   and caching = 'KEYS_ONLY'
   and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
   and compression_options = {'chunk_length_kb' : '64', 'sstable_compression' 
 : 'org.apache.cassandra.io.compress.DeflateCompressor'};

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4532) NPE when trying to select a slice from a composite table

2012-08-29 Thread basanth gowda (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444059#comment-13444059
 ] 

basanth gowda commented on CASSANDRA-4532:
--

I was trying to get a slice range, like you could do in thrift.

table defn :

create tables schedules(status ascii, timecreated bigint, key ascii, nil ascii, 
PRIMARY KEY(status,timecreated,key));

for the same time there can be a lot of entries.

Lets suppose there are 50 entries that match where timecreated is  Ln

1st query : select * from schedules where timecreated = Ln limit 10;


2nd Query : select * from schedules where timecreated=L10 AND key=K10 and 
timecreatedLn.

In CQL terms this is a wrong query I know, basically not sure how to represent 
Between in CQL


In Hector I would do, get slice range limiting 10 first time, 

for the next query (until no more are returned) I would use the time returned 
by last query and key returned by last query as the start range. This is in 
production and works perfectly fine

 NPE when trying to select a slice from a composite table
 

 Key: CASSANDRA-4532
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4532
 Project: Cassandra
  Issue Type: Bug
  Components: API, Core
Affects Versions: 1.1.3
 Environment: Cassandra 1.1.3 (2 nodes) on a single host - mac osx
Reporter: basanth gowda
Priority: Minor
  Labels: Slice, cql, cql3

 I posted this question on StackOverflow, because i need a solution. 
 Created a table with :
 {noformat}
 create table compositetest(m_id ascii,i_id int,l_id ascii,body ascii, PRIMARY 
 KEY(m_id,i_id,l_id));
 {noformat}
 wanted to slice the results returned, so did something like below, not sure 
 if its the right way. The first one returns data perfectly as expected, 
 second one to get the next 3 columns closes the transport of my cqlsh
 {noformat}
 cqlsh:testkeyspace1 select * from compositetest where i_id=3 limit 3;
  m_id | i_id | l_id | body
 --+--+--+--
m1 |1 |   l1 |   b1
m1 |2 |   l2 |   b2
m2 |1 |   l1 |   b1
 cqlsh:testkeyspace1 Was trying to write something for slice range.
 TSocket read 0 bytes
 {noformat}
 Is there a way to achieve what I am doing here, it would be good if some 
 meaning ful error is sent back, instead of cqlsh closing the transport.
 On the server side I see the following error.
 {noformat}
 ERROR [Thrift:3] 2012-08-12 15:15:24,414 CustomTThreadPoolServer.java (line 
 204) Error occurred during processing of message.
 java.lang.NullPointerException
   at 
 org.apache.cassandra.cql3.statements.SelectStatement$Restriction.setBound(SelectStatement.java:1277)
   at 
 org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.updateRestriction(SelectStatement.java:1151)
   at 
 org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1001)
   at 
 org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:215)
   at 
 org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:121)
   at 
 org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1237)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3542)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3530)
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
   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:680)
 {noformat}
 With ThriftClient I get :
 {noformat}
 org.apache.thrift.transport.TTransportException
   at 
 org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
   at 
 org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
   at 
 org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
   at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
   at 
 org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378)
   at 
 org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297)
   at 
 org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:204)
   at

53 matches

Mail list logo