date:20140829


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

Sylvain Lebresne commented on CASSANDRA-7847:
-

The patch lgtm and I agree that this is how it should work, but I slightly 
worry about the fact that it's a breaking change as existing trigger names will 
be considered case-sensitive (and will thus start requiring quoting). This 
probably doesn't justify not doing this, but maybe it's worth putting it in 
2.1.0 (a breaking change might be more expected in a major than a minor) with a 
clear warning in the NEWS file? 

 Allow quoted identifiers for triggers' names
 

 Key: CASSANDRA-7847
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7847
 Project: Cassandra
  Issue Type: Bug
Reporter: Mikhail Stepura
Assignee: Mikhail Stepura
Priority: Minor
 Fix For: 2.1.1

 Attachments: CASSANDRA-2.1-7847.patch


 Current implementation doesn't allow quoted/case sensitive identifiers for 
 triggers' names, and doesn't handle those names in case-insensitive manner  
 either.
 {code}
 mstepura-mac:cassandra mikhail$ bin/cqlsh
 Connected to Test Cluster at 127.0.0.1:9042.
 [cqlsh 5.0.1 | Cassandra 2.1.1-SNAPSHOT | CQL spec 3.2.0 | Native protocol v3]
 Use HELP for help.
 cqlsh use stress;
 cqlsh:stress create TRIGGER ZooZoo ON t1 USING  
 'org.apache.cassandra.triggers.InvertedIndex';
 ErrorMessage code=2000 [Syntax error in CQL query] message=line 1:15 
 mismatched input 'ZooZoo' expecting IDENT (create TRIGGER [ZooZo]o ON...)
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress create TRIGGER ZooZoo ON t1 USING  
 'org.apache.cassandra.triggers.InvertedIndex';
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER zoozoo ON stress.t1 ;
 code=2200 [Invalid query] message=Trigger zoozoo was not found
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER ZooZoo ON stress.t1 ;
 ErrorMessage code=2000 [Syntax error in CQL query] message=line 1:13 
 mismatched input 'ZooZoo' expecting IDENT (drop TRIGGER [ZooZo]o ON...)
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER ZooZoo ON stress.t1 ;
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7801) A successful INSERT with CAS does not always store data in the DB after a DELETE

2014-08-29 Thread Martin Fransson (JIRA)


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

Martin Fransson commented on CASSANDRA-7801:


I have implemented the fix on the latest code in 2.1.1-snapshot, and it seems 
to work. I do not get the fault running my tests.


 A successful INSERT with CAS does not always store data in the DB after a 
 DELETE
 

 Key: CASSANDRA-7801
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7801
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: PC with Windows 7 and on Linux installation.
 Have seen the fault on Cassandra 2.0.9 and Cassandra 2.1.0-rc5 
Reporter: Martin Fransson
Assignee: Sylvain Lebresne
 Fix For: 2.0.11

 Attachments: 7801.txt, cas.zip


 When I run a loop with CQL statements to DELETE, INSERT with CAS and then a 
 GET.
 The INSERT opertion is successful (Applied), but no data is stored in the 
 database. I have checked the database manually after the test to verify that 
 the DB is empty.
 for (int i = 0; i  1; ++i)
 {
 try
 {
 t.del();
 t.cas();
 t.select();
 }
 catch (Exception e)
 {
 System.err.println(i= + i);
 e.printStackTrace();
 break;
 }
 }
 myCluster = 
 Cluster.builder().addContactPoint(localhost).withPort(12742).build();
 mySession = myCluster.connect();
 mySession.execute(CREATE KEYSPACE IF NOT EXISTS castest WITH 
 REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };);
 mySession.execute(CREATE TABLE IF NOT EXISTS castest.users (userid 
 text PRIMARY KEY, name text));
 myInsert = mySession.prepare(INSERT INTO castest.users (userid, 
 name) values ('user1', 'calle') IF NOT EXISTS);
 myDelete = mySession.prepare(DELETE FROM castest.users where 
 userid='user1');
 myGet = mySession.prepare(SELECT * FROM castest.users where 
 userid='user1');
 }
 I can reproduce the fault with the attached program on a PC with windows 7.
 You need a cassandra runing and you need to set the port in the program.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6565) New node refuses to join the ring.

2014-08-29 Thread Adrian Lisenberg (JIRA)


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

Adrian Lisenberg commented on CASSANDRA-6565:
-

Hi!, I have the same problem with 2.0.9. 
I have a cluster of tow nodes. When I try to boostrap a new node I get the 
following exception.
How can I look for corrupted sstables in my nodes? 

 WARN [GossipTasks:1] 2014-08-29 07:29:39,401 StreamResultFuture.java (line 
215) [Stream #ee709b70-2ed0-11e4-8d72-05912176c8e0] Stream failed
ERROR [main] 2014-08-29 07:29:39,402 CassandraDaemon.java (line 513) Exception 
encountered during startup
java.lang.RuntimeException: Error during boostrap: Stream failed
at org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:86)
at 
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1037)
at 
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:799)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:614)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:504)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
at 
org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1160)
at 
com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at 
com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at 
com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
at 
com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
at 
org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:216)
at 
org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:191)
at 
org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:353)
at 
org.apache.cassandra.streaming.StreamSession.convict(StreamSession.java:623)
at 
org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:241)
at org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:648)
at org.apache.cassandra.gms.Gossiper.access$700(Gossiper.java:64)
at org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:167)
at 
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPool
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)


 New node refuses to join the ring.
 --

 Key: CASSANDRA-6565
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6565
 Project: Cassandra
  Issue Type: Bug
Reporter: Shao-Chuan Wang

 We have 30 nodes in one DC, 25 nodes in another. We are running 2.0.1.
 Two nodes are joining the ring, but one of them failed
 ARN [STREAM-IN-/10.4.197.53] 2014-01-09 19:41:40,418 StreamResultFuture.java 
 (line 209) [Stream #e515d6e0-795d-11e3-b74a-b72892248056] Stream failed
 ERROR [main] 2014-01-09 19:41:40,418 CassandraDaemon.java (line 459) 
 Exception encountered during startup
 java.lang.RuntimeException: Error during boostrap: Stream failed
 at 
 org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:86)
 at 
 org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:901)
 at 
 org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:670)
 at 
 org.apache.cassandra.service.StorageService.initServer(StorageService.java:529)
 at 
 org.apache.cassandra.service.StorageService.initServer(StorageService.java:428)
 at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:343)
 at

[jira] [Updated] (CASSANDRA-7159) sstablemetadata command should print some more stuff

2014-08-29 Thread Vladislav Sinjavin (JIRA)


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

Vladislav Sinjavin updated CASSANDRA-7159:
--

Attachment: 
CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch

Patch for part of the task. MinMax tokens.

 sstablemetadata command should print some more stuff
 

 Key: CASSANDRA-7159
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7159
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Vladislav Sinjavin
Priority: Trivial
  Labels: lhf
 Attachments: 
 CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch


 It would be nice if the sstablemetadata command printed out some more of the 
 stuff we track.  Like the Min/Max column names and the min/max token in the 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7281) SELECT on tuple relations are broken for mixed ASC/DESC clustering order


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

Sylvain Lebresne updated CASSANDRA-7281:


Fix Version/s: (was: 1.2.19)
   2.0.11

 SELECT on tuple relations are broken for mixed ASC/DESC clustering order
 

 Key: CASSANDRA-7281
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7281
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
 Fix For: 2.0.11


 As noted on 
 [CASSANDRA-6875|https://issues.apache.org/jira/browse/CASSANDRA-6875?focusedCommentId=13992153page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992153],
  the tuple notation is broken when the clustering order mixes ASC and DESC 
 directives because the range of data they describe don't correspond to a 
 single continuous slice internally. To copy the example from CASSANDRA-6875:
 {noformat}
 cqlsh:ks create table foo (a int, b int, c int, PRIMARY KEY (a, b, c)) WITH 
 CLUSTERING ORDER BY (b DESC, c ASC);
 cqlsh:ks INSERT INTO foo (a, b, c) VALUES (0, 2, 0);
 cqlsh:ks INSERT INTO foo (a, b, c) VALUES (0, 1, 0);
 cqlsh:ks INSERT INTO foo (a, b, c) VALUES (0, 1, 1);
 cqlsh:ks INSERT INTO foo (a, b, c) VALUES (0, 0, 0);
 cqlsh:ks SELECT * FROM foo WHERE a=0;
  a | b | c
 ---+---+---
  0 | 2 | 0
  0 | 1 | 0
  0 | 1 | 1
  0 | 0 | 0
 (4 rows)
 cqlsh:ks SELECT * FROM foo WHERE a=0 AND (b, c)  (1, 0);
  a | b | c
 ---+---+---
  0 | 2 | 0
 (1 rows)
 {noformat}
 The last query should really return {{(0, 2, 0)}} and {{(0, 1, 1)}}.
 For that specific example we should generate 2 internal slices, but I believe 
 that with more clustering columns we may have more slices.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7846) Archive Commitlog Tests Failings

2014-08-29 Thread Philip Thompson (JIRA)


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

Philip Thompson updated CASSANDRA-7846:
---

  Assignee: Philip Thompson
Issue Type: Test  (was: Bug)

 Archive Commitlog Tests Failings
 

 Key: CASSANDRA-7846
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7846
 Project: Cassandra
  Issue Type: Test
 Environment: OSX and Ubuntu 14.04
