date:20121204

[jira] [Updated] (CASSANDRA-5017) Preparing UPDATE queries with collections returns suboptimal metadata

2012-12-04 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne updated CASSANDRA-5017:


Attachment: 0003-Fix-handling-of-prepared-marker-for-deletes.txt
0002-Fix-prepared-list-index-and-using-integer-for-map-keys.txt
0001-Return-correct-metadata-when-preparing-map.txt

Attaching 3 small patches that fixes a number of problems with prepared queries 
and collections, including this one, the fact that you weren't allowed to 
prepare a list index and the fact that delete wasn't working correctly when 
either a list index or a map key was prepared.

I note we have a small problem for the metadata return in all those cases, in 
that if you do
{noformat}
UPDATE foo SET amap[?] = ? WHERE ...
{noformat}
then it's unclear what name to return for the prepared variables in the 
metadata. The choice made by the patch is to return 'key(amap)' and 
'value(amap)' respectively (and when preparing a list index, we return 
'index(alist)').


 Preparing UPDATE queries with collections returns suboptimal metadata
 -

 Key: CASSANDRA-5017
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5017
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 2
Reporter: Aleksey Yeschenko
Assignee: Sylvain Lebresne
Priority: Minor
 Attachments: 0001-Return-correct-metadata-when-preparing-map.txt, 
 0002-Fix-prepared-list-index-and-using-integer-for-map-keys.txt, 
 0003-Fix-handling-of-prepared-marker-for-deletes.txt


 CQL3, binary protocol.
 collections (id int primary key, amap mapint, varchar);
 preparing UPDATE test.collections SET amap[?] = ? WHERE id = ? returns the 
 following metadata:
 [{column,test,collections,amap,
{map,int,varchar}},
{column,test,collections,amap,
{map,int,varchar}},
{column,test,collections,id,int}]
 Ideally it should return [int, varchar, int] types. Less ideally [{map, int, 
 varchar}, int] and expect an encoded map with a single key-value pair. But 
 certainly not what it currently returns.

--
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] [Resolved] (CASSANDRA-5018) Some queries with collections require quoting the key even when the key is an integer

2012-12-04 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne resolved CASSANDRA-5018.
-

Resolution: Duplicate

Marking this a duplicate of CASSANDRA-5017 because the 2nd patch attached to 
that issue happens to fix this issue too.

 Some queries with collections require quoting the key even when the key is an 
 integer
 -

 Key: CASSANDRA-5018
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5018
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 2
Reporter: Aleksey Yeschenko
Assignee: Sylvain Lebresne
Priority: Trivial

 collections (id int primary key, amap mapint, varchar);
 UPDATE test.collections SET amap[1] = 'text' WHERE id = 0 - List 
 operations are only supported on List typed columns
 UPDATE test.collections SET amap['1'] = 'text' WHERE id = 0 - ok
 Not sure if boolean/double/uuid/etc. are affected or require quoting as well.
 DELETE is not affected though: DELETE amap[1] from test.collections where id 
 = 0 - ok

--
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-4071) Topology changes can lead to bad counters (at RF=1)

2012-12-04 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-4071:
-

bq. Could we introduce something like gc_g_s for node ids so renewing doesn't
have to be avoided so religiously?

The problem is that when we renew a counterId, the existing shards are still
parts of all those counters. So the only way to get rid of those shards would
be to merge their values into some newer shard. But as far as I can tell (and
I've put quite some though into that), this is really hard to do correctly,
because it's not something you can do in isolation of other nodes.

That being said, we do have some mechanism that does exactly that shard merging
in a few cases. I.e. if a node detects that a counter has 2 shards for 2 old
counterId of itself, it merges them in two phases: first we merge one of the
shard into the other but we keep the first shard with a value of 0. And only
when we consider this has been propagated to all replica (after gc_grace
basically), do we remove the zeroed shard. However:
# this shard merging is already a fairly dark and hacky corner of the counter
implementation. I'd rather remove it than complicate it further.
# it only works for counter that don't change ownership basically. As soon as a
counter changes ownership, whatever old counterId it has won't ever be merged.
The reason is that a node only knows about it's own counterId because that's
the only simple way I've found to ensure 2 nodes don't start doing the 2-phase
merge on the same counterIds at the same time.

Topology changes can lead to bad counters (at RF=1)
---

Key: CASSANDRA-4071
URL: https://issues.apache.org/jira/browse/CASSANDRA-4071
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Sylvain Lebresne
Labels: counters

A counter is broken into shards (partitions), each shard being 'owned' by a
given replica (meaning that only this replica will increment that shard).
For a given node A, the resolution of 2 shards (having the same owner)
follows the following rules:
* if the shards are owned by A, then sum the values (in the original patch,
'owned by A' was based on the machine IP address, in the current code, it's
based on the shard having a delta flag but the principle is the same)
* otherwise, keep the maximum value (based on the shards clocks)
During topology changes (boostrap/move/decommission), we transfer data from A
to B, but the shards owned by A are not owned by B (and we cannot make them
owned by B because during those operations (boostrap, ...) a given shard
would be owned by A and B which would break counters). But this means that B
won't interpret the streamed shards correctly.
Concretely, if A receives a number of counter increments that end up in
different sstables (the shards should thus be summed) and then those
increments are streamed to B as part of boostrap, B will not sum the
increments but use the clocks to keep the maximum value.
I've pushed a test that show the breakeage at
https://github.com/riptano/cassandra-dtest/commits/counters_test (the test
needs CASSANDRA-4070 to work correctly).
Note that in practice, replication will hide this (even though B will have
the bad value after the boostrap, read or read/repair from the other replica
will repair it). This is a problem for RF=1 however.
Another problem is that during repair, a node won't correctly repair other
nodes on it's own shards (unless everything is fully compacted).

--
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

[Cassandra Wiki] Update of RelatedProjects by TerranceShepherd

2012-12-04 Thread Apache Wiki

Dear Wiki user,

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

The RelatedProjects page has been changed by TerranceShepherd:
http://wiki.apache.org/cassandra/RelatedProjects?action=diffrev1=7rev2=8

   * https://github.com/flewton/flewton the extensible Netflow collector
   * https://github.com/ticktock/qsandra A Cassandra backed PersistenceAdapter 
for ActiveMQ
   * http://esper.codehaus.org/ A Cassandra backend for Esper CEP
+  * https://github.com/canausa/cassandra-teaspoon An simplification in 
managing the installation of Cassandra and Sun Java 1.6 on a Debian-like system.
  
  == Cassandra clients ==
  See ClientOptions

[jira] [Created] (CASSANDRA-5025) Schema push/pull race

2012-12-04 Thread Jonathan Ellis (JIRA)

Jonathan Ellis created CASSANDRA-5025:
-

 Summary: Schema push/pull race
 Key: CASSANDRA-5025
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5025
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Jonathan Ellis
Priority: Minor
 Fix For: 1.1.8


When a schema change is made, the coordinator pushes the delta to the other 
nodes in the cluster.  This is more efficient than sending the entire schema.  
But the coordinator also announces the new schema version, so the other nodes' 
reception of the new version races with processing the delta, and usually 
seeing the new schema wins.  So the other nodes also issue a pull to the 
coordinator for the entire schema.

Thus, schema changes tend to become O(n) in the number of KS and CF present.

--
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-5009) RangeStreamer has no way to report failures, allowing bootstrap/move etc to complete without data

2012-12-04 Thread Brandon Williams (JIRA)


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

Brandon Williams updated CASSANDRA-5009:


Fix Version/s: 1.1.8

 RangeStreamer has no way to report failures, allowing bootstrap/move etc to 
 complete without data
 -

 Key: CASSANDRA-5009
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5009
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Critical
 Fix For: 1.1.8, 1.2.0 beta 3

 Attachments: 5009.txt, 5009-v2.txt


 It looks like we fixed this for 1.2 by having RS.fetch() throw, but in 1.1 it 
 does not and there doesn't appear to be a way to detect an RS failure, which 
 among other things will cause bootstrap to succeed even though it failed to 
 fetch any data.

--
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-5022) Can't prepare an UPDATE query with a counter column (CQL3)

2012-12-04 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne updated CASSANDRA-5022:


Attachment: 5002.txt

Attaching patch to fix that. The patch also move some small bit of validation 
that were done at execution time to preparation time (since there is no good 
reason not to do it there).

 Can't prepare an UPDATE query with a counter column (CQL3)
 --

 Key: CASSANDRA-5022
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5022
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 2
Reporter: Aleksey Yeschenko
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.0 rc1

 Attachments: 5002.txt


 CQL3, binary protocol:
 demo(id int primary key, counter counter)
 Preparing UPDATE test.counters SET counter = counter + ? WHERE id = ? 
 yields 8704, Invalid operation for commutative columnfamily counters error.

--
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

Git Push Summary

2012-12-04 Thread slebresne

Updated Tags:  refs/tags/cassandra-1.2.0-beta3 [created] eb2d12ab7

Git Push Summary

2012-12-04 Thread slebresne

Updated Tags:  refs/tags/1.2.0-beta3-tentative [deleted] b86f75dcd

svn commit: r1417120 - in /cassandra/site: publish/download/index.html src/settings.py

2012-12-04 Thread slebresne

Author: slebresne
Date: Tue Dec  4 19:09:17 2012
New Revision: 1417120

URL: http://svn.apache.org/viewvc?rev=1417120view=rev
Log:
Update website for 1.2.0-beta3 release

Modified:
cassandra/site/publish/download/index.html
cassandra/site/src/settings.py

Modified: cassandra/site/publish/download/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1417120r1=1417119r2=1417120view=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Tue Dec  4 19:09:17 2012
@@ -107,16 +107,16 @@
 
   h2 class=hdrDevelopment Cassandra Server Releases (not production 
ready)/h2
   p
-  The latest development release is 1.2.0-beta2 (released on
-  2012-11-09).
+  The latest development release is 1.2.0-beta3 (released on
+  2012-12-04).
   /p
 
   ul
 li
-a class=filename 
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.0/apache-cassandra-1.2.0-beta2-bin.tar.gz;apache-cassandra-1.2.0-beta2-bin.tar.gz/a
-[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta2-bin.tar.gz.asc;PGP/a]
-[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta2-bin.tar.gz.md5;MD5/a]
-[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta2-bin.tar.gz.sha1;SHA1/a]
+a class=filename 
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.0/apache-cassandra-1.2.0-beta3-bin.tar.gz;apache-cassandra-1.2.0-beta3-bin.tar.gz/a
+[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta3-bin.tar.gz.asc;PGP/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta3-bin.tar.gz.md5;MD5/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta3-bin.tar.gz.sha1;SHA1/a]
 /li
   /ul
   
@@ -195,10 +195,10 @@
   
   
 li
-a class=filename 
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.0/apache-cassandra-1.2.0-beta2-src.tar.gz;apache-cassandra-1.2.0-beta2-src.tar.gz/a
-[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta2-src.tar.gz.asc;PGP/a]
-[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta2-src.tar.gz.md5;MD5/a]
-[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta2-src.tar.gz.sha1;SHA1/a]
+a class=filename 
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.0/apache-cassandra-1.2.0-beta3-src.tar.gz;apache-cassandra-1.2.0-beta3-src.tar.gz/a
+[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta3-src.tar.gz.asc;PGP/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta3-src.tar.gz.md5;MD5/a]
+[a 
href=http://www.apache.org/dist/cassandra/1.2.0/apache-cassandra-1.2.0-beta3-src.tar.gz.sha1;SHA1/a]
 /li
   
   /ul 

Modified: cassandra/site/src/settings.py
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/settings.py?rev=1417120r1=1417119r2=1417120view=diff
==
--- cassandra/site/src/settings.py (original)
+++ cassandra/site/src/settings.py Tue Dec  4 19:09:17 2012
@@ -100,8 +100,8 @@ class CassandraDef(object):
 veryoldstable_exists = True
 stable_version = '1.1.7'
 stable_release_date = '2012-11-30'
-devel_version = '1.2.0-beta2'
-devel_release_date = '2012-11-09'
+devel_version = '1.2.0-beta3'
+devel_release_date = '2012-12-04'
 devel_exists = True
 _apache_base_url = 'http://www.apache.org'
 _svn_base_url = 'https://svn.apache.org/repos/asf'

[jira] [Commented] (CASSANDRA-5023) Upgrading from 1.0 to 1.1 makes secondary indexes no longer work

2012-12-04 Thread Yuki Morishita (JIRA)


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

Yuki Morishita commented on CASSANDRA-5023:
---

In above case, inserting via CQL stores value(and key in index) in 
IntegerType(BigInteger), and you are querying that with 1 byte 
ByteBuffer(ByteBufferUtil.bytes(0)). If you change the line

{code}
indexExpressions.add(new 
IndexExpression(ByteBufferUtil.bytes(numberOfDeloreans), IndexOperator.EQ, 
ByteBufferUtil.bytes(0)));
{code}

to

{code}
indexExpressions.add(new 
IndexExpression(ByteBufferUtil.bytes(numberOfDeloreans), IndexOperator.EQ, 
IntegerType.instance.fromString(0)));
{code}

it all works fine.

So why the code has been working with 1.0? In 1.0, DecoratedKey#compareTo just 
compares two tokens. LocalToken, which is used for secondary index, from 
ByteBufferUtil.bytes(0) ...(1) and from 
IntegerType.instance.fromString(0)...(2) are considered equal when using 
IntegerType, and that's why you can query IntegerTyped DK with both (1) and (2).

DK#comparedTo changed since 1.1(CASSANDRA-1034), and now DKs are compared by 
key itself byte by byte if two tokens are considered equal. In above case, 
tokens are equal but keys are different byte-wise. So you only can query 
IndexedTyped value with the same IndexTyped value now.

So I conclude that the behavior of 1.0 can be considered as a bug.

 Upgrading from 1.0 to 1.1 makes secondary indexes no longer work
 

 Key: CASSANDRA-5023
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5023
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jeremy Hanna
Assignee: Yuki Morishita
 Fix For: 1.1.8


 To reproduce:
 Create column family with C* 1.0.8:
 {code}
 CREATE KEYSPACE Keyspace1 
 with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
 and strategy_options = {replication_factor:1};
 use Keyspace1;
 CREATE COLUMN FAMILY 'User' WITH
  key_validation_class = 'UTF8Type' AND
  comparator = 'UTF8Type' AND
  default_validation_class = 'UTF8Type' AND
  compression_options = 
 {sstable_compression:SnappyCompressor,chunk_length_kb:64} AND
  column_metadata = [
  {column_name: 'numberOfDeloreans', validation_class: 'IntegerType', 
 index_type: KEYS}
 ];
 {code}
 Then in cqlsh add some data:
 {code}
 use Keyspace1;
 update User set 'numberOfDeloreans'=0 where key = 'marty';
 update User set 'userId'='themartymcfly' where key = 'marty';
 {code}
 In cqlsh, do
 {code}select * from User where numberOfDeloreans=0;{code}
 Then in thrift do:
 {code}
 package org.mostlyharmless;
 import org.apache.cassandra.thrift.*;
 import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.thrift.TException;
 import org.apache.thrift.protocol.TProtocol;
 import org.apache.thrift.transport.TFramedTransport;
 import org.apache.thrift.transport.TSocket;
 import org.apache.thrift.transport.TTransport;
 import java.io.UnsupportedEncodingException;
 import java.nio.ByteBuffer;
 import java.util.ArrayList;
 import java.util.List;
 public class ThriftQuery {
 public static void main(String[] args)
 throws TException, InvalidRequestException, UnavailableException, 
 UnsupportedEncodingException, NotFoundException, TimedOutException
 {
 TTransport tr = new TFramedTransport(new TSocket(localhost, 9160));
 TProtocol proto = new TBinaryProtocol(tr);
 Cassandra.Client client = new Cassandra.Client(proto);
 tr.open();
 client.set_keyspace(Keyspace1);
 ColumnParent columnParent = new ColumnParent(User);
 SlicePredicate slicePredicate = new SlicePredicate();
 ListByteBuffer columnNames = new ArrayListByteBuffer();
 columnNames.add(ByteBufferUtil.bytes(userId));
 slicePredicate.setColumn_names(columnNames);
 KeyRange keyRange = new KeyRange();
 keyRange.setStart_token(0);
 keyRange.setEnd_token(0);
 ListIndexExpression indexExpressions = new 
 ArrayListIndexExpression();
 indexExpressions.add(new 
 IndexExpression(ByteBufferUtil.bytes(numberOfDeloreans), IndexOperator.EQ, 
 ByteBufferUtil.bytes(0)));
 keyRange.setRow_filter(indexExpressions);
 ListKeySlice keySlices = client.get_range_slices(columnParent, 
 slicePredicate, keyRange, ConsistencyLevel.ONE);
 System.out.println(number of keyslices returned:  + 
 keySlices.size());
 tr.close();
 }
 }
 {code}
 Note that 1 record is returned in both instances.
 Run nodetool drain on 1.0.8.  Start 1.1.7.  Do the cqlsh query again, returns 
 the result.  Run the thrift code again, get 0 results.
 Tried both upgradesstables and rebuild_index.  Didn't help.

--
This message is automatically generated by JIRA.

[jira] [Updated] (CASSANDRA-3378) Allow configuration of storage protocol socket buffer

2012-12-04 Thread JIRA


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

Michał Michalski updated CASSANDRA-3378:


Attachment: cassandra-3378-v2.patch

Thanks for reviewing, Brandon. 

Changes in v2:
1) Remove receive buffer setting from OutboundTcpConnection - as it's being 
used for Messaging purposes only and not really needed there
2) Set receive buffer (only) for IncommingTcpConnection. My concern is the way 
of changing this parameter in a kind of wide way - not only for streaming 
(for which it makes sense for me), but much earlier, so it affects messaging 
parts of code too. I'm unsure of the impact it may have on the messaging 
service in general - I don't have that much experience with Cassandra  network 
programming to judge it just like that.

 Allow configuration of storage protocol socket buffer
 -

 Key: CASSANDRA-3378
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3378
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Brandon Williams
Assignee: Michał Michalski
Priority: Minor
  Labels: lhf
 Attachments: cassandra-3378-v1.patch, cassandra-3378-v2.patch


 Similar to rpc_[send,recv]_buff_size_in_bytes, we should expose this for high 
 latency connections.

--
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-4191) Add `nodetool cfstats ks cf` abilities

2012-12-04 Thread Jackson Chung (JIRA)


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

Jackson Chung commented on CASSANDRA-4191:
--

the 2nd index option would be nice  :)

 Add `nodetool cfstats ks cf` abilities
 --

 Key: CASSANDRA-4191
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4191
 Project: Cassandra
  Issue Type: New Feature
Affects Versions: 1.2.0 beta 1
Reporter: Joaquin Casares
Assignee: Dave Brosius
Priority: Minor
  Labels: datastax_qa
 Attachments: 4191_specific_cfstats.diff


 This way cfstats will only print information per keyspace/column family 
 combinations.
 Another related proposal as an alternative to this ticket:
 Allow for `nodetool cfstats` to use --excludes or --includes to accept 
 keyspace and column family arguments.

--
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] [Resolved] (CASSANDRA-5023) Upgrading from 1.0 to 1.1 makes secondary indexes no longer work

2012-12-04 Thread Brandon Williams (JIRA)


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

Brandon Williams resolved CASSANDRA-5023.
-

Resolution: Not A Problem

 Upgrading from 1.0 to 1.1 makes secondary indexes no longer work
 

 Key: CASSANDRA-5023
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5023
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jeremy Hanna
Assignee: Yuki Morishita
 Fix For: 1.1.8


 To reproduce:
 Create column family with C* 1.0.8:
 {code}
 CREATE KEYSPACE Keyspace1 
 with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
 and strategy_options = {replication_factor:1};
 use Keyspace1;
 CREATE COLUMN FAMILY 'User' WITH
  key_validation_class = 'UTF8Type' AND
  comparator = 'UTF8Type' AND
  default_validation_class = 'UTF8Type' AND
  compression_options = 
 {sstable_compression:SnappyCompressor,chunk_length_kb:64} AND
  column_metadata = [
  {column_name: 'numberOfDeloreans', validation_class: 'IntegerType', 
 index_type: KEYS}
 ];
 {code}
 Then in cqlsh add some data:
 {code}
 use Keyspace1;
 update User set 'numberOfDeloreans'=0 where key = 'marty';
 update User set 'userId'='themartymcfly' where key = 'marty';
 {code}
 In cqlsh, do
 {code}select * from User where numberOfDeloreans=0;{code}
 Then in thrift do:
 {code}
 package org.mostlyharmless;
 import org.apache.cassandra.thrift.*;
 import org.apache.cassandra.utils.ByteBufferUtil;
 import org.apache.thrift.TException;
 import org.apache.thrift.protocol.TProtocol;
 import org.apache.thrift.transport.TFramedTransport;
 import org.apache.thrift.transport.TSocket;
 import org.apache.thrift.transport.TTransport;
 import java.io.UnsupportedEncodingException;
 import java.nio.ByteBuffer;
 import java.util.ArrayList;
 import java.util.List;
 public class ThriftQuery {
 public static void main(String[] args)
 throws TException, InvalidRequestException, UnavailableException, 
 UnsupportedEncodingException, NotFoundException, TimedOutException
 {
 TTransport tr = new TFramedTransport(new TSocket(localhost, 9160));
 TProtocol proto = new TBinaryProtocol(tr);
 Cassandra.Client client = new Cassandra.Client(proto);
 tr.open();
 client.set_keyspace(Keyspace1);
 ColumnParent columnParent = new ColumnParent(User);
 SlicePredicate slicePredicate = new SlicePredicate();
 ListByteBuffer columnNames = new ArrayListByteBuffer();
 columnNames.add(ByteBufferUtil.bytes(userId));
 slicePredicate.setColumn_names(columnNames);
 KeyRange keyRange = new KeyRange();
 keyRange.setStart_token(0);
 keyRange.setEnd_token(0);
 ListIndexExpression indexExpressions = new 
 ArrayListIndexExpression();
 indexExpressions.add(new 
 IndexExpression(ByteBufferUtil.bytes(numberOfDeloreans), IndexOperator.EQ, 
 ByteBufferUtil.bytes(0)));
 keyRange.setRow_filter(indexExpressions);
 ListKeySlice keySlices = client.get_range_slices(columnParent, 
 slicePredicate, keyRange, ConsistencyLevel.ONE);
 System.out.println(number of keyslices returned:  + 
 keySlices.size());
 tr.close();
 }
 }
 {code}
 Note that 1 record is returned in both instances.
 Run nodetool drain on 1.0.8.  Start 1.1.7.  Do the cqlsh query again, returns 
 the result.  Run the thrift code again, get 0 results.
 Tried both upgradesstables and rebuild_index.  Didn't help.

--
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-5005) Add a latency histogram option to stress

2012-12-04 Thread Brandon Williams (JIRA)


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

Brandon Williams commented on CASSANDRA-5005:
-

+1, with minor nit: it'd be better to keep with the CSV-style separator instead 
of using '/'

 Add a latency histogram option to stress
 

 Key: CASSANDRA-5005
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5005
 Project: Cassandra
  Issue Type: Improvement
Reporter: Brandon Williams
Assignee: Jonathan Ellis
Priority: Minor
  Labels: stress
 Fix For: 1.2.0 rc1

 Attachments: 5005.txt


 Averages just aren't always enough and it should be easy to wire our existing 
 histogram utils into stress.

--
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

1 2 >

1 - 100 of 106 matches

Mail list logo