date:20121024

[jira] [Commented] (CASSANDRA-4816) Broken get_paged_slice

2012-10-24 Thread Cathy Daw (JIRA)


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

Cathy Daw commented on CASSANDRA-4816:
--

+1 this version fixes my tests as well.

 Broken get_paged_slice 
 ---

 Key: CASSANDRA-4816
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4816
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.6
Reporter: Piotr Kołaczkowski
Assignee: Sylvain Lebresne
Priority: Blocker
 Fix For: 1.1.7

 Attachments: 4816-2.txt, 4816-3.txt


 get_paged_slice doesn't reset the start column filter for the second returned 
 row sometimes. So instead of getting a slice:
 row 0: start_column...last_column_in_row
 row 1: first column in a row...last_column_in_row
 row 2: first column in a row...
 you sometimes get:
 row 0: start_column...last_column_in_row
 row 1: start_column...last_column_in_row
 row 2: first column in a row...

--
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-4816) Broken get_paged_slice

2012-10-24 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-4816:
-

To be clear, I'm also good on version 3 but I'll let Jonathan review since I've 
wrote version 2 on which version 3 is based.

 Broken get_paged_slice 
 ---

 Key: CASSANDRA-4816
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4816
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.1.6
Reporter: Piotr Kołaczkowski
Assignee: Sylvain Lebresne
Priority: Blocker
 Fix For: 1.1.7

 Attachments: 4816-2.txt, 4816-3.txt


 get_paged_slice doesn't reset the start column filter for the second returned 
 row sometimes. So instead of getting a slice:
 row 0: start_column...last_column_in_row
 row 1: first column in a row...last_column_in_row
 row 2: first column in a row...
 you sometimes get:
 row 0: start_column...last_column_in_row
 row 1: start_column...last_column_in_row
 row 2: first column in a row...

--
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-4800) cqlsh help is obsolete for cql3

2012-10-24 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne updated CASSANDRA-4800:


Summary: cqlsh help is obsolete for cql3  (was: cqlsh help is obsolete for 
cql3 DDL)

 cqlsh help is obsolete for cql3
 ---

 Key: CASSANDRA-4800
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4800
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
Priority: Minor
  Labels: cql3
 Fix For: 1.2.0 beta 2


 For example, new syntax for CREATE KEYSPACE is
 create keyspace foo with replication = {'class': 'SimpleStrategy', 
 'replication_factor': 1}

--
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-4800) cqlsh help is obsolete for cql3

2012-10-24 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-4800:
-

I've updated the title to reflect my opinion :)

But basically, we need to fix all the cqlsh help for 1.2 release anyway, so I 
don't see a point in creating many different tickets.

 cqlsh help is obsolete for cql3
 ---

 Key: CASSANDRA-4800
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4800
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
Priority: Minor
  Labels: cql3
 Fix For: 1.2.0 beta 2


 For example, new syntax for CREATE KEYSPACE is
 create keyspace foo with replication = {'class': 'SimpleStrategy', 
 'replication_factor': 1}

--
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-4835) Appending/Prepending items to list using BATCH

2012-10-24 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne updated CASSANDRA-4835:


Attachment: 0002-Ensure-same-timestamp-in-batches.txt
0001-Fix-prepends-within-same-millis.txt

Alright, this is in fact a legit bug in prepend and is not specific to batches 
(though it's probably harder to reproduce without them). Basically the logic in 
prepend to make sure we were always generating a decreasing keys even in the 
same millisecond was broken. It was working only for the same update, but was 
broke for successive update in the same millisecond. Patch attached to fix that.

That being said, I do think that people should be very careful in assuming that 
statements in a batch are applied in order *even within the same row* because 
that's just not true in general. Batch applies everything at the same time.  
So for instance:
{noformat}
BEGIN BATCH
  UPDATE user SET name = 'Goo' WHERE userid = 1;
  UPDATE user SET name = 'Foo' WHERE userid = 1;
APPLY BATCH
{noformat}
will always (that's not quite true currently, see below) end up setting 'Goo' 
as the name because the way the reconciliation rules work, the biggest value 
wins for equal timestamp. Similarly,
{noformat}
BEGIN BATCH
  DELETE FROM user WHERE userid = 1;
  UPDATE user SET name = 'Foo' WHERE userid = 1;
APPLY BATCH
{noformat}
will always (again, see below) end up with the user deleted because on 
timestamp ties, tombstone wins.

In other words, there was indeed a bug with prepend, and append/prepend do 
respect the order in batches within the same partition key because we happen to 
process the statements of a batch in order and there is no good reason to do 
otherwise, but I don't think we should make that a guarantee either (as in, 
it's true now, it could change tomorrow, it's an implementation detail). And so 
user shouldn't rely on it, and if the order is important, they should combine 
into one statement.

Now, it is unrelated to lists, but when I said that
{noformat}
BEGIN BATCH
  UPDATE user SET name = 'Goo' WHERE userid = 1;
  UPDATE user SET name = 'Foo' WHERE userid = 1;
APPLY BATCH
{noformat}
will always end up with 'Goo', it's not quite true currently, because batches 
don't guarantee that all update will use the same timestamp (in other words, 
the result of the batch above randomly depends of the timing of the operation). 
 I think that *that* is a guarantee we should provide: that unless the 
timestamp is user provided, all statement of a batch uses the same timestamp. 
I'm attaching a second patch that implements that.


 Appending/Prepending items to list using BATCH
 --

 Key: CASSANDRA-4835
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4835
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Krzysztof Cieslinski
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 1.2.0 beta 2

 Attachments: 0001-Fix-prepends-within-same-millis.txt, 
 0002-Ensure-same-timestamp-in-batches.txt


 As I know, there is no any guarantee that commands that are inside BATCH 
 block will execute in same order, as they are stored in the BATCH block. 
 But...
 I have made two tests:
 First appends some items to the empty list, and the second one, prepends 
 items, also to the empty list. Both of them are using UPDATE commands stored 
 in the BATCH block. 
 Results of those tests are as follow:
 First:
   When appending new items to list, USING commands are executed in the 
 same order as they are stored i BATCH.
 Second:
   When prepending new items to list, USING commands are executed in 
 random order.  
 So, in other words below code:
 {code:xml}
 BEGIN BATCH
  UPDATE... list_name = list_name + [ '1' ]  
  UPDATE... list_name = list_name + [ '2' ]
  UPDATE... list_name = list_name + [ '3' ] 
 APPLY BATCH;{code}
  always results in [ '1', '2', '3' ],
  but this code:
 {code:xml}
 BEGIN BATCH
  UPDATE... list_name = [ '1' ] + list_name   
  UPDATE... list_name = [ '2' ] + list_name
  UPDATE... list_name = [ '3' ] + list_name
 APPLY BATCH;{code}
 results in randomly ordered list, like [ '2', '1', '3' ](expected result 
 is [ '3', '2', '1' ])
 So somehow, when appending items to list, commands from BATCH are executed in 
 order as they are stored, but when prepending, the order is random.

--
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-3306) Error in LeveledCompactionStrategy

2012-10-24 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne commented on CASSANDRA-3306:
-

Good analysis Yuki. I'm not really sure what is the right fix though. Given 
that this should very rarely happen (repair uses a much higher failure 
detection threshold than the normal one, though maybe we can increase it even 
more to make this even less likely) and that I don't seen any obvious way to 
avoid that kind of situation, maybe making DataTracker handle duplicate 
addition of a SSTableReader is the simplest thing to do. The obvious way to do 
that would be to change the View sstables List to a Set, which leads me to the 
current commentary in the code:
{noformat}
// We can't use a SortedSet here because the ordering maintained by a 
sorted set (whether or not an
// explicit comparator is provided) must be iconsistent with 
equals/i.  In particular,
// ImmutableSortedSet will ignore any objects that compare equally with 
an existing Set member.
// Obviously, dropping sstables whose max column timestamp happens to 
be equal to another's
// is not acceptable for us.  So, we use a List instead.
{noformat}
I think that comment is obsolete. Namely, it was added with CASSANDRA-2498 and 
at the time the list of sstable was kept in max timestamp order at all time. 
But since then, we've moved the sorting in max timestamp in CollationController 
directly (which is less fragile), so the order inside DataTracker doesn't 
matter anymore.

 Error in LeveledCompactionStrategy
 --

 Key: CASSANDRA-3306
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3306
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Radim Kolar
Assignee: Yuki Morishita
 Attachments: 0001-CASSANDRA-3306-test.patch


 during stress testing, i always get this error making leveledcompaction 
 strategy unusable. Should be easy to reproduce - just write fast.
 ERROR [CompactionExecutor:6] 2011-10-04 15:48:52,179 
 AbstractCassandraDaemon.java (line 133) Fatal exception in thread 
 Thread[CompactionExecutor:6,5,main]
 java.lang.AssertionError
   at 
 org.apache.cassandra.db.DataTracker$View.newSSTables(DataTracker.java:580)
   at 
 org.apache.cassandra.db.DataTracker$View.replace(DataTracker.java:546)
   at org.apache.cassandra.db.DataTracker.replace(DataTracker.java:268)
   at 
 org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:232)
   at 
 org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:960)
   at 
 org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:199)
   at 
 org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:47)
   at 
 org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:131)
   at 
 org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:114)
   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:662)
 and this is in json data for table:
 {
   generations : [ {
 generation : 0,
 members : [ 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 
 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484 ]
   }, {
 generation : 1,
 members : [ ]
   }, {
 generation : 2,
 members : [ ]
   }, {
 generation : 3,
 members : [ ]
   }, {
 generation : 4,
 members : [ ]
   }, {
 generation : 5,
 members : [ ]
   }, {
 generation : 6,
 members : [ ]
   }, {
 generation : 7,
 members : [ ]
   } ]
 }

--
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-4179) Add more general support for composites (to row key, column value)

2012-10-24 Thread Edward Capriolo (JIRA)


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

Edward Capriolo commented on CASSANDRA-4179:


I see that I am probably too late to this discussion, but did want to point out 
we may be mis-using  the term primary-key here. In my mind the CQL3 compound 
primary key is more like the M$ SQL Cluster index, which controls sorting.

This syntax might do more to say These fields are the primary key and these 
fields are the ones we sort by.
{noformat}
CREATE TABLE timeline (
name text,
month int,
ts timestamp,
value text,
PRIMARY KEY (name, month),
clustered index (name,month,tx)
)
{noformat}


 Add more general support for composites (to row key, column value)
 --

 Key: CASSANDRA-4179
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4179
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
  Labels: cql3
 Fix For: 1.2.0 beta 1

 Attachments: 4179-2.txt, 4179.txt


 Currently CQL3 have a nice syntax for using composites in the column name 
 (it's more than that in fact, it creates a whole new abstraction but let's 
 say I'm talking implementation here). There is however 2 other place where 
 composites could be used (again implementation wise): the row key and the 
 column value. This ticket proposes to explore which of those make sense for 
 CQL3 and how.
 For the row key, I really think that CQL support makes sense. It's very 
 common (and useful) to want to stuff composite information in a row key. 
 Sharding a time serie (CASSANDRA-4176) is probably the best example but there 
 is other.
 For the column value it is less clear. CQL3 makes it very transparent and 
 convenient to store multiple related values into multiple columns so maybe 
 composites in a column value is much less needed. I do still see two cases 
 for which it could be handy:
 # to save some disk/memory space, if you do know it makes no sense to 
 insert/read two value separatly.
 # if you want to enforce that two values should not be inserted separatly. 
 I.e. to enforce a form of constraint to avoid programatic error.
 Those are not widely useful things, but my reasoning is that if whatever 
 syntax we come up for grouping row key in a composite trivially extends to 
 column values, why not support it.
 As for syntax I have 3 suggestions (that are just that, suggestions):
 # If we only care about allowing grouping for row keys:
 {noformat}
 CREATE TABLE timeline (
 name text,
 month int,
 ts timestamp,
 value text,
 PRIMARY KEY ((name, month), ts)
 )
 {noformat}
 # A syntax that could work for both grouping in row key and colum value:
 {noformat}
 CREATE TABLE timeline (
 name text,
 month int,
 ts timestamp,
 value1 text,
 value2 text,
 GROUP (name, month) as key,
 GROUP (value1, value2),
 PRIMARY KEY (key, ts)
 )
 {noformat}
 # An alternative to the preceding one:
 {noformat}
 CREATE TABLE timeline (
 name text,
 month int,
 ts timestamp,
 value1 text,
 value2 text,
 GROUP (name, month) as key,
 GROUP (value1, value2),
 PRIMARY KEY (key, ts)
 ) WITH GROUP (name, month) AS key
AND GROUP (value1, value2)
 {noformat}

--
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] [Created] (CASSANDRA-4853) composite row key

2012-10-24 Thread cristina rodriguez (JIRA)

cristina rodriguez created CASSANDRA-4853:
-

 Summary: composite row key
 Key: CASSANDRA-4853
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4853
 Project: Cassandra
  Issue Type: Task
  Components: Documentation  website
Affects Versions: 1.1.5
Reporter: cristina rodriguez


I have a columnfamily with a composite key,

create column family MyCF
with key_validation_class = 'CompositeType(UTF8Type, UTF8Type)'
and comparator = 'CompositeType(UTF8Type, UTF8Type)'
and default_validation_class='CompositeType(UTF8Type, UTF8Type)'
   
;

i store the row key with the value 1:1 ,1:2,1:3

---
RowKey: 1:1
= (column=colum1, value=value1, timestamp=1351093372962000)
---
RowKey: 2:2
= (column=colum1, value=value1, timestamp=1351093411137000)
---
RowKey: 1:3
= (column=colum1, value=value1, timestamp=135109338582)
---
RowKey: 2:1
= (column=colum1, value=value1, timestamp=1351093401162000)
---
RowKey: 1:2
= (column=colum1, value=value1, timestamp=1351093379274000)
---
RowKey: 2:3
= (column=colum1, value=value1, timestamp=1351093421393000)

i want to get all the row that estar wit 1,with cql  whit all that i read i 
thought it could be posible, but i coudn´t do it. 
i thought it would work with
select * from MyCF where key'1:';
any idea or example? 

--
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] [Created] (CASSANDRA-4854) Can not select the Schema table

2012-10-24 Thread Edward Capriolo (JIRA)

Edward Capriolo created CASSANDRA-4854:
--

 Summary: Can not select the Schema table
 Key: CASSANDRA-4854
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4854
 Project: Cassandra
  Issue Type: Bug
Reporter: Edward Capriolo
Priority: Minor


Some system tables can be selected with data. Some return 0 rows. Schema seems 
impossible to select because it's name is Schema

{noformat}
cqlsh:system select * from schema_keyspaces;
 keyspace_name | durable_writes | strategy_class
   | strategy_options
---++--+
  testkeyspace |   True |  
org.apache.cassandra.locator.SimpleStrategy | {replication_factor:1}
testks |   True | 
org.apache.cassandra.locator.NetworkTopologyStrategy |
{datacenter1:1}

cqlsh:system select * from Schema;
Bad Request: line 1:14 no viable alternative at input 'Schema'
cqlsh:system select * from Schema;
cqlsh:system select * from `Schema`;
Invalid syntax at line 1, char 15
  select * from `Schema`;
^
cqlsh:system select * from `Schema`;
Invalid syntax at line 1, char 15
  select * from `Schema`;
^
cqlsh:system select * from 'Schema';
Bad Request: line 1:14 no viable alternative at input 'Schema'
Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.
{noformat}

--
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-4443) shuffle utility for vnodes

2012-10-24 Thread Brandon Williams (JIRA)


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

Brandon Williams commented on CASSANDRA-4443:
-

Hmm, I'm seeing this when trying to create:

{noformat}

Exception in thread main java.lang.RuntimeException: 
InvalidRequestException(why:no keyspace has been specified)
at org.apache.cassandra.tools.Shuffle.executeCqlQuery(Shuffle.java:532)
at org.apache.cassandra.tools.Shuffle.shuffle(Shuffle.java:375)
at org.apache.cassandra.tools.Shuffle.main(Shuffle.java:693)
Caused by: InvalidRequestException(why:no keyspace has been specified)
at 
org.apache.cassandra.thrift.Cassandra$execute_cql_query_result.read(Cassandra.java:36625)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at 
org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql_query(Cassandra.java:1525)
at 
org.apache.cassandra.thrift.Cassandra$Client.execute_cql_query(Cassandra.java:1511)
at 
org.apache.cassandra.tools.CassandraClient.execute_cql_query(Shuffle.java:748)
at org.apache.cassandra.tools.Shuffle.executeCqlQuery(Shuffle.java:518)
... 2 more
{noformat}

 shuffle utility for vnodes
 --

 Key: CASSANDRA-4443
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4443
 Project: Cassandra
  Issue Type: Sub-task
  Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Assignee: Eric Evans
  Labels: vnodes
 Fix For: 1.2.0 beta 2


 As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to 
 split up the contiguous ranges.
 List discussion: http://thread.gmane.org/gmane.comp.db.cassandra.devel/6799
 _Edit0: Linked in mailing list discussion._
 _Edit1: Linked in patch information._
 _Edit2: Updated patch links._
 \\
 h3. Patches
 ||Compare||Raw diff||Description||
 |[060_shuffle_utility|https://github.com/acunu/cassandra/compare/top-bases/p/4443/060_shuffle_utility...p/4443/060_shuffle_utility]|[060_shuffle_utility.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/060_shuffle_utility...p/4443/060_shuffle_utility.diff]|{{shuffle}}
  util to randomly remap ranges|
 
 _Note: These are branches managed with TopGit. If you are applying the patch 
 output manually, you will either need to filter the TopGit metadata files 
 (i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), 
 or remove them afterward ({{rm .topmsg .topdeps}})._

--
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-3799) cqlsh: ASSUME should also change how values are sent to cassandra

2012-10-24 Thread paul cannon (JIRA)


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

paul cannon commented on CASSANDRA-3799:


Just to clarify for others, it might not be as bad as it sounds, since cqlsh 
already parses every insert, update, and batch, including contained statements. 
The difficulty is just in making sure that cqlsh can marshal textual values 
(from user input) and then unmarshal them again, both in the same way that 
Cassandra will do for the same contexts.

 cqlsh: ASSUME should also change how values are sent to cassandra
 -

 Key: CASSANDRA-3799
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3799
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Affects Versions: 1.0.3
Reporter: paul cannon
Assignee: Aleksey Yeschenko
Priority: Minor
  Labels: cqlsh
 Fix For: 1.3


 cqlsh's ASSUME command currently only changes how query *return* values are 
 deserialized, and never transforms user CQL text before sending to Cassandra.
 Apparently cassandra-cli also changes how values are interpreted and 
 marshaled for Cassandra, so user expectation is that cqlsh should also do 
 this.

--
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-10-24 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-4071:
-

I'm beginning to think we've made a mistake in the counters design. Namely,
when we write a new increment to the leader, we write the increment, then
read (which merge the new increments to the previous ones), then send that to
the other replica. But that's why we have all the delta business that is the
root cause for this and for CASSANDRA-4417 (and we're not even sure we
understand all the case that can produce the error message of CASSANDRA-4417).

An alternative would be instead that when the leader receives a new increment,
it reads, apply the increment to the value read, and write the result. If we do
that, we don't need delta anymore, fixing this issue as well as CASSANDRA-4417.
We also don't ever have to renew nodeId, so we also fix the problem of
increasing counter context. And overall we greatly simplify the code. There
would be clear performance downsides however:
# we will have to lock during the read, apply increment, write result dance.
# we still read before the first write, so replicate_on_write won't be an
option anymore (I've always been clear how I personally feel about this option
in the first place so that would almost be an advantage in my opinion, but some
disagree). But it will also increase the latency of writes at CL.ONE.

But even if we decide to go that route, another thing to go into account is
that I don't know how to support the upgrade to this new way of doing things
without requiring a major compaction on upgrade (which is particularly a
problem for LeveledCompaction because we don't even know how to major compact).

So definitively not perfect, but the best idea I've had so far.

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

[jira] [Resolved] (CASSANDRA-4854) Can not select the Schema table

2012-10-24 Thread Sylvain Lebresne (JIRA)


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

Sylvain Lebresne resolved CASSANDRA-4854.
-

Resolution: Not A Problem

Schema is the old-style, pre-1.1 schema table so as soon as you've correctly 
started a 1.1 it is expected to be empty. So
{noformat}
select * from Schema
{noformat}
is correct and is working as expected.

The new-style schema tables are: schema_keyspaces, schema_columnfamilies and 
schema_columns.

 Can not select the Schema table
 -

 Key: CASSANDRA-4854
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4854
 Project: Cassandra
  Issue Type: Bug
Reporter: Edward Capriolo
Priority: Minor

 Some system tables can be selected with data. Some return 0 rows. Schema 
 seems impossible to select because it's name is Schema
 {noformat}
 cqlsh:system select * from schema_keyspaces;
  keyspace_name | durable_writes | strategy_class  
  | strategy_options
 ---++--+
   testkeyspace |   True |  
 org.apache.cassandra.locator.SimpleStrategy | {replication_factor:1}
 testks |   True | 
 org.apache.cassandra.locator.NetworkTopologyStrategy |
 {datacenter1:1}
 cqlsh:system select * from Schema;
 Bad Request: line 1:14 no viable alternative at input 'Schema'
 cqlsh:system select * from Schema;
 cqlsh:system select * from `Schema`;
 Invalid syntax at line 1, char 15
   select * from `Schema`;
 ^
 cqlsh:system select * from `Schema`;
 Invalid syntax at line 1, char 15
   select * from `Schema`;
 ^
 cqlsh:system select * from 'Schema';
 Bad Request: line 1:14 no viable alternative at input 'Schema'
 Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.
 {noformat}

--
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-4837) IllegalStateException when upgrading schema

2012-10-24 Thread Wade Simmons (JIRA)


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

Wade Simmons commented on CASSANDRA-4837:
-

AL: I haven't been able to get it to work yet. Still trying to find a solution 
that works.

 IllegalStateException when upgrading schema
 ---

 Key: CASSANDRA-4837
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4837
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6
 Environment: Linux
Reporter: Wade Simmons
Assignee: Pavel Yaskevich

 I am upgrading a cluster from 1.1.2 to 1.1.6. When restarting a node with new 
 code, I am seeing this exception repeat in the logs:
 {code}
 ERROR [InternalResponseStage:21] 2012-10-19 00:41:26,794 
 AbstractCassandraDaemon.java (line 135) Exception in thread 
 Thread[InternalResponseStage:21,5,main]
 java.lang.IllegalStateException: One row required, 0 found
 at 
 org.apache.cassandra.cql3.UntypedResultSet.one(UntypedResultSet.java:50)
 at 
 org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:258)
 at 
 org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:406)
 at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:355)
 at 
 org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:329)
 at 
 org.apache.cassandra.service.MigrationManager$MigrationTask$1.response(MigrationManager.java:449)
 at 
 org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
 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)
 {code}
 I added in some debugging logging to see what Row it was trying to load, and 
 I see this:
 {code}
 Unable to load keyspace schema: 
 Row(key=DecoratedKey(112573196966143652100562749464385838776, 
 5365676d656e7473496e746567726174696f6e54657374), 
 cf=ColumnFamily(schema_keyspaces -deleted at 1350665377628000- []))
 {code}
 The hex key translates to a schema that exists in schema_keyspaces when I 
 query on the rest of the cluster. I tried restarting one of the other nodes 
 without upgrading the jar and it restarted without exceptions.

--
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] [Comment Edited] (CASSANDRA-4854) Can not select the Schema table

2012-10-24 Thread Edward Capriolo (JIRA)


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

Edward Capriolo edited comment on CASSANDRA-4854 at 10/24/12 5:48 PM:
--

You are right my mistake. I noticed something else. It seems like if you 
describe an empty keyspace you get this.

{noformat}
cqlsh:system describe schema;
USE testkeyspace;

expected string or buffer
{noformat}

Should we open another ticket for this? this is 1.2.0-beta btw.

  was (Author: appodictic):
You are right my mistake. I noticed something else. It seems like if you 
describe an empty keyspace you get this.

{noformat}
cqlsh:system describe schema;
USE testkeyspace;

expected string or buffer
{noformat}

Should we open another ticket for this?
  
 Can not select the Schema table
 -

 Key: CASSANDRA-4854
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4854
 Project: Cassandra
  Issue Type: Bug
Reporter: Edward Capriolo
Priority: Minor

 Some system tables can be selected with data. Some return 0 rows. Schema 
 seems impossible to select because it's name is Schema
 {noformat}
 cqlsh:system select * from schema_keyspaces;
  keyspace_name | durable_writes | strategy_class  
  | strategy_options
 ---++--+
   testkeyspace |   True |  
 org.apache.cassandra.locator.SimpleStrategy | {replication_factor:1}
 testks |   True | 
 org.apache.cassandra.locator.NetworkTopologyStrategy |
 {datacenter1:1}
 cqlsh:system select * from Schema;
 Bad Request: line 1:14 no viable alternative at input 'Schema'
 cqlsh:system select * from Schema;
 cqlsh:system select * from `Schema`;
 Invalid syntax at line 1, char 15
   select * from `Schema`;
 ^
 cqlsh:system select * from `Schema`;
 Invalid syntax at line 1, char 15
   select * from `Schema`;
 ^
 cqlsh:system select * from 'Schema';
 Bad Request: line 1:14 no viable alternative at input 'Schema'
 Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.
 {noformat}

--
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-4854) Can not select the Schema table

2012-10-24 Thread Edward Capriolo (JIRA)


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

Edward Capriolo commented on CASSANDRA-4854:


You are right my mistake. I noticed something else. It seems like if you 
describe an empty keyspace you get this.

{noformat}
cqlsh:system describe schema;
USE testkeyspace;

expected string or buffer
{noformat}

Should we open another ticket for this?

 Can not select the Schema table
 -

 Key: CASSANDRA-4854
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4854
 Project: Cassandra
  Issue Type: Bug
Reporter: Edward Capriolo
Priority: Minor

 Some system tables can be selected with data. Some return 0 rows. Schema 
 seems impossible to select because it's name is Schema
 {noformat}
 cqlsh:system select * from schema_keyspaces;
  keyspace_name | durable_writes | strategy_class  
  | strategy_options
 ---++--+
   testkeyspace |   True |  
 org.apache.cassandra.locator.SimpleStrategy | {replication_factor:1}
 testks |   True | 
 org.apache.cassandra.locator.NetworkTopologyStrategy |
 {datacenter1:1}
 cqlsh:system select * from Schema;
 Bad Request: line 1:14 no viable alternative at input 'Schema'
 cqlsh:system select * from Schema;
 cqlsh:system select * from `Schema`;
 Invalid syntax at line 1, char 15
   select * from `Schema`;
 ^
 cqlsh:system select * from `Schema`;
 Invalid syntax at line 1, char 15
   select * from `Schema`;
 ^
 cqlsh:system select * from 'Schema';
 Bad Request: line 1:14 no viable alternative at input 'Schema'
 Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.
 {noformat}

--
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-4837) IllegalStateException when upgrading schema

2012-10-24 Thread Pavel Yaskevich (JIRA)


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

Pavel Yaskevich commented on CASSANDRA-4837:


[~wadey] Can you please attach schema_* directories here so I can take a look 
what is going on there?

 IllegalStateException when upgrading schema
 ---

 Key: CASSANDRA-4837
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4837
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6
 Environment: Linux
Reporter: Wade Simmons
Assignee: Pavel Yaskevich

 I am upgrading a cluster from 1.1.2 to 1.1.6. When restarting a node with new 
 code, I am seeing this exception repeat in the logs:
 {code}
 ERROR [InternalResponseStage:21] 2012-10-19 00:41:26,794 
 AbstractCassandraDaemon.java (line 135) Exception in thread 
 Thread[InternalResponseStage:21,5,main]
 java.lang.IllegalStateException: One row required, 0 found
 at 
 org.apache.cassandra.cql3.UntypedResultSet.one(UntypedResultSet.java:50)
 at 
 org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:258)
 at 
 org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:406)
 at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:355)
 at 
 org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:329)
 at 
 org.apache.cassandra.service.MigrationManager$MigrationTask$1.response(MigrationManager.java:449)
 at 
 org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
 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)
 {code}
 I added in some debugging logging to see what Row it was trying to load, and 
 I see this:
 {code}
 Unable to load keyspace schema: 
 Row(key=DecoratedKey(112573196966143652100562749464385838776, 
 5365676d656e7473496e746567726174696f6e54657374), 
 cf=ColumnFamily(schema_keyspaces -deleted at 1350665377628000- []))
 {code}
 The hex key translates to a schema that exists in schema_keyspaces when I 
 query on the rest of the cluster. I tried restarting one of the other nodes 
 without upgrading the jar and it restarted without exceptions.

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

92 matches

Mail list logo