Reporter: Philip Thompson
Assignee: Philip Thompson

 Four of the snapshot_test.py:TestArchiveCommitlog tests are failing on 2.1.0 
 and 2.1-HEAD:
 http://cassci.datastax.com/job/cassandra-2.1.0_dtest/lastCompletedBuild/testReport/snapshot_test/
 The tests restore archived commit logs and check how many rows exist after 
 restoring. They are passing on 2.0-HEAD.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CASSANDRA-7422) Logging for Authentication and Authorization

2014-08-29 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko resolved CASSANDRA-7422.
--

   Resolution: Not a Problem
Fix Version/s: (was: 1.2.19)

Closing as Not a Problem, for now. If we decide to do it, eventually, I'd 
rather we went for a more complete comprehensive audit log solution.

In the meantime, you can subclass CassandraAuthorizer and wrap its methods with 
logging calls, as a reasonable clean solution.

 Logging for Authentication and Authorization
 

 Key: CASSANDRA-7422
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7422
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Adam Holmberg
Priority: Trivial
 Attachments: auth_logging_remote_host.patch.20140201020


 We would like to enable Cassandra to log authentication and authorization 
 change events. 
 This facilitates audits on access to certain data. As a side effect it would 
 also make it easier to notice ill-behaved clients connecting repeatedly.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7422) Logging for Authentication and Authorization

2014-08-29 Thread Adam Holmberg (JIRA)


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

Adam Holmberg commented on CASSANDRA-7422:
--

For the record, wrapping didn't really accomplish what they were after because 
there was no way to get at the client IP from that context. That was the entire 
point of the patch -- to get the client state over to the auth context so it 
could be logged.

I'm not going to hound it anymore since I'm not with the company asking for 
this.

 Logging for Authentication and Authorization
 

 Key: CASSANDRA-7422
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7422
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Adam Holmberg
Priority: Trivial
 Attachments: auth_logging_remote_host.patch.20140201020


 We would like to enable Cassandra to log authentication and authorization 
 change events. 
 This facilitates audits on access to certain data. As a side effect it would 
 also make it easier to notice ill-behaved clients connecting repeatedly.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7848) Additional keystore configurations for SSL with HSMs

2014-08-29 Thread Hendrik van Huyssteen (JIRA)

Hendrik van Huyssteen created CASSANDRA-7848:


 Summary: Additional keystore configurations for SSL with HSMs
 Key: CASSANDRA-7848
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7848
 Project: Cassandra
  Issue Type: Improvement
  Components: Config
Reporter: Hendrik van Huyssteen
Priority: Minor


In order to use Cassandra with a Hardware Security Module (HSM) for encrypted 
communications, additional configuration options are required in terms of 
keystore configurations. 

A user configuring Cassandra must be able to:
# Specify the truststore and keystore type independently (eg. keystore would be 
in hardware and truststore in software)
# Specify the desired certificate and private key entry that should be used, by 
setting an alias
# Specify the keystore and keypair passwords independently
 
At the moment Cassandra only allows:
# A global keystore type
# Expects one keypair per keystore and
# Uses the same password for the keystore and keypair
 
The appropriate changes have been made to Cassandra 1.2 to support the above 
mentioned configuration.

The proposed cassandra.yaml would then look as follows, with the new changes 
marked with *:
{noformat}
server_encryption_options:
internode_encryption: all
keystore: path to keystore
keystore_password: password of keystore
store_type: hsm storetype
*keystore_entry_alias: alias of key entry in keystore to use*
*keystore_entry_password: password of key entry in keystore to use*
 
truststore: path to truststore
truststore_password: password of truststore
# More advanced defaults below:
# protocol: TLS
*truststore_type: JKS*
# cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
{noformat}
 
In terms of backwards compatibility, the following defaults should be used for 
the newly proposed settings:
* truststore_type = store_type;
* keystore_entry_password = keystore_password;
* keystore_entry_alias = autoselect

Example use case with HSM:
* Keystore is stored in HSM.
* store_type is set to the HSM store type.
* keystore_password is set to the slot password of the HSM.
* keystore_entry_password set to the keypair password.
* Truststore is stored on disk, with type set to JKS. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7848) Additional keystore configurations for SSL with HSMs

2014-08-29 Thread Hendrik van Huyssteen (JIRA)


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

Hendrik van Huyssteen commented on CASSANDRA-7848:
--

Patch to be submitted soon. Comments are welcome in the meantime.

 Additional keystore configurations for SSL with HSMs
 

 Key: CASSANDRA-7848
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7848
 Project: Cassandra
  Issue Type: Improvement
  Components: Config
Reporter: Hendrik van Huyssteen
Priority: Minor

 In order to use Cassandra with a Hardware Security Module (HSM) for encrypted 
 communications, additional configuration options are required in terms of 
 keystore configurations. 
 A user configuring Cassandra must be able to:
 # Specify the truststore and keystore type independently (eg. keystore would 
 be in hardware and truststore in software)
 # Specify the desired certificate and private key entry that should be used, 
 by setting an alias
 # Specify the keystore and keypair passwords independently
  
 At the moment Cassandra only allows:
 # A global keystore type
 # Expects one keypair per keystore and
 # Uses the same password for the keystore and keypair
  
 The appropriate changes have been made to Cassandra 1.2 to support the above 
 mentioned configuration.
 The proposed cassandra.yaml would then look as follows, with the new changes 
 marked with *:
 {noformat}
 server_encryption_options:
 internode_encryption: all
 keystore: path to keystore
 keystore_password: password of keystore
 store_type: hsm storetype
 *keystore_entry_alias: alias of key entry in keystore to use*
 *keystore_entry_password: password of key entry in keystore to use*
  
 truststore: path to truststore
 truststore_password: password of truststore
 # More advanced defaults below:
 # protocol: TLS
 *truststore_type: JKS*
 # cipher_suites: 
 [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
 {noformat}
  
 In terms of backwards compatibility, the following defaults should be used 
 for the newly proposed settings:
 * truststore_type = store_type;
 * keystore_entry_password = keystore_password;
 * keystore_entry_alias = autoselect
 Example use case with HSM:
 * Keystore is stored in HSM.
 * store_type is set to the HSM store type.
 * keystore_password is set to the slot password of the HSM.
 * keystore_entry_password set to the keypair password.
 * Truststore is stored on disk, with type set to JKS. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7159) sstablemetadata command should print some more stuff


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

Jonathan Ellis updated CASSANDRA-7159:
--

Reviewer: Jeremiah Jordan

[~jjordan] to review

 sstablemetadata command should print some more stuff
 

 Key: CASSANDRA-7159
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7159
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Vladislav Sinjavin
Priority: Trivial
  Labels: lhf
 Fix For: 2.0.11

 Attachments: 
 CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch


 It would be nice if the sstablemetadata command printed out some more of the 
 stuff we track.  Like the Min/Max column names and the min/max token in the 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7159) sstablemetadata command should print some more stuff

2014-08-29 Thread Vladislav Sinjavin (JIRA)


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

Vladislav Sinjavin commented on CASSANDRA-7159:
---

Hi Sylvain! 

Once more:)

Sorry in advance for many questions. Trying to understand about the 
CellNameType comparator. As I see right now there is many implementations of 
this interface. How to correct create this instance to deserialize ByteBuffer?

I was trying in that way:
 CompositeType composite = CompositeType.getInstance(Arrays.asList(new 
AbstractType?[]{UTF8Type.instance, UTF8Type.instance}));
 CellNameType cellNameType = CellNames.fromAbstractType(composite, false);

But it didn't help.


 sstablemetadata command should print some more stuff
 

 Key: CASSANDRA-7159
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7159
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Vladislav Sinjavin
Priority: Trivial
  Labels: lhf
 Fix For: 2.0.11

 Attachments: 
 CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch


 It would be nice if the sstablemetadata command printed out some more of the 
 stuff we track.  Like the Min/Max column names and the min/max token in the 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7159) sstablemetadata command should print some more stuff

2014-08-29 Thread Vladislav Sinjavin (JIRA)


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

Vladislav Sinjavin edited comment on CASSANDRA-7159 at 8/29/14 2:51 PM:


Hi Sylvain! 

Once more:)

Sorry in advance for many questions. Trying to understand about the 
CellNameType comparator. As I see right now there is many implementations of 
this interface. How to correct create this instance to deserialize ByteBuffer?

I was trying in that way:
 CompositeType composite = CompositeType.getInstance(Arrays.asList(new 
AbstractType?[]{UTF8Type.instance, UTF8Type.instance}));
 CellNameType cellNameType = CellNames.fromAbstractType(composite, false);

But it didn't help.

Another way to get comparator is to get from CFMetaData, but I can't see any 
chance to get instance of this object with the help of descriptor of data file.



was (Author: vsinjavin):
Hi Sylvain! 

Once more:)

Sorry in advance for many questions. Trying to understand about the 
CellNameType comparator. As I see right now there is many implementations of 
this interface. How to correct create this instance to deserialize ByteBuffer?

I was trying in that way:
 CompositeType composite = CompositeType.getInstance(Arrays.asList(new 
AbstractType?[]{UTF8Type.instance, UTF8Type.instance}));
 CellNameType cellNameType = CellNames.fromAbstractType(composite, false);

But it didn't help.


 sstablemetadata command should print some more stuff
 

 Key: CASSANDRA-7159
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7159
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Vladislav Sinjavin
Priority: Trivial
  Labels: lhf
 Fix For: 2.0.11

 Attachments: 
 CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch


 It would be nice if the sstablemetadata command printed out some more of the 
 stuff we track.  Like the Min/Max column names and the min/max token in the 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7159) sstablemetadata command should print some more stuff

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

Sylvain Lebresne commented on CASSANDRA-7159:
-

I don't think we save the comparator in any sstable component so I don't think
there is a good way to get the comparator without reading the schema. And
reading the schema means that you'd only be able to run sstablemetadata on a
configured node of the cluster, which I'm not sure is a limitation we want to
add.

I guess the options are:
# we do require a configured node for sstablemetadata to run, and we read the
schema.
# we writes the column names bytes as hex. Not sure how useful that is but why
not.
# we start storing the comparator in the validation metadata, use that and
don't print anything on the column names if we don't have it.

I don't have a super strong opinion on which to do tbh, but 3) sounds
reasonable to me.

sstablemetadata command should print some more stuff

Key: CASSANDRA-7159
URL: https://issues.apache.org/jira/browse/CASSANDRA-7159
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Jeremiah Jordan
Assignee: Vladislav Sinjavin
Priority: Trivial
Labels: lhf
Fix For: 2.0.11

Attachments:
CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch

It would be nice if the sstablemetadata command printed out some more of the
stuff we track. Like the Min/Max column names and the min/max token in the
file.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7159) sstablemetadata command should print some more stuff


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

Brandon Williams commented on CASSANDRA-7159:
-

I think 2) is fine, since sstablemetadata is already in the cassandra-tools 
package, which means you should know what you're doing.

 sstablemetadata command should print some more stuff
 

 Key: CASSANDRA-7159
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7159
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Vladislav Sinjavin
Priority: Trivial
  Labels: lhf
 Fix For: 2.0.11

 Attachments: 
 CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch


 It would be nice if the sstablemetadata command printed out some more of the 
 stuff we track.  Like the Min/Max column names and the min/max token in the 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-4914) Aggregation functions in CQL

2014-08-29 Thread Benjamin Lerer (JIRA)


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

Benjamin Lerer updated CASSANDRA-4914:
--

Attachment: CASSANDRA-4914-V2.txt

This patch add:
1) the support for paging: data will be loaded in page in a similar way to 
count(*)
2) the support for count(columnName)

count(*) and count(columnName) are different in nature due to that it is not 
easy to use the same code for both. So I prefered to keep them separate for 
now.  

 Aggregation functions in CQL
 

 Key: CASSANDRA-4914
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4914
 Project: Cassandra
  Issue Type: New Feature
Reporter: Vijay
Assignee: Benjamin Lerer
  Labels: cql, docs
 Fix For: 3.0

 Attachments: CASSANDRA-4914-V2.txt, CASSANDRA-4914.txt


 The requirement is to do aggregation of data in Cassandra (Wide row of column 
 values of int, double, float etc).
 With some basic agree gate functions like AVG, SUM, Mean, Min, Max, etc (for 
 the columns within a row).
 Example:
 SELECT * FROM emp WHERE empID IN (130) ORDER BY deptID DESC;  
   
  empid | deptid | first_name | last_name | salary
 ---+++---+
130 |  3 | joe| doe   |   10.1
130 |  2 | joe| doe   |100
130 |  1 | joe| doe   |  1e+03
  
 SELECT sum(salary), empid FROM emp WHERE empID IN (130);  
   
  sum(salary) | empid
 -+
1110.1|  130



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7447) New sstable format with support for columnar layout

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

Sylvain Lebresne commented on CASSANDRA-7447:
-

bq. Any features not supported will require sticking with the old format until
we extend support to all C* functionality.

I'm not extremely fan of that part tbh. I would have a strong preference for
introducing a file format that is better that our current one (not very hard)
but is generic enough to cover everything, even if this means that it's not as
optimized for some workloads that it can possibly be. Which probably means a
row oriented approach first. We can then optimize some special cases later.

One reason is that I'd prefer not having to keep/maintain the existing file
format for multiple versions, but generally, it feels more sane to me to get
one format reasonably performant first, and then add special case/variants.
This would also delay the debate on how much we're willing to special the
sstable format for different workload, debate on which I'm not sure we all have
the same opinion, and debate that is currently somewhat clouded by the fact
that the existing format is really rather inefficient.

New sstable format with support for columnar layout
---

Key: CASSANDRA-7447
URL: https://issues.apache.org/jira/browse/CASSANDRA-7447
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Benedict
Assignee: Benedict
Labels: performance, storage
Fix For: 3.0

Attachments: ngcc-storage.odp

h2. Storage Format Proposal
C* has come a long way over the past few years, and unfortunately our storage
format hasn't kept pace with the data models we are now encouraging people to
utilise. This ticket proposes a collections of storage primitives that can be
combined to serve these data models more optimally.
It would probably help to first state the data model at the most abstract
level. We have a fixed three-tier structure: We have the partition key, the
clustering columns, and the data columns. Each have their own characteristics
and so require their own specialised treatment.
I should note that these changes will necessarily be delivered in stages, and
that we will be making some assumptions about what the most useful features
to support initially will be. Any features not supported will require
sticking with the old format until we extend support to all C* functionality.
h3. Partition Key
* This really has two components: the partition, and the value. Although the
partition is primarily used to distribute across nodes, it can also be used
to optimise lookups for a given key within a node
* Generally partitioning is by hash, and for the moment I want to focus this
ticket on the assumption that this is the case
* Given this, it makes sense to optimise our storage format to permit O(1)
searching of a given partition. It may be possible to achieve this with
little overhead based on the fact we store the hashes in order and know they
are approximately randomly distributed, as this effectively forms an
immutable contiguous split-ordered list (see Shalev/Shavit, or
CASSANDRA-7282), so we only need to store an amount of data based on how
imperfectly distributed the hashes are, or at worst a single value per block.
* This should completely obviate the need for a separate key-cache, which
will be relegated to supporting the old storage format only
h3. Primary Key / Clustering Columns
* Given we have a hierarchical data model, I propose the use of a
cache-oblivious trie
* The main advantage of the trie is that it is extremely compact and
_supports optimally efficient merges with other tries_ so that we can support
more efficient reads when multiple sstables are touched
* The trie will be preceded by a small amount of related data; the full
partition key, a timestamp epoch (for offset-encoding timestamps) and any
other partition level optimisation data, such as (potentially) a min/max
timestamp to abort merges earlier
* Initially I propose to limit the trie to byte-order comparable data types
only (the number of which we can expand through translations of the important
types that are not currently)
* Crucially the trie will also encapsulate any range tombstones, so that
these are merged early in the process and avoids re-iterating the same data
* Results in true bidirectional streaming without having to read entire range
into memory
h3. Values
There are generally two approaches to storing rows of data: columnar, or
row-oriented. The above two data structures can be combined with a value
storage scheme that is based on either. However, given the current model we
have of

[jira] [Updated] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled


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

Brandon Williams updated CASSANDRA-7239:


Priority: Critical  (was: Minor)

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled


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

Brandon Williams updated CASSANDRA-7239:


Fix Version/s: (was: 2.1.1)
   2.1.0

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled


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

Brandon Williams commented on CASSANDRA-7239:
-

It appears the root of the problem here is that we have a serious bookkeeping 
problem.  We only increment totalDiskSpaceUsed in DataTracker.replaceFlushed, 
which is to say that we only count flushed memtables.  This means if you do a 
compaction, even if the result isn't negative, your reported load is completely 
wrong:

{noformat}
root@bw-2:/srv/cassandra# du -sh /var/lib/cassandra/data/Keyspace1/
163M/var/lib/cassandra/data/Keyspace1/
root@bw-2:/srv/cassandra# bin/nodetool status
Note: Ownership information does not include topology; for complete 
information, specify a keyspace
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  AddressLoad   Tokens  OwnsHost ID   
Rack
UN  10.208.35.225  33.16 MB   256 100.0%  
ac9b6dd7-233e-4cd5-a7e0-bc9564871704  rack1
{noformat}

(33MB because that's the size this machine likes to flush at, and there was one 
flush after the compaction.)  It looks like we need to increment somewhere in 
compaction as well, probably CompactionTask completes.  This area isn't my 
forte, though.

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Minor
 Fix For: 2.1.0

 Attachments: nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled


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

Brandon Williams edited comment on CASSANDRA-7239 at 8/29/14 5:23 PM:
--

It appears the root of the problem here is that we have a serious bookkeeping 
problem.  We only increment totalDiskSpaceUsed in DataTracker.replaceFlushed, 
which is to say that we only count flushed memtables.  This means if you do a 
compaction, even if the result isn't negative, your reported load is completely 
wrong:

{noformat}
root@bw-2:/srv/cassandra# du -sh /var/lib/cassandra/data/Keyspace1/
163M/var/lib/cassandra/data/Keyspace1/
root@bw-2:/srv/cassandra# bin/nodetool status
Note: Ownership information does not include topology; for complete 
information, specify a keyspace
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  AddressLoad   Tokens  OwnsHost ID   
Rack
UN  10.208.35.225  33.16 MB   256 100.0%  
ac9b6dd7-233e-4cd5-a7e0-bc9564871704  rack1
{noformat}

(33MB because that's the size this machine likes to flush at, and there was one 
flush after the compaction.)  It looks like we need to increment somewhere in 
compaction as well, probably when CompactionTask completes.  This area isn't my 
forte, though.


was (Author: brandon.williams):
It appears the root of the problem here is that we have a serious bookkeeping 
problem.  We only increment totalDiskSpaceUsed in DataTracker.replaceFlushed, 
which is to say that we only count flushed memtables.  This means if you do a 
compaction, even if the result isn't negative, your reported load is completely 
wrong:

{noformat}
root@bw-2:/srv/cassandra# du -sh /var/lib/cassandra/data/Keyspace1/
163M/var/lib/cassandra/data/Keyspace1/
root@bw-2:/srv/cassandra# bin/nodetool status
Note: Ownership information does not include topology; for complete 
information, specify a keyspace
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  AddressLoad   Tokens  OwnsHost ID   
Rack
UN  10.208.35.225  33.16 MB   256 100.0%  
ac9b6dd7-233e-4cd5-a7e0-bc9564871704  rack1
{noformat}

(33MB because that's the size this machine likes to flush at, and there was one 
flush after the compaction.)  It looks like we need to increment somewhere in 
compaction as well, probably CompactionTask completes.  This area isn't my 
forte, though.

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7159) sstablemetadata command should print some more stuff

2014-08-29 Thread Jeremiah Jordan (JIRA)


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

Jeremiah Jordan commented on CASSANDRA-7159:


2) or 3) WFM.  Maybe 2) here and a new ticket to do 3) in 3.0? Since 3 requires 
a new sstable version?  Would be nice to have some schema stuff stored in the 
sstables, as the requirement to read schema exists for all of the sstable 
reading tools.  (And reading schema actually causes a commit log replay, so you 
have to do it with the node offline.)

 sstablemetadata command should print some more stuff
 

 Key: CASSANDRA-7159
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7159
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Vladislav Sinjavin
Priority: Trivial
  Labels: lhf
 Fix For: 2.0.11

 Attachments: 
 CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch


 It would be nice if the sstablemetadata command printed out some more of the 
 stuff we track.  Like the Min/Max column names and the min/max token in the 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled

2014-08-29 Thread Ryan McGuire (JIRA)


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

Ryan McGuire updated CASSANDRA-7239:


Reproduced In: 2.1 rc6, 2.1 beta2  (was: 2.1 beta2, 2.1 rc6)
   Tester: Ryan McGuire

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7847) Allow quoted identifiers for triggers' names

2014-08-29 Thread Mikhail Stepura (JIRA)


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

Mikhail Stepura updated CASSANDRA-7847:
---

Fix Version/s: (was: 2.1.1)
   2.1.0

 Allow quoted identifiers for triggers' names
 

 Key: CASSANDRA-7847
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7847
 Project: Cassandra
  Issue Type: Bug
Reporter: Mikhail Stepura
Assignee: Mikhail Stepura
Priority: Minor
 Fix For: 2.1.0

 Attachments: CASSANDRA-2.1-7847.patch


 Current implementation doesn't allow quoted/case sensitive identifiers for 
 triggers' names, and doesn't handle those names in case-insensitive manner  
 either.
 {code}
 mstepura-mac:cassandra mikhail$ bin/cqlsh
 Connected to Test Cluster at 127.0.0.1:9042.
 [cqlsh 5.0.1 | Cassandra 2.1.1-SNAPSHOT | CQL spec 3.2.0 | Native protocol v3]
 Use HELP for help.
 cqlsh use stress;
 cqlsh:stress create TRIGGER ZooZoo ON t1 USING  
 'org.apache.cassandra.triggers.InvertedIndex';
 ErrorMessage code=2000 [Syntax error in CQL query] message=line 1:15 
 mismatched input 'ZooZoo' expecting IDENT (create TRIGGER [ZooZo]o ON...)
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress create TRIGGER ZooZoo ON t1 USING  
 'org.apache.cassandra.triggers.InvertedIndex';
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER zoozoo ON stress.t1 ;
 code=2200 [Invalid query] message=Trigger zoozoo was not found
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER ZooZoo ON stress.t1 ;
 ErrorMessage code=2000 [Syntax error in CQL query] message=line 1:13 
 mismatched input 'ZooZoo' expecting IDENT (drop TRIGGER [ZooZo]o ON...)
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER ZooZoo ON stress.t1 ;
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7847) Allow quoted identifiers for triggers' names

2014-08-29 Thread Mikhail Stepura (JIRA)


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

Mikhail Stepura updated CASSANDRA-7847:
---

Reproduced In: 2.0.10  (was: 2.1.1)

 Allow quoted identifiers for triggers' names
 

 Key: CASSANDRA-7847
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7847
 Project: Cassandra
  Issue Type: Bug
Reporter: Mikhail Stepura
Assignee: Mikhail Stepura
Priority: Minor
 Fix For: 2.1.0

 Attachments: CASSANDRA-2.1-7847.patch


 Current implementation doesn't allow quoted/case sensitive identifiers for 
 triggers' names, and doesn't handle those names in case-insensitive manner  
 either.
 {code}
 mstepura-mac:cassandra mikhail$ bin/cqlsh
 Connected to Test Cluster at 127.0.0.1:9042.
 [cqlsh 5.0.1 | Cassandra 2.1.1-SNAPSHOT | CQL spec 3.2.0 | Native protocol v3]
 Use HELP for help.
 cqlsh use stress;
 cqlsh:stress create TRIGGER ZooZoo ON t1 USING  
 'org.apache.cassandra.triggers.InvertedIndex';
 ErrorMessage code=2000 [Syntax error in CQL query] message=line 1:15 
 mismatched input 'ZooZoo' expecting IDENT (create TRIGGER [ZooZo]o ON...)
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress create TRIGGER ZooZoo ON t1 USING  
 'org.apache.cassandra.triggers.InvertedIndex';
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER zoozoo ON stress.t1 ;
 code=2200 [Invalid query] message=Trigger zoozoo was not found
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER ZooZoo ON stress.t1 ;
 ErrorMessage code=2000 [Syntax error in CQL query] message=line 1:13 
 mismatched input 'ZooZoo' expecting IDENT (drop TRIGGER [ZooZo]o ON...)
 cqlsh:stress
 cqlsh:stress
 cqlsh:stress drop TRIGGER ZooZoo ON stress.t1 ;
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled

2014-08-29 Thread Marcus Eriksson (JIRA)


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

Marcus Eriksson updated CASSANDRA-7239:
---

Attachment: 0001-add-new-sstable-size-when-rewriting.patch

we never add the size of the new sstables when using the sstable rewriter, 
patch does that

we could be more fancy here, decreasing live size every time we open early etc, 
will create a ticket for that, but this seems to fix the issue atleast

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-add-new-sstable-size-when-rewriting.patch, 
 nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled


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

Brandon Williams commented on CASSANDRA-7239:
-

Still seeing a decent amount of discrepancy:

{noformat}
root@bw-2:/srv/cassandra# du -sh 
/var/lib/cassandra/data/Keyspace1/Standard1-967836f02fbe11e4ae61517bcdb23258/
9.7G
/var/lib/cassandra/data/Keyspace1/Standard1-967836f02fbe11e4ae61517bcdb23258/
root@bw-2:/srv/cassandra# bin/nodetool status
Note: Ownership information does not include topology; for complete 
information, specify a keyspace
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  AddressLoad   Tokens  OwnsHost ID   
Rack
UN  10.208.35.225  6.59 GB256 100.0%  
43ab5b6b-7248-4960-911f-bd8620ca83a6  rack1
{noformat}

But no negative load.

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-add-new-sstable-size-when-rewriting.patch, 
 nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled


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

Jonathan Ellis commented on CASSANDRA-7239:
---

No tmp or snapshots?

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-add-new-sstable-size-when-rewriting.patch, 
 nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled


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

Brandon Williams commented on CASSANDRA-7239:
-

Nope, but it matches now, so I guess it's just eventually consistent.

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-add-new-sstable-size-when-rewriting.patch, 
 nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7849) Server logged error messages for unexpected exceptions could be more helpful

graham sanderson created CASSANDRA-7849:
---

 Summary: Server logged error messages for unexpected exceptions 
could be more helpful
 Key: CASSANDRA-7849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7849
 Project: Cassandra
  Issue Type: Improvement
Reporter: graham sanderson


From time to time (actually quite frequently) we get error messages in the 
server logs like this

{code}
ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 ErrorMessage.java 
(line 222) Unexpected exception during request
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

These particular cases are almost certainly problems with the client driver, 
client machine, client process, however after the fact this particular 
exception is practically impossible to debug



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7849) Server logged error messages for unexpected exceptions could be more helpful


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

graham sanderson updated CASSANDRA-7849:


Description: 
From time to time (actually quite frequently) we get error messages in the 
server logs like this

{code}
ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 ErrorMessage.java 
(line 222) Unexpected exception during request
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

These particular cases are almost certainly problems with the client driver, 
client machine, client process, however after the fact this particular 
exception is practically impossible to debug because there is no indication in 
the underlying JVM/netty exception of who the peer was

  was:
From time to time (actually quite frequently) we get error messages in the 
server logs like this

{code}
ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 ErrorMessage.java 
(line 222) Unexpected exception during request
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

These particular cases are almost certainly problems with the client driver, 
client machine, client process, however after the fact this particular 
exception is practically impossible to debug


 Server logged error messages for unexpected exceptions could be more helpful
 

 Key: CASSANDRA-7849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7849
 Project: Cassandra
  Issue Type: Improvement
Reporter: graham sanderson

 From time to time (actually quite frequently) we get error messages in the 
 server logs like this
 {code}
 ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 
 ErrorMessage.java (line 222) Unexpected exception during request
 java.io.IOException: Connection reset by peer
 at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
 at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
 at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
 at sun.nio.ch.IOUtil.read(IOUtil.java:192)
 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at

[jira] [Commented] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled


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

Jonathan Ellis commented on CASSANDRA-7239:
---

[~krummas] where does the rewriter decrement out the space from the old 
sstables?

 Nodetool Status Reports Negative Load With VNodes Disabled
 --

 Key: CASSANDRA-7239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Critical
 Fix For: 2.1.0

 Attachments: 0001-add-new-sstable-size-when-rewriting.patch, 
 nodetool.png, opscenter.png


 When I run stress on a large cluster without vnodes (num_token =1 initial 
 token set) The loads reported by nodetool status are negative, or become 
 negative after stress is run.
 {code}
 UN  10.97.155.31-447426217 bytes  1   0.2%
 8d40568c-044c-4753-be26-4ab62710beba  rack1   

 UN  10.9.132.53 -447342449 bytes  1   0.2%
 58e7f255-803d-493b-a19e-58137466fb78  rack1   

 UN  10.37.151.202   -447298672 bytes  1   0.2%
 ba29b1f1-186f-45d0-9e59-6a528db8df5d  rack1  
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7849) Server logged error messages for unexpected exceptions could be more helpful


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

graham sanderson commented on CASSANDRA-7849:
-

Unless anyone objects, or has a better idea, I'll make a patch

 Server logged error messages for unexpected exceptions could be more helpful
 

 Key: CASSANDRA-7849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7849
 Project: Cassandra
  Issue Type: Improvement
Reporter: graham sanderson

 From time to time (actually quite frequently) we get error messages in the 
 server logs like this
 {code}
 ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 
 ErrorMessage.java (line 222) Unexpected exception during request
 java.io.IOException: Connection reset by peer
 at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
 at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
 at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
 at sun.nio.ch.IOUtil.read(IOUtil.java:192)
 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 {code}
 These particular cases are almost certainly problems with the client driver, 
 client machine, client process, however after the fact this particular 
 exception is practically impossible to debug because there is no indication 
 in the underlying JVM/netty exception of who the peer was



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7849) Server logged error messages for unexpected exceptions could be more helpful


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

graham sanderson commented on CASSANDRA-7849:
-

Given that this is logging is a side effect of 
{{org.apache.cassandra.transport.messages.fromException(Throwable e)}} for 
unexpected exception types, and yet the caller generally has some useful 
context, my suggestion would be to add an optional {{Object context}} argument 
that could be {{.toString}}-ed into the error message if present.

i.e. in this case (the one we are seeing)

{code}
@Override
public void exceptionCaught(final ChannelHandlerContext ctx, 
ExceptionEvent e)
throws Exception
{
if (ctx.getChannel().isOpen())
{
ChannelFuture future = 
ctx.getChannel().write(ErrorMessage.fromException(e.getCause()));
// On protocol exception, close the channel as soon as the 
message have been sent
if (e.getCause() instanceof ProtocolException)
{
future.addListener(new ChannelFutureListener() {
public void operationComplete(ChannelFuture future) {
ctx.getChannel().close();
}
});
}
}
}
{code}

do

{code}
ChannelFuture future = 
ctx.getChannel().write(ErrorMessage.fromException(e.getCause(), 
ctx.getChannel()));
{code}

 Server logged error messages for unexpected exceptions could be more helpful
 

 Key: CASSANDRA-7849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7849
 Project: Cassandra
  Issue Type: Improvement
Reporter: graham sanderson

 From time to time (actually quite frequently) we get error messages in the 
 server logs like this
 {code}
 ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 
 ErrorMessage.java (line 222) Unexpected exception during request
 java.io.IOException: Connection reset by peer
 at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
 at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
 at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
 at sun.nio.ch.IOUtil.read(IOUtil.java:192)
 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 {code}
 These particular cases are almost certainly problems with the client driver, 
 client machine, client process, however after the fact this particular 
 exception is practically impossible to debug because there is no indication 
 in the underlying JVM/netty exception of who the peer was



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7849) Server logged error messages for unexpected exceptions could be more helpful


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

graham sanderson updated CASSANDRA-7849:


Description: 
From time to time (actually quite frequently) we get error messages in the 
server logs like this

{code}
ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 ErrorMessage.java 
(line 222) Unexpected exception during request
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

These particular cases are almost certainly problems with the client driver, 
client machine, client process, however after the fact this particular 
exception is practically impossible to debug because there is no indication in 
the underlying JVM/netty exception of who the peer was. I should note we have 
lots of different types of applications running against the cluster so it is 
very hard to correlate these to anything

  was:
From time to time (actually quite frequently) we get error messages in the 
server logs like this

{code}
ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 ErrorMessage.java 
(line 222) Unexpected exception during request
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

These particular cases are almost certainly problems with the client driver, 
client machine, client process, however after the fact this particular 
exception is practically impossible to debug because there is no indication in 
the underlying JVM/netty exception of who the peer was


 Server logged error messages for unexpected exceptions could be more helpful
 

 Key: CASSANDRA-7849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7849
 Project: Cassandra
  Issue Type: Improvement
Reporter: graham sanderson

 From time to time (actually quite frequently) we get error messages in the 
 server logs like this
 {code}
 ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 
 ErrorMessage.java (line 222) Unexpected exception during request
 java.io.IOException: Connection reset by peer
 at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
 at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
 at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
 at sun.nio.ch.IOUtil.read(IOUtil.java:192)
 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
 at

[jira] [Created] (CASSANDRA-7850) Composite Aware Partitioner

Drew Kutcharian created CASSANDRA-7850:
--

 Summary: Composite Aware Partitioner
 Key: CASSANDRA-7850
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7850
 Project: Cassandra
  Issue Type: Improvement
Reporter: Drew Kutcharian


Since C* supports composites for partition keys, I think it'd be useful to have 
the ability to only use first (or first few) components of the key to calculate 
the token hash.

A naive use case would be multi-tenancy:

Say we have accounts and accounts have users. So we would have the following 
tables:

{code}
CREATE TABLE account (
  id timeuuid PRIMARY KEY,
  company text
);
{code}

{code}
CREATE TABLE user (
  id  timeuuid PRIMARY KEY, 
  accountId timeuuid,
  emailtext,
  password text
);
{code}

{code}
// Get users by account
CREATE TABLE user_account_index (
  accountId  timeuuid,
  userIdtimeuuid,
  PRIMARY KEY(acid, id)
);
{code}

Say we want to get all the users that belong to an account. We would first have 
to get the results from user_account_index and then use a multi-get (WHERE IN) 
to get the records from user table. Now this multi-get part could potentially 
query a lot of different nodes in the cluster. It’d be great if there was a way 
to limit storage of users of an account to a single node so that way multi-get 
would only need to query a single node.

With this improvement we would be able to define the user table like so:
{code}
CREATE TABLE user (
  id  timeuuid, 
  accountId timeuuid,
  emailtext,
  password text,
  PRIMARY KEY(((accountId),id))  //extra parentheses
);
{code}

I'm not too sure about the notation, it could be something like PRIMARY 
KEY(((accountId),id)) where the (accountId) means use this part to calculate 
the hash and ((accountId),id) is the actual partition key.

The main complication I see with this is that we would have to use the table 
definition when calculating hashes so we know what components of the partition 
keys need to be used for hash calculation.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CASSANDRA-7850) Composite Aware Partitioner


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

Jonathan Ellis resolved CASSANDRA-7850.
---

Resolution: Invalid

There's already a way to distinguish primary key components from partition key 
components.  

http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/refCompositePk.html

 Composite Aware Partitioner
 ---

 Key: CASSANDRA-7850
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7850
 Project: Cassandra
  Issue Type: Improvement
Reporter: Drew Kutcharian

 Since C* supports composites for partition keys, I think it'd be useful to 
 have the ability to only use first (or first few) components of the key to 
 calculate the token hash.
 A naive use case would be multi-tenancy:
 Say we have accounts and accounts have users. So we would have the following 
 tables:
 {code}
 CREATE TABLE account (
   id timeuuid PRIMARY KEY,
   company text
 );
 {code}
 {code}
 CREATE TABLE user (
   id  timeuuid PRIMARY KEY, 
   accountId timeuuid,
   emailtext,
   password text
 );
 {code}
 {code}
 // Get users by account
 CREATE TABLE user_account_index (
   accountId  timeuuid,
   userIdtimeuuid,
   PRIMARY KEY(acid, id)
 );
 {code}
 Say we want to get all the users that belong to an account. We would first 
 have to get the results from user_account_index and then use a multi-get 
 (WHERE IN) to get the records from user table. Now this multi-get part could 
 potentially query a lot of different nodes in the cluster. It’d be great if 
 there was a way to limit storage of users of an account to a single node so 
 that way multi-get would only need to query a single node.
 With this improvement we would be able to define the user table like so:
 {code}
 CREATE TABLE user (
   id  timeuuid, 
   accountId timeuuid,
   emailtext,
   password text,
   PRIMARY KEY(((accountId),id))  //extra parentheses
 );
 {code}
 I'm not too sure about the notation, it could be something like PRIMARY 
 KEY(((accountId),id)) where the (accountId) means use this part to 
 calculate the hash and ((accountId),id) is the actual partition key.
 The main complication I see with this is that we would have to use the table 
 definition when calculating hashes so we know what components of the 
 partition keys need to be used for hash calculation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Reopened] (CASSANDRA-7850) Composite Aware Partitioner


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

Drew Kutcharian reopened CASSANDRA-7850:



Hi [~jbellis], I think you misunderstood this JIRA or more likely I didn't 
explain it properly.

In the link that you provided:

bq. Generally, Cassandra will store columns having the same block_id but a 
different breed on different nodes, and columns having the same block_id and 
breed on the same node.

The point of this JIRA is to be able to store columns having the _same_ 
block_id but different breeds on the same node. (Think wide row sharding)

 Composite Aware Partitioner
 ---

 Key: CASSANDRA-7850
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7850
 Project: Cassandra
  Issue Type: Improvement
Reporter: Drew Kutcharian

 Since C* supports composites for partition keys, I think it'd be useful to 
 have the ability to only use first (or first few) components of the key to 
 calculate the token hash.
 A naive use case would be multi-tenancy:
 Say we have accounts and accounts have users. So we would have the following 
 tables:
 {code}
 CREATE TABLE account (
   id timeuuid PRIMARY KEY,
   company text
 );
 {code}
 {code}
 CREATE TABLE user (
   id  timeuuid PRIMARY KEY, 
   accountId timeuuid,
   emailtext,
   password text
 );
 {code}
 {code}
 // Get users by account
 CREATE TABLE user_account_index (
   accountId  timeuuid,
   userIdtimeuuid,
   PRIMARY KEY(acid, id)
 );
 {code}
 Say we want to get all the users that belong to an account. We would first 
 have to get the results from user_account_index and then use a multi-get 
 (WHERE IN) to get the records from user table. Now this multi-get part could 
 potentially query a lot of different nodes in the cluster. It’d be great if 
 there was a way to limit storage of users of an account to a single node so 
 that way multi-get would only need to query a single node.
 With this improvement we would be able to define the user table like so:
 {code}
 CREATE TABLE user (
   id  timeuuid, 
   accountId timeuuid,
   emailtext,
   password text,
   PRIMARY KEY(((accountId),id))  //extra parentheses
 );
 {code}
 I'm not too sure about the notation, it could be something like PRIMARY 
 KEY(((accountId),id)) where the (accountId) means use this part to 
 calculate the hash and ((accountId),id) is the actual partition key.
 The main complication I see with this is that we would have to use the table 
 definition when calculating hashes so we know what components of the 
 partition keys need to be used for hash calculation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7840) Refactor static state functions into static singletons

2014-08-29 Thread Blake Eggleston (JIRA)


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

Blake Eggleston updated CASSANDRA-7840:
---

Attachment: 0040-AtomicBtreeColumns-replacing-SystemKeyspace-CFMetaDa.patch
0039-CounterId-removing-static-singleton-accesses-from-st.patch
0038-UTMetaData-refactoring-static-singleton-accesses-for.patch
0037-SystemKeyspace-moving-system-keyspace-definitions-on.patch
0036-KSMetaData-splitting-off-static-factory-methods-onto.patch
0035-CFMetaData-splitting-off-static-factory-methods-onto.patch
0034-TriggerDefinition-removing-static-singleton-access-f.patch
0033-ColumnFamilyStore-splitting-static-factory-methods-a.patch
0032-Keyspace-splitting-static-factory-methods-and-state-.patch
0031-SSTableReader-splitting-static-factory-methods-into-.patch
0030-ClientState-splitting-configured-QueryHandler-instan.patch
0029-CompactionMetrics-making-static-method-instance-meth.patch
0028-Cassandra-PasswordAuthenticator-making-static-method.patch
0027-OutboundTcpConnectionPool-removing-static-singleton-.patch
0026-TokenMetadata-removing-static-singleton-access-from-.patch
0025-ResourceWatcher-removing-static-singleton-access-fro.patch
0024-FileUtils-removing-static-singleton-accesses-from-st.patch
0023-StorageServiceAccessor-removing-static-singleton-acc.patch
0022-AbstractReadExecutor-removing-static-method.patch
0021-RowDataResolver-removing-static-singleton-access-fro.patch
0020-ActiveRepairService-removing-static-members-and-meth.patch
0019-PendingRangeCalculatorService-removing-singleton-acc.patch
0018-FBUtilities-removing-getLocalAddress-getBroadcastAdd.patch
0017-OutboundTcpConnection-removing-singleton-access-from.patch
0016-removing-static-method-from-CommitLog.patch
0015-removing-static-state-from-BatchlogManager.patch
0014-refactoring-static-methods-on-Tracing.patch

Uploading the second round of patches. Unless I've missed something, this 
should complete the first step.

Static methods that access static singletons have been converted to instance 
methods where appropriate, or are now taking their singleton dependencies as 
arguments. In some cases, they were split off into factory classes. The ones 
that were split off into factory classes will end up passing dependencies into 
the classes they're instantiating. Having a factory is easier than passing a 
ton of arguments in each time, and a few of them have a small amount of state 
that was static.

I've also moved the system keyspace CFMetaData instances into the 
SystemKeyspace class. I did this because the CFMetaData can be compiled using 
just a QueryProcessor instance, and rolling it into the CFMetaDataFactory would 
likely ended up in a dependency loop, because it depends on singletons that 
depend on the SystemKeyspace.

Finally, the AtomicBTreeColumns class was using the system's IndexCf to 
estimate it's empty size, so I switched it to a throwaway CFMetaData instance. 
I'm assuming that the IndexCf was being used out of convenience, but let me 
know if I'm wrong, and I'll rework it.

 Refactor static state  functions into static singletons
 

 Key: CASSANDRA-7840
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7840
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Blake Eggleston
  Labels: patch
 Attachments: 
 0001-splitting-StorageService-executors-into-a-separate-c.patch, 
 0002-making-DatabaseDescriptor-a-singleton.patch, 
 0003-refactoring-StorageService-static-methods.patch, 
 0004-making-StorageProxy-a-singleton.patch, 
 0005-making-MigrationManager-a-singleton.patch, 
 0006-making-SystemKeyspace-a-singleton.patch, 
 0007-making-Auth-a-singleton.patch, 
 0008-removing-static-methods-and-initialization-from-Comp.patch, 
 0009-making-SinkManager-a-singleton.patch, 
 0010-making-DefsTables-a-singleton.patch, 
 0011-making-StageManager-a-singleton.patch, 
 0012-making-MessagingService-a-singleton.patch, 
 0013-making-QueryProcessor-a-singleton.patch, 
 0014-refactoring-static-methods-on-Tracing.patch, 
 0014-refactoring-static-methods-on-Tracing.patch, 
 0015-removing-static-state-from-BatchlogManager.patch, 
 0016-removing-static-method-from-CommitLog.patch, 
 0017-OutboundTcpConnection-removing-singleton-access-from.patch, 
 0018-FBUtilities-removing-getLocalAddress-getBroadcastAdd.patch, 
 0019-PendingRangeCalculatorService-removing-singleton-acc.patch,

[jira] [Updated] (CASSANDRA-7840) Refactor static state functions into static singletons

2014-08-29 Thread Blake Eggleston (JIRA)


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

Blake Eggleston updated CASSANDRA-7840:
---

Attachment: (was: 0014-refactoring-static-methods-on-Tracing.patch)

 Refactor static state  functions into static singletons
 

 Key: CASSANDRA-7840
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7840
 Project: Cassandra
  Issue Type: Sub-task
Reporter: Blake Eggleston
  Labels: patch
 Attachments: 
 0001-splitting-StorageService-executors-into-a-separate-c.patch, 
 0002-making-DatabaseDescriptor-a-singleton.patch, 
 0003-refactoring-StorageService-static-methods.patch, 
 0004-making-StorageProxy-a-singleton.patch, 
 0005-making-MigrationManager-a-singleton.patch, 
 0006-making-SystemKeyspace-a-singleton.patch, 
 0007-making-Auth-a-singleton.patch, 
 0008-removing-static-methods-and-initialization-from-Comp.patch, 
 0009-making-SinkManager-a-singleton.patch, 
 0010-making-DefsTables-a-singleton.patch, 
 0011-making-StageManager-a-singleton.patch, 
 0012-making-MessagingService-a-singleton.patch, 
 0013-making-QueryProcessor-a-singleton.patch, 
 0014-refactoring-static-methods-on-Tracing.patch, 
 0015-removing-static-state-from-BatchlogManager.patch, 
 0016-removing-static-method-from-CommitLog.patch, 
 0017-OutboundTcpConnection-removing-singleton-access-from.patch, 
 0018-FBUtilities-removing-getLocalAddress-getBroadcastAdd.patch, 
 0019-PendingRangeCalculatorService-removing-singleton-acc.patch, 
 0020-ActiveRepairService-removing-static-members-and-meth.patch, 
 0021-RowDataResolver-removing-static-singleton-access-fro.patch, 
 0022-AbstractReadExecutor-removing-static-method.patch, 
 0023-StorageServiceAccessor-removing-static-singleton-acc.patch, 
 0024-FileUtils-removing-static-singleton-accesses-from-st.patch, 
 0025-ResourceWatcher-removing-static-singleton-access-fro.patch, 
 0026-TokenMetadata-removing-static-singleton-access-from-.patch, 
 0027-OutboundTcpConnectionPool-removing-static-singleton-.patch, 
 0028-Cassandra-PasswordAuthenticator-making-static-method.patch, 
 0029-CompactionMetrics-making-static-method-instance-meth.patch, 
 0030-ClientState-splitting-configured-QueryHandler-instan.patch, 
 0031-SSTableReader-splitting-static-factory-methods-into-.patch, 
 0032-Keyspace-splitting-static-factory-methods-and-state-.patch, 
 0033-ColumnFamilyStore-splitting-static-factory-methods-a.patch, 
 0034-TriggerDefinition-removing-static-singleton-access-f.patch, 
 0035-CFMetaData-splitting-off-static-factory-methods-onto.patch, 
 0036-KSMetaData-splitting-off-static-factory-methods-onto.patch, 
 0037-SystemKeyspace-moving-system-keyspace-definitions-on.patch, 
 0038-UTMetaData-refactoring-static-singleton-accesses-for.patch, 
 0039-CounterId-removing-static-singleton-accesses-from-st.patch, 
 0040-AtomicBtreeColumns-replacing-SystemKeyspace-CFMetaDa.patch


 1st step of CASSANDRA-7837.
 Things like DatabaseDescriptor.getPartitioner() should become 
 DatabaseDescriptor.instance.getPartitioner(). In cases where there is a mix 
 of instance state and static functionality (Keyspace  ColumnFamilyStore 
 classes), the static portion should be split off into singleton factory 
 classes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7849) Server logged error messages (in binary protocol) for unexpected exceptions could be more helpful


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

graham sanderson updated CASSANDRA-7849:


Summary: Server logged error messages (in binary protocol) for unexpected 
exceptions could be more helpful  (was: Server logged error messages for 
unexpected exceptions could be more helpful)

 Server logged error messages (in binary protocol) for unexpected exceptions 
 could be more helpful
 -

 Key: CASSANDRA-7849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7849
 Project: Cassandra
  Issue Type: Improvement
Reporter: graham sanderson

 From time to time (actually quite frequently) we get error messages in the 
 server logs like this
 {code}
 ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 
 ErrorMessage.java (line 222) Unexpected exception during request
 java.io.IOException: Connection reset by peer
 at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
 at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
 at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
 at sun.nio.ch.IOUtil.read(IOUtil.java:192)
 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 {code}
 These particular cases are almost certainly problems with the client driver, 
 client machine, client process, however after the fact this particular 
 exception is practically impossible to debug because there is no indication 
 in the underlying JVM/netty exception of who the peer was. I should note we 
 have lots of different types of applications running against the cluster so 
 it is very hard to correlate these to anything



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7849) Server logged error messages (in binary protocol) for unexpected exceptions could be more helpful


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

graham sanderson edited comment on CASSANDRA-7849 at 8/30/14 12:49 AM:
---

Unless anyone objects, or has a better idea, I'll make a patch. Since there are 
7 uses, I'll just overload the fromException method and fix the places I know 
has a .toString-able object


was (Author: graham sanderson):
Unless anyone objects, or has a better idea, I'll make a patch

 Server logged error messages (in binary protocol) for unexpected exceptions 
 could be more helpful
 -

 Key: CASSANDRA-7849
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7849
 Project: Cassandra
  Issue Type: Improvement
Reporter: graham sanderson

 From time to time (actually quite frequently) we get error messages in the 
 server logs like this
 {code}
 ERROR [Native-Transport-Requests:288] 2014-08-29 04:48:07,118 
 ErrorMessage.java (line 222) Unexpected exception during request
 java.io.IOException: Connection reset by peer
 at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
 at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
 at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
 at sun.nio.ch.IOUtil.read(IOUtil.java:192)
 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
 at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
 at 
 org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 {code}
 These particular cases are almost certainly problems with the client driver, 
 client machine, client process, however after the fact this particular 
 exception is practically impossible to debug because there is no indication 
 in the underlying JVM/netty exception of who the peer was. I should note we 
 have lots of different types of applications running against the cluster so 
 it is very hard to correlate these to anything



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7850) Composite Aware Partitioner


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

Jonathan Ellis commented on CASSANDRA-7850:
---

Then you declare {{PRIMARY KEY (block_id, breed)}}

 Composite Aware Partitioner
 ---

 Key: CASSANDRA-7850
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7850
 Project: Cassandra
  Issue Type: Improvement
Reporter: Drew Kutcharian

 Since C* supports composites for partition keys, I think it'd be useful to 
 have the ability to only use first (or first few) components of the key to 
 calculate the token hash.
 A naive use case would be multi-tenancy:
 Say we have accounts and accounts have users. So we would have the following 
 tables:
 {code}
 CREATE TABLE account (
   id timeuuid PRIMARY KEY,
   company text
 );
 {code}
 {code}
 CREATE TABLE user (
   id  timeuuid PRIMARY KEY, 
   accountId timeuuid,
   emailtext,
   password text
 );
 {code}
 {code}
 // Get users by account
 CREATE TABLE user_account_index (
   accountId  timeuuid,
   userIdtimeuuid,
   PRIMARY KEY(acid, id)
 );
 {code}
 Say we want to get all the users that belong to an account. We would first 
 have to get the results from user_account_index and then use a multi-get 
 (WHERE IN) to get the records from user table. Now this multi-get part could 
 potentially query a lot of different nodes in the cluster. It’d be great if 
 there was a way to limit storage of users of an account to a single node so 
 that way multi-get would only need to query a single node.
 With this improvement we would be able to define the user table like so:
 {code}
 CREATE TABLE user (
   id  timeuuid, 
   accountId timeuuid,
   emailtext,
   password text,
   PRIMARY KEY(((accountId),id))  //extra parentheses
 );
 {code}
 I'm not too sure about the notation, it could be something like PRIMARY 
 KEY(((accountId),id)) where the (accountId) means use this part to 
 calculate the hash and ((accountId),id) is the actual partition key.
 The main complication I see with this is that we would have to use the table 
 definition when calculating hashes so we know what components of the 
 partition keys need to be used for hash calculation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7851) C* PID file should be readable by mere users


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

Michael Shuler updated CASSANDRA-7851:
--

Description: 
{noformat}
automaton@i-175d594e9:~$ service cassandra status
 * Cassandra is not running
automaton@i-175d594e9:~$ sudo service cassandra status
 * Cassandra is running
automaton@i-175d594e9:~$ ls -la /var/run/cassandra/
ls: cannot open directory /var/run/cassandra/: Permission denied
automaton@i-175d594e9:~$ sudo ls -la /var/run/cassandra/
total 4
drwxr-x---  2 cassandra cassandra  60 Aug 30 01:21 .
drwxr-xr-x 15 root  root  700 Aug 30 01:21 ..
-rw-r--r--  1 cassandra cassandra   4 Aug 30 01:21 cassandra.pid
{noformat}

  was:
automaton@i-175d594e9:~$ service cassandra status
 * Cassandra is not running
automaton@i-175d594e9:~$ sudo service cassandra status
 * Cassandra is running
automaton@i-175d594e9:~$ ls -la /var/run/cassandra/
ls: cannot open directory /var/run/cassandra/: Permission denied
automaton@i-175d594e9:~$ sudo ls -la /var/run/cassandra/
total 4
drwxr-x---  2 cassandra cassandra  60 Aug 30 01:21 .
drwxr-xr-x 15 root  root  700 Aug 30 01:21 ..
-rw-r--r--  1 cassandra cassandra   4 Aug 30 01:21 cassandra.pid


 C* PID file should be readable by mere users
 

 Key: CASSANDRA-7851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7851
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: Michael Shuler
Assignee: Michael Shuler
Priority: Minor

 {noformat}
 automaton@i-175d594e9:~$ service cassandra status
  * Cassandra is not running
 automaton@i-175d594e9:~$ sudo service cassandra status
  * Cassandra is running
 automaton@i-175d594e9:~$ ls -la /var/run/cassandra/
 ls: cannot open directory /var/run/cassandra/: Permission denied
 automaton@i-175d594e9:~$ sudo ls -la /var/run/cassandra/
 total 4
 drwxr-x---  2 cassandra cassandra  60 Aug 30 01:21 .
 drwxr-xr-x 15 root  root  700 Aug 30 01:21 ..
 -rw-r--r--  1 cassandra cassandra   4 Aug 30 01:21 cassandra.pid
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CASSANDRA-7851) C* PID file should be readable by mere users

Michael Shuler created CASSANDRA-7851:
-

 Summary: C* PID file should be readable by mere users
 Key: CASSANDRA-7851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7851
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: Michael Shuler
Assignee: Michael Shuler
Priority: Minor


automaton@i-175d594e9:~$ service cassandra status
 * Cassandra is not running
automaton@i-175d594e9:~$ sudo service cassandra status
 * Cassandra is running
automaton@i-175d594e9:~$ ls -la /var/run/cassandra/
ls: cannot open directory /var/run/cassandra/: Permission denied
automaton@i-175d594e9:~$ sudo ls -la /var/run/cassandra/
total 4
drwxr-x---  2 cassandra cassandra  60 Aug 30 01:21 .
drwxr-xr-x 15 root  root  700 Aug 30 01:21 ..
-rw-r--r--  1 cassandra cassandra   4 Aug 30 01:21 cassandra.pid



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7850) Composite Aware Partitioner


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

Drew Kutcharian commented on CASSANDRA-7850:


Yes, but then I might end up with very wide rows.

Basically what I want is {{PRIMARY KEY ((block_id, breed_bucket), breed)}} 
where records with same block_id and breed_bucket get stored on the same node, 
but in different _thrift_ rows so I don't have very wide rows (millions of 
_thrift_ columns per _thrift_ row). 

 Composite Aware Partitioner
 ---

 Key: CASSANDRA-7850
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7850
 Project: Cassandra
  Issue Type: Improvement
Reporter: Drew Kutcharian

 Since C* supports composites for partition keys, I think it'd be useful to 
 have the ability to only use first (or first few) components of the key to 
 calculate the token hash.
 A naive use case would be multi-tenancy:
 Say we have accounts and accounts have users. So we would have the following 
 tables:
 {code}
 CREATE TABLE account (
   id timeuuid PRIMARY KEY,
   company text
 );
 {code}
 {code}
 CREATE TABLE user (
   id  timeuuid PRIMARY KEY, 
   accountId timeuuid,
   emailtext,
   password text
 );
 {code}
 {code}
 // Get users by account
 CREATE TABLE user_account_index (
   accountId  timeuuid,
   userIdtimeuuid,
   PRIMARY KEY(acid, id)
 );
 {code}
 Say we want to get all the users that belong to an account. We would first 
 have to get the results from user_account_index and then use a multi-get 
 (WHERE IN) to get the records from user table. Now this multi-get part could 
 potentially query a lot of different nodes in the cluster. It’d be great if 
 there was a way to limit storage of users of an account to a single node so 
 that way multi-get would only need to query a single node.
 With this improvement we would be able to define the user table like so:
 {code}
 CREATE TABLE user (
   id  timeuuid, 
   accountId timeuuid,
   emailtext,
   password text,
   PRIMARY KEY(((accountId),id))  //extra parentheses
 );
 {code}
 I'm not too sure about the notation, it could be something like PRIMARY 
 KEY(((accountId),id)) where the (accountId) means use this part to 
 calculate the hash and ((accountId),id) is the actual partition key.
 The main complication I see with this is that we would have to use the table 
 definition when calculating hashes so we know what components of the 
 partition keys need to be used for hash calculation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CASSANDRA-7850) Composite Aware Partitioner


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

Drew Kutcharian edited comment on CASSANDRA-7850 at 8/30/14 2:00 AM:
-

Yes, but then I might end up with very wide _thrift_ rows.

Basically what I want is {{PRIMARY KEY ((block_id, breed_bucket), breed)}} 
where records with same block_id get stored on the same node *regardless* of 
the value of breed_bucket. But I don't want to use {{PRIMARY KEY (block_id, 
breed_bucket, breed)}} since in that case all the records for a block_id would 
end up in a single _thrift_ row.

So, ideally the layout would be:
block_id - decides the node
(block_id, breed_bucket) - decides the _thrift_ row. Old school row key
breed - prefix of _thrift_ columns. Old school column name prefix



was (Author: drew_kutchar):
Yes, but then I might end up with very wide rows.

Basically what I want is {{PRIMARY KEY ((block_id, breed_bucket), breed)}} 
where records with same block_id and breed_bucket get stored on the same node, 
but in different _thrift_ rows so I don't have very wide rows (millions of 
_thrift_ columns per _thrift_ row). 

 Composite Aware Partitioner
 ---

 Key: CASSANDRA-7850
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7850
 Project: Cassandra
  Issue Type: Improvement
Reporter: Drew Kutcharian

 Since C* supports composites for partition keys, I think it'd be useful to 
 have the ability to only use first (or first few) components of the key to 
 calculate the token hash.
 A naive use case would be multi-tenancy:
 Say we have accounts and accounts have users. So we would have the following 
 tables:
 {code}
 CREATE TABLE account (
   id timeuuid PRIMARY KEY,
   company text
 );
 {code}
 {code}
 CREATE TABLE user (
   id  timeuuid PRIMARY KEY, 
   accountId timeuuid,
   emailtext,
   password text
 );
 {code}
 {code}
 // Get users by account
 CREATE TABLE user_account_index (
   accountId  timeuuid,
   userIdtimeuuid,
   PRIMARY KEY(acid, id)
 );
 {code}
 Say we want to get all the users that belong to an account. We would first 
 have to get the results from user_account_index and then use a multi-get 
 (WHERE IN) to get the records from user table. Now this multi-get part could 
 potentially query a lot of different nodes in the cluster. It’d be great if 
 there was a way to limit storage of users of an account to a single node so 
 that way multi-get would only need to query a single node.
 With this improvement we would be able to define the user table like so:
 {code}
 CREATE TABLE user (
   id  timeuuid, 
   accountId timeuuid,
   emailtext,
   password text,
   PRIMARY KEY(((accountId),id))  //extra parentheses
 );
 {code}
 I'm not too sure about the notation, it could be something like PRIMARY 
 KEY(((accountId),id)) where the (accountId) means use this part to 
 calculate the hash and ((accountId),id) is the actual partition key.
 The main complication I see with this is that we would have to use the table 
 definition when calculating hashes so we know what components of the 
 partition keys need to be used for hash calculation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7851) C* PID file should be readable by mere users


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

Michael Shuler updated CASSANDRA-7851:
--

Attachment: 7851.txt

 C* PID file should be readable by mere users
 

 Key: CASSANDRA-7851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7851
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: Michael Shuler
Assignee: Michael Shuler
Priority: Minor
 Fix For: 2.0.11, 2.1.1

 Attachments: 7851.txt


 {noformat}
 automaton@i-175d594e9:~$ service cassandra status
  * Cassandra is not running
 automaton@i-175d594e9:~$ sudo service cassandra status
  * Cassandra is running
 automaton@i-175d594e9:~$ ls -la /var/run/cassandra/
 ls: cannot open directory /var/run/cassandra/: Permission denied
 automaton@i-175d594e9:~$ sudo ls -la /var/run/cassandra/
 total 4
 drwxr-x---  2 cassandra cassandra  60 Aug 30 01:21 .
 drwxr-xr-x 15 root  root  700 Aug 30 01:21 ..
 -rw-r--r--  1 cassandra cassandra   4 Aug 30 01:21 cassandra.pid
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7851) C* PID file should be readable by mere users


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

Michael Shuler updated CASSANDRA-7851:
--

Reviewer: Brandon Williams

 C* PID file should be readable by mere users
 

 Key: CASSANDRA-7851
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7851
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Reporter: Michael Shuler
Assignee: Michael Shuler
Priority: Minor
 Fix For: 2.0.11, 2.1.1

 Attachments: 7851.txt


 {noformat}
 automaton@i-175d594e9:~$ service cassandra status
  * Cassandra is not running
 automaton@i-175d594e9:~$ sudo service cassandra status
  * Cassandra is running
 automaton@i-175d594e9:~$ ls -la /var/run/cassandra/
 ls: cannot open directory /var/run/cassandra/: Permission denied
 automaton@i-175d594e9:~$ sudo ls -la /var/run/cassandra/
 total 4
 drwxr-x---  2 cassandra cassandra  60 Aug 30 01:21 .
 drwxr-xr-x 15 root  root  700 Aug 30 01:21 ..
 -rw-r--r--  1 cassandra cassandra   4 Aug 30 01:21 cassandra.pid
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory


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

graham sanderson updated CASSANDRA-7546:


Attachment: hint_spikes.png
young_gen_gc.png

I thought I'd attach an image of the correlation between the hint spikes and 
the massive memory allocation. There is a chicken and egg thing here, but if a 
node starts hinting heavily, it may become unresponsive causing a knock on 
effect.

Note on the yellow node, there was a period of about 500 seconds of young gen 
GC, which equates to about 3TB of garbage

 AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
 -

 Key: CASSANDRA-7546
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7546
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: graham sanderson
Assignee: graham sanderson
 Fix For: 2.1.1

 Attachments: 7546.20.txt, 7546.20_2.txt, 7546.20_3.txt, 
 7546.20_4.txt, 7546.20_5.txt, 7546.20_6.txt, 7546.20_7.txt, 7546.20_7b.txt, 
 7546.20_alt.txt, hint_spikes.png, suggestion1.txt, suggestion1_21.txt, 
 young_gen_gc.png


 In order to preserve atomicity, this code attempts to read, clone/update, 
 then CAS the state of the partition.
 Under heavy contention for updating a single partition this can cause some 
 fairly staggering memory growth (the more cores on your machine the worst it 
 gets).
 Whilst many usage patterns don't do highly concurrent updates to the same 
 partition, hinting today, does, and in this case wild (order(s) of magnitude 
 more than expected) memory allocation rates can be seen (especially when the 
 updates being hinted are small updates to different partitions which can 
 happen very fast on their own) - see CASSANDRA-7545
 It would be best to eliminate/reduce/limit the spinning memory allocation 
 whilst not slowing down the very common un-contended case.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory