[jira] [Assigned] (CASSANDRA-7637) Add CQL3 keyword for efficient lexical range queries (e.g. START_WITH)

[Sunil Kumar Singh (JIRA)]

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

Sunil Kumar Singh reassigned CASSANDRA-7637:


Assignee: Sunil Kumar Singh

 Add CQL3 keyword for efficient lexical range queries (e.g. START_WITH)
 --

 Key: CASSANDRA-7637
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7637
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Rustam Aliyev
Assignee: Sunil Kumar Singh
 Fix For: 3.0


 Currently, if I want to perform range query on lexical type I need to do 
 something like this:
 {code}
 SELECT * FROM profile WHERE profile_id = 123 AND
   attribute  'interests.food.' AND
   attribute  'interests.food.z';
 {code}
 This is very efficient range query. Yet, many users who are not familiar with 
 Thrift and storage level implementation are unaware of this trick.
 Therefore, it would be convenient to introduce CQL keyword which will do this 
 more simply:
 {code}
 SELECT * FROM profile WHERE profile_id = 123 AND
   attribute START_WITH('interests.food.');
 {code}
 Keyword would have same restrictions as other inequality search operators 
 plus some type restrictions.
 Allowed types would be:
  * {{ascii}}
  * {{text}} / {{varchar}}
  * {{maptext, *}} (same for ascii) (?)
  * {{settext}} (same for ascii) (?)
 (?) may require more work, therefore optional



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7637) Add CQL3 keyword for efficient lexical range queries (e.g. START_WITH)

[Sunil Kumar Singh (JIRA)]

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

Sunil Kumar Singh commented on CASSANDRA-7637:
--

I have started to looking into this Issue once understand  I will mark it as 
In Progress. If any more suggestion on requirement, Please make it clear.  

 Add CQL3 keyword for efficient lexical range queries (e.g. START_WITH)
 --

 Key: CASSANDRA-7637
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7637
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Rustam Aliyev
Assignee: Sunil Kumar Singh
 Fix For: 3.0


 Currently, if I want to perform range query on lexical type I need to do 
 something like this:
 {code}
 SELECT * FROM profile WHERE profile_id = 123 AND
   attribute  'interests.food.' AND
   attribute  'interests.food.z';
 {code}
 This is very efficient range query. Yet, many users who are not familiar with 
 Thrift and storage level implementation are unaware of this trick.
 Therefore, it would be convenient to introduce CQL keyword which will do this 
 more simply:
 {code}
 SELECT * FROM profile WHERE profile_id = 123 AND
   attribute START_WITH('interests.food.');
 {code}
 Keyword would have same restrictions as other inequality search operators 
 plus some type restrictions.
 Allowed types would be:
  * {{ascii}}
  * {{text}} / {{varchar}}
  * {{maptext, *}} (same for ascii) (?)
  * {{settext}} (same for ascii) (?)
 (?) may require more work, therefore optional



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-7637) Add CQL3 keyword for efficient lexical range queries (e.g. START_WITH)

[Sunil Kumar Singh (JIRA)]

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

Sunil Kumar Singh edited comment on CASSANDRA-7637 at 9/29/14 6:32 AM:
---

I have started looking into this Issue once understand. I will mark it as In 
Progress. If any more suggestion on requirement, Please make it clear.  


was (Author: sunil_cass_dev):
I have started looking into this Issue once understand  I will mark it as In 
Progress. If any more suggestion on requirement, Please make it clear.  

 Add CQL3 keyword for efficient lexical range queries (e.g. START_WITH)
 --

 Key: CASSANDRA-7637
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7637
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Rustam Aliyev
Assignee: Sunil Kumar Singh
 Fix For: 3.0


 Currently, if I want to perform range query on lexical type I need to do 
 something like this:
 {code}
 SELECT * FROM profile WHERE profile_id = 123 AND
   attribute  'interests.food.' AND
   attribute  'interests.food.z';
 {code}
 This is very efficient range query. Yet, many users who are not familiar with 
 Thrift and storage level implementation are unaware of this trick.
 Therefore, it would be convenient to introduce CQL keyword which will do this 
 more simply:
 {code}
 SELECT * FROM profile WHERE profile_id = 123 AND
   attribute START_WITH('interests.food.');
 {code}
 Keyword would have same restrictions as other inequality search operators 
 plus some type restrictions.
 Allowed types would be:
  * {{ascii}}
  * {{text}} / {{varchar}}
  * {{maptext, *}} (same for ascii) (?)
  * {{settext}} (same for ascii) (?)
 (?) may require more work, therefore optional



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-7637) Add CQL3 keyword for efficient lexical range queries (e.g. START_WITH)

[Sunil Kumar Singh (JIRA)]

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

Sunil Kumar Singh edited comment on CASSANDRA-7637 at 9/29/14 6:31 AM:
---

I have started looking into this Issue once understand  I will mark it as In 
Progress. If any more suggestion on requirement, Please make it clear.  


was (Author: sunil_cass_dev):
I have started to looking into this Issue once understand  I will mark it as 
In Progress. If any more suggestion on requirement, Please make it clear.  

 Add CQL3 keyword for efficient lexical range queries (e.g. START_WITH)
 --

 Key: CASSANDRA-7637
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7637
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Rustam Aliyev
Assignee: Sunil Kumar Singh
 Fix For: 3.0


 Currently, if I want to perform range query on lexical type I need to do 
 something like this:
 {code}
 SELECT * FROM profile WHERE profile_id = 123 AND
   attribute  'interests.food.' AND
   attribute  'interests.food.z';
 {code}
 This is very efficient range query. Yet, many users who are not familiar with 
 Thrift and storage level implementation are unaware of this trick.
 Therefore, it would be convenient to introduce CQL keyword which will do this 
 more simply:
 {code}
 SELECT * FROM profile WHERE profile_id = 123 AND
   attribute START_WITH('interests.food.');
 {code}
 Keyword would have same restrictions as other inequality search operators 
 plus some type restrictions.
 Allowed types would be:
  * {{ascii}}
  * {{text}} / {{varchar}}
  * {{maptext, *}} (same for ascii) (?)
  * {{settext}} (same for ascii) (?)
 (?) may require more work, therefore optional



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7969) Properly track min/max timestamps and maxLocalDeletionTimes for range and row tombstones

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-7969:


oops wrong commit, it is this one:

https://github.com/krummas/cassandra/commit/c53978e374df01f8d0bebdc5d560c5c5fb240324

 Properly track min/max timestamps and maxLocalDeletionTimes for range and row 
 tombstones
 

 Key: CASSANDRA-7969
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7969
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
 Fix For: 2.0.11

 Attachments: 
 0001-track-min-max-timestamps-and-maxLocalDeletionTime-co.patch, 
 0001-track-min-max-timestamps-and-maxLocalDeletionTime-v2.patch


 First problem is that when we have only row or range tombstones in an sstable 
 we dont update the maxLocalDeletionTime for the sstable
 Second problem is that if we have a range tombstone in an sstable, 
 minTimestamp will always be Long.MIN_VALUE for flushed sstables due to how we 
 set the default values for the variables



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7953) RangeTombstones not merging during compaction

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-7953:


It might not be safe to change the comparator for this, a proper fix should 
probably be in RangeTombstone.Tracker and remove all unnecessary RTs (not only 
the ones that have the same start point). It might not be trivial in our new 
(since CASSANDRA-4180) single-pass compaction though

 RangeTombstones not merging during compaction
 -

 Key: CASSANDRA-7953
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7953
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 2.1
Reporter: Marcus Olsson
Priority: Minor
  Labels: compaction, deletes, tombstone
 Attachments: 0001-7953-v2.patch, CASSANDRA-7953-1.patch, 
 CASSANDRA-7953.patch


 When performing a compaction on two sstables that contain the same 
 RangeTombstone with different timestamps, the tombstones are not merged in 
 the new sstable.
 This has been tested using cassandra 2.1 with the following table:
 {code}
 CREATE TABLE test(
   key text,
   column text,
   data text,
   PRIMARY KEY(key, column)
 );
 {code}
 And then doing the following:
 {code}
 INSERT INTO test (key, column, data) VALUES (1, 1, 1); // If the 
 sstable only contains tombstones during compaction it seems that the sstable 
 either gets removed or isn't created (but that could probably be a separate 
 JIRA issue).
 INSERT INTO test (key, column, data) VALUES (1, 2, 2); // The inserts 
 are not actually needed, since the deletes create tombstones either way.
 DELETE FROM test WHERE key=1 AND column=2;
 nodetool flush
 INSERT INTO test (key, column, data) VALUES (1, 2, 2);
 DELETE FROM test WHERE key=1 AND column=2;
 nodetool flush
 nodetool compact
 {code}
 When checking with the SSTableExport tool two tombstones exists in the 
 compacted sstable. This can be repeated, resulting in more and more 
 tombstones.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8014) NPE in Message.java line 324

[Peter Haggerty (JIRA)]

Peter Haggerty created CASSANDRA-8014:
-

 Summary: NPE in Message.java line 324
 Key: CASSANDRA-8014
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8014
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 2.0.9
Reporter: Peter Haggerty
 Attachments: NPE_Message.java_line-324.txt

We received this when a server was rebooting and attempted to shut Cassandra 
down while it was still quite busy. While it's normal for us to have a handful 
of the RejectedExecution exceptions on a sudden shutdown like this these NPEs 
in Message.java are new.

The attached file include the logs from StorageServiceShutdownHook to the 
Logging initialized after the server restarts and Cassandra comes back up.


ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 324) 
Unexpected throwable while invoking!
java.lang.NullPointerException
at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
at 
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
at 
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
at 
org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
at 
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
at 
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
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)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Vladislav Sinjavin (JIRA)]

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

Vladislav Sinjavin commented on CASSANDRA-7159:
---

Hi Jeremiah!

Just a gentle reminder about the patch review.

Thanks in advance.

 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.3.4#6332)

[jira] [Commented] (CASSANDRA-7859) Extend freezing to collections

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-7859:
-

bq. By default, indexes on frozen collections will index the entire collection.

What bother me about that is the inconstency with non-frozen collections and I 
do feel that this inconsistency will be unintuitive. So I would prefer leaving 
the default be indexing by values, and add some new keyword for indexing entire 
collections. Something like {{CREATE INDEX ON foo(fullCollection(myMap))}}, 
excepted that I'm hoping someone can come with a less crappy name than 
{{fullCollection}}.

More generally, on the indexing of frozen collections, indexing on the entire 
collection should be relatively simple but indexing on values and keys will 
require new indexes implementation (new subclasses of {{CompositesIndex}}) and 
so this should definitively be pushed to a follow-up ticket imo. Not even sure 
said ticket should be targeted at 2.1.


 Extend freezing to collections
 --

 Key: CASSANDRA-7859
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7859
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Tyler Hobbs
 Fix For: 2.1.1


 This is the follow-up to CASSANDRA-7857, to extend {{frozen}} to collections. 
 This will allow things like {{maptext, frozenmapint, int}} for 
 instance, as well as allowing {{frozen}} collections in PK columns.
 Additionally (and that's alsmot a separate ticket but I figured we can start 
 discussing it here), we could decide that tuple is a frozen type by default. 
 This means that we would allow {{tupleint, text}} without needing to add 
 {{frozen}}, but we would require {{frozen}} for complex type inside tuple, so 
 {{tupleint, listtext}} would be rejected, but not {{tupleint, 
 frozenlisttext}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8005) Server-side DESCRIBE

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-8005:
-

bq. Why would the drivers need to parse the string?

What I mean is that the drivers (at least the JAVA one, but I'd argue that any 
good driver should do the same) exposes the schema in a programatic way (in 
[KeyspaceMetadata|http://www.datastax.com/drivers/java/2.0/com/datastax/driver/core/KeyspaceMetadata.html],
 
[TableMetadata|http://www.datastax.com/drivers/java/2.0/com/datastax/driver/core/TableMetadata.html],
 ...) which is useful and not something we'd want to remove. It follows that 
the driver will read the schema tables anyway (or, in your proposal of 
replacing the read of the schema tables by a string, it would have to parse 
that string). And since the drivers have the schema this way, re-generating the 
string representation of it is pretty trivial (and the java driver does it).

So I argue that sending a string of the whole schema is somewhat useless for 
drivers (but making schema table much more easily consumable is definitively 
useful).

 Server-side DESCRIBE
 

 Key: CASSANDRA-8005
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Tyler Hobbs
Priority: Minor
  Labels: cql3
 Fix For: 3.0


 The various {{DESCRIBE}} commands are currently implemented by cqlsh, and 
 nearly identical implementations exist in many drivers.  There are several 
 motivations for making {{DESCRIBE}} part of the CQL language:
 * Eliminate the (fairly complex) duplicate implementations across drivers and 
 cqlsh
 * Get closer to allowing drivers to not have to fetch the schema tables. 
 (Minor changes to prepared statements are also needed.)
 * Have instantaneous support for new schema features in cqlsh.  (You 
 currently have to update the bundled python driver.)
 * Support writing out schemas where it makes sense.  One good example of this 
 is backups.  You need to restore the schema before restoring data in the case 
 of total loss, so it makes sense to write out the schema alongside snapshots.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7953) RangeTombstones not merging during compaction

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-7953:
--

Could an alternative be to change the onDiskAtomComparator to only check for 
equal ranges, instead of inclusive ranges?

 RangeTombstones not merging during compaction
 -

 Key: CASSANDRA-7953
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7953
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 2.1
Reporter: Marcus Olsson
Priority: Minor
  Labels: compaction, deletes, tombstone
 Attachments: 0001-7953-v2.patch, CASSANDRA-7953-1.patch, 
 CASSANDRA-7953.patch


 When performing a compaction on two sstables that contain the same 
 RangeTombstone with different timestamps, the tombstones are not merged in 
 the new sstable.
 This has been tested using cassandra 2.1 with the following table:
 {code}
 CREATE TABLE test(
   key text,
   column text,
   data text,
   PRIMARY KEY(key, column)
 );
 {code}
 And then doing the following:
 {code}
 INSERT INTO test (key, column, data) VALUES (1, 1, 1); // If the 
 sstable only contains tombstones during compaction it seems that the sstable 
 either gets removed or isn't created (but that could probably be a separate 
 JIRA issue).
 INSERT INTO test (key, column, data) VALUES (1, 2, 2); // The inserts 
 are not actually needed, since the deletes create tombstones either way.
 DELETE FROM test WHERE key=1 AND column=2;
 nodetool flush
 INSERT INTO test (key, column, data) VALUES (1, 2, 2);
 DELETE FROM test WHERE key=1 AND column=2;
 nodetool flush
 nodetool compact
 {code}
 When checking with the SSTableExport tool two tombstones exists in the 
 compacted sstable. This can be repeated, resulting in more and more 
 tombstones.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8015) nodetool exception for users with read only permissions on jmx authentication

[Jose Martinez Poblete (JIRA)]

Jose Martinez Poblete created CASSANDRA-8015:


 Summary: nodetool exception for users with read only permissions 
on jmx authentication 
 Key: CASSANDRA-8015
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8015
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 2.0.8.39
Reporter: Jose Martinez Poblete


nodetool will throw exception for a read only user when JMX authentication is 
enabled.

{noformat}
[automaton@i-0212b8098 ~]$ nodetool -u jose -pw JoseManuel status
Exception in thread main java.lang.SecurityException: Access denied! Invalid 
access level for requested MBeanServer operation.
at 
com.sun.jmx.remote.security.MBeanServerFileAccessController.checkAccess(MBeanServerFileAccessController.java:344)
at 
com.sun.jmx.remote.security.MBeanServerFileAccessController.checkWrite(MBeanServerFileAccessController.java:240)
at 
com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:466)
at 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
at 
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
at java.security.AccessController.doPrivileged(Native Method)
at 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
at 
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
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:744)
at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:275)
at 
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown 
Source)
at 
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:1029)
at 
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:292)
at com.sun.proxy.$Proxy0.effectiveOwnership(Unknown Source)
at 
org.apache.cassandra.tools.NodeProbe.effectiveOwnership(NodeProbe.java:335)
at 
org.apache.cassandra.tools.NodeCmd$ClusterStatus.print(NodeCmd.java:480)
at 
org.apache.cassandra.tools.NodeCmd.printClusterStatus(NodeCmd.java:590)
at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:1263)
[automaton@i-0212b8098 ~]$ dse -v
4.5.1
[automaton@i-0212b8098 ~]$ cqlsh -u jose -p JoseManuel 
Connected to Spark at localhost:9160.
[cqlsh 4.1.1 | Cassandra 2.0.8.39 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
cqlsh exit;
[automaton@i-0212b8098 ~]$ 
{noformat}


Nodetool runs fine for cassandra user:

{noformat}
[automaton@i-0212b8098 ~]$ nodetool -u cassandra -pw cassandra status
Note: Ownership information does not include topology; for complete 
information, specify a keyspace
Datacenter: Cassandra
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  AddressLoad   Owns   Host ID   
TokenRack
UN  10.240.11.164  771.93 KB  100.0%  ae672795-bd73-4f53-a371-1a35c8df28a1  
-9223372036854775808 rack1
[automaton@i-0212b8098 ~]$
{noformat}

JMX authentication is enabled as described [here | 
https://support.datastax.com/entries/43692547-Step-by-step-instructions-for-securing-JMX-authentication-for-nodetool-utility-OpsCenter-and-JConsol]

[jira] [Commented] (CASSANDRA-7969) Properly track min/max timestamps and maxLocalDeletionTimes for range and row tombstones

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-7969:
---

+1 nit: the CQLtest should use the CQLTester class

 Properly track min/max timestamps and maxLocalDeletionTimes for range and row 
 tombstones
 

 Key: CASSANDRA-7969
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7969
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
 Fix For: 2.0.11

 Attachments: 
 0001-track-min-max-timestamps-and-maxLocalDeletionTime-co.patch, 
 0001-track-min-max-timestamps-and-maxLocalDeletionTime-v2.patch


 First problem is that when we have only row or range tombstones in an sstable 
 we dont update the maxLocalDeletionTime for the sstable
 Second problem is that if we have a range tombstone in an sstable, 
 minTimestamp will always be Long.MIN_VALUE for flushed sstables due to how we 
 set the default values for the variables



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7969) Properly track min/max timestamps and maxLocalDeletionTimes for range and row tombstones

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-7969:


bq. the CQLtest should use the CQLTester class

It will, in 2.1 where we have it (should maybe be backported to 2.0 as well?)

 Properly track min/max timestamps and maxLocalDeletionTimes for range and row 
 tombstones
 

 Key: CASSANDRA-7969
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7969
 Project: Cassandra
  Issue Type: Bug
Reporter: Marcus Eriksson
Assignee: Marcus Eriksson
 Fix For: 2.0.11

 Attachments: 
 0001-track-min-max-timestamps-and-maxLocalDeletionTime-co.patch, 
 0001-track-min-max-timestamps-and-maxLocalDeletionTime-v2.patch


 First problem is that when we have only row or range tombstones in an sstable 
 we dont update the maxLocalDeletionTime for the sstable
 Second problem is that if we have a range tombstone in an sstable, 
 minTimestamp will always be Long.MIN_VALUE for flushed sstables due to how we 
 set the default values for the variables



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8016) Auth tables should use higher consistency level

[T Jake Luciani (JIRA)]

T Jake Luciani created CASSANDRA-8016:
-

 Summary: Auth tables should use higher consistency level
 Key: CASSANDRA-8016
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8016
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
 Fix For: 2.0.11


The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of 
the superuser.

Since the Auth keyspace is created with RF=1 the default experience is fine.
However if you change to RF  1 suddenly the select statements are open to 
misses.

We should change reads/writes in Auth, PasswordAuthenticator, 
CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM.

For reads if could optimize it to start with CL.ONE and on a miss increase to 
CL.QUORUM



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8016) Auth tables should use higher consistency level

[T Jake Luciani (JIRA)]

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

T Jake Luciani updated CASSANDRA-8016:
--
Description: 
The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of 
the superuser.

Since the Auth keyspace is created with RF=1 the default experience is fine.
However if you change to RF  1 suddenly the select statements are open to 
misses.

We should change reads/writes in Auth, PasswordAuthenticator, 
CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM.

For reads we could optimize the code to start with CL.ONE and on a miss 
increase to CL.QUORUM

  was:
The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of 
the superuser.

Since the Auth keyspace is created with RF=1 the default experience is fine.
However if you change to RF  1 suddenly the select statements are open to 
misses.

We should change reads/writes in Auth, PasswordAuthenticator, 
CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM.

For reads if could optimize it to start with CL.ONE and on a miss increase to 
CL.QUORUM


 Auth tables should use higher consistency level
 ---

 Key: CASSANDRA-8016
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8016
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
 Fix For: 2.0.11


 The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of 
 the superuser.
 Since the Auth keyspace is created with RF=1 the default experience is fine.
 However if you change to RF  1 suddenly the select statements are open to 
 misses.
 We should change reads/writes in Auth, PasswordAuthenticator, 
 CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM.
 For reads we could optimize the code to start with CL.ONE and on a miss 
 increase to CL.QUORUM



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6246) EPaxos

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-6246:
---

For write timestamps take a look at CASSANDRA-7919 we need to change this to 
support better LWW semantics and RAMP

 EPaxos
 --

 Key: CASSANDRA-6246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Blake Eggleston
Priority: Minor

 One reason we haven't optimized our Paxos implementation with Multi-paxos is 
 that Multi-paxos requires leader election and hence, a period of 
 unavailability when the leader dies.
 EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
 (2) is particularly useful across multiple datacenters, and (3) allows any 
 node to act as coordinator: 
 http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
 However, there is substantial additional complexity involved if we choose to 
 implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8008) Timed out waiting for timer thread on large stress command

[Shawn Kumar (JIRA)]

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

Shawn Kumar updated CASSANDRA-8008:
---
Attachment: (was: perftest.log)

 Timed out waiting for timer thread on large stress command
 

 Key: CASSANDRA-8008
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Shawn Kumar
 Attachments: node1-2.log, node1.log, node2-2.log, node2.log, 
 perftest.log


 I've been using cstar_perf to test a performance scenario and was able to 
 reproduce this error on a two node cluster with stock 2.1.0 while carrying 
 out large stress writes (50M keys):
 {noformat}
 java.lang.RuntimeException: Timed out waiting for a timer thread - seems one 
 got stuck
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
 at 
 org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
 at 
 org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
 at 
 org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
 at java.lang.Thread.run(Thread.java:745)
 {noformat}
 It looks like a similar error to that found in CASSANDRA-6943. I've also 
 attached the test log and thread dumps. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8008) Timed out waiting for timer thread on large stress command

[Shawn Kumar (JIRA)]

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

Shawn Kumar updated CASSANDRA-8008:
---
Attachment: perftest.log

 Timed out waiting for timer thread on large stress command
 

 Key: CASSANDRA-8008
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Shawn Kumar
 Attachments: node1-2.log, node1.log, node2-2.log, node2.log, 
 perftest.log


 I've been using cstar_perf to test a performance scenario and was able to 
 reproduce this error on a two node cluster with stock 2.1.0 while carrying 
 out large stress writes (50M keys):
 {noformat}
 java.lang.RuntimeException: Timed out waiting for a timer thread - seems one 
 got stuck
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
 at 
 org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
 at 
 org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
 at 
 org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
 at java.lang.Thread.run(Thread.java:745)
 {noformat}
 It looks like a similar error to that found in CASSANDRA-6943. I've also 
 attached the test log and thread dumps. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-8011) Fail on large batch sizes

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian edited comment on CASSANDRA-8011 at 9/29/14 1:55 PM:


Added the option which fails on very large batches.

{noformat}
batch_size_fail_threshold_in_kb: 50
{noformat}


was (Author: carlyeks):
Added the option which fails on very large batches.

{noformat}
batch_size_file_threshold_in_kb: 50
{noformat}

 Fail on large batch sizes 
 --

 Key: CASSANDRA-8011
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Assignee: Carl Yeksigian
Priority: Minor
 Fix For: 3.0

 Attachments: 8011-trunk.txt


 Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
 Just education alone is not going to stop some of the largest batch sizes 
 from being used. Just like we have a tombstone fail threshold, I propose that 
 we have a batch size fail threshold.
 Maybe 10x warn?
 {{batch_fail_threshold: 50k}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8017) er()

[Benedict (JIRA)]

Benedict created CASSANDRA-8017:
---

 Summary: er()
 Key: CASSANDRA-8017
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8017
 Project: Cassandra
  Issue Type: Bug
Reporter: Benedict






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Deleted] (CASSANDRA-8017) er()

[Benedict (JIRA)]

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

Benedict deleted CASSANDRA-8017:



 er()
 

 Key: CASSANDRA-8017
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8017
 Project: Cassandra
  Issue Type: Bug
Reporter: Benedict





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7838) Warn user when disks are network/ebs mounted

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-7838:
---

Your isSwapDisabled check is backwards. Also, the log message warning is 
missing some : separators



If all the checks pass we should log that everything looks OK. 

 Warn user when disks are network/ebs mounted
 

 Key: CASSANDRA-7838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7838
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Priority: Minor
  Labels: bootcamp, lhf
 Fix For: 3.0

 Attachments: 
 0001-CASSANDRA-7838-log-warning-for-networked-drives.patch, 
 0002-added-missing-winnt-native.patch, 
 0003-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch, 
 0004-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch


 The Sigar project let's you probe os/cpu/filesystems across the major 
 platforms.
 https://github.com/hyperic/sigar
 It would be nice on start-up to use this to warn users if they are running 
 with settings that will make them sad, like Network drive or EBS on Ec2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[8/8] git commit: Merge branch 'cassandra-2.1' into trunk

[brandonwilliams]

Merge branch 'cassandra-2.1' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9391fc03
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9391fc03
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9391fc03

Branch: refs/heads/trunk
Commit: 9391fc03d479a71d95386375f1a3037eb72d1898
Parents: 04f0d41 3ece6f2
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Sep 29 09:52:49 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Sep 29 09:52:49 2014 -0500

--
 CHANGES.txt |  1 +
 .../apache/cassandra/service/StorageService.java| 16 +++-
 2 files changed, 16 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9391fc03/CHANGES.txt
--
diff --cc CHANGES.txt
index b9ffacc,354cb5d..bbfc5cb
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,32 -1,5 +1,33 @@@
 +3.0
 + * Remove cassandra-cli (CASSANDRA-7920)
 + * Optimize java source-based UDF invocation (CASSANDRA-7924)
 + * Accept dollar quoted strings in CQL (CASSANDRA-7769)
 + * Make assassinate a first class command (CASSANDRA-7935)
 + * Support IN clause on any clustering column (CASSANDRA-4762)
 + * Improve compaction logging (CASSANDRA-7818)
 + * Remove YamlFileNetworkTopologySnitch (CASSANDRA-7917)
 + * Support Java source code for user-defined functions (CASSANDRA-7562)
 + * Require arg types to disambiguate UDF drops (CASSANDRA-7812)
 + * Do anticompaction in groups (CASSANDRA-6851)
 + * Verify that UDF class methods are static (CASSANDRA-7781)
 + * Support pure user-defined functions (CASSANDRA-7395, 7740)
 + * Permit configurable timestamps with cassandra-stress (CASSANDRA-7416)
 + * Move sstable RandomAccessReader to nio2, which allows using the
 +   FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050)
 + * Remove CQL2 (CASSANDRA-5918)
 + * Add Thrift get_multi_slice call (CASSANDRA-6757)
 + * Optimize fetching multiple cells by name (CASSANDRA-6933)
 + * Allow compilation in java 8 (CASSANDRA-7028)
 + * Make incremental repair default (CASSANDRA-7250)
 + * Enable code coverage thru JaCoCo (CASSANDRA-7226)
 + * Switch external naming of 'column families' to 'tables' (CASSANDRA-4369) 
 + * Shorten SSTable path (CASSANDRA-6962)
 + * Use unsafe mutations for most unit tests (CASSANDRA-6969)
 + * Fix race condition during calculation of pending ranges (CASSANDRA-7390)
 +
 +
  2.1.1
+  * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
   * Make sstablerepairedset take a list of files (CASSANDRA-7995)
   * (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972)
   * (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9391fc03/src/java/org/apache/cassandra/service/StorageService.java
--

[4/8] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1

[brandonwilliams]

Merge branch 'cassandra-2.0' into cassandra-2.1


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5f186581
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5f186581
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5f186581

Branch: refs/heads/cassandra-2.1
Commit: 5f18658170b66714e46f82b8151c5fcab233d742
Parents: ad60b78 6b8b8e0
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Sep 29 09:46:47 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Sep 29 09:46:47 2014 -0500

--

--

[7/8] git commit: Ignore fat clients when checking for endpoint collision

[brandonwilliams]

Ignore fat clients when checking for endpoint collision

Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3ece6f23
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3ece6f23
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3ece6f23

Branch: refs/heads/cassandra-2.1
Commit: 3ece6f2399fa15c97d889c5d43b4a7457825e8e1
Parents: 5f18658
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Sep 29 09:52:09 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Sep 29 09:52:09 2014 -0500

--
 CHANGES.txt |  1 +
 .../apache/cassandra/service/StorageService.java| 16 +++-
 2 files changed, 16 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ece6f23/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fca7ccb..354cb5d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.1
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
  * Make sstablerepairedset take a list of files (CASSANDRA-7995)
  * (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972)
  * (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ece6f23/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index a005c44..d2cb1ab 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -453,12 +453,26 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 MessagingService.instance().listen(FBUtilities.getLocalAddress());
 Gossiper.instance.doShadowRound();
 EndpointState epState = 
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null  !Gossiper.instance.isDeadState(epState))
+if (epState != null  !Gossiper.instance.isDeadState(epState)  
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
 {
 throw new RuntimeException(String.format(A node with address %s 
already exists, cancelling join.  +
  Use 
cassandra.replace_address if you want to replace this node.,
  
FBUtilities.getBroadcastAddress()));
 }
+if (RangeStreamer.useStrictConsistency)
+{
+for (Map.EntryInetAddress, EndpointState entry : 
Gossiper.instance.getEndpointStates())
+{
+
+if 
(entry.getValue().getApplicationState(ApplicationState.STATUS) == null)
+continue;
+String[] pieces = 
entry.getValue().getApplicationState(ApplicationState.STATUS).value.split(VersionedValue.DELIMITER_STR,
 -1);
+assert (pieces.length  0);
+String state = pieces[0];
+if (state.equals(VersionedValue.STATUS_BOOTSTRAPPING) || 
state.equals(VersionedValue.STATUS_LEAVING) || 
state.equals(VersionedValue.STATUS_MOVING))
+throw new UnsupportedOperationException(Other 
bootstrapping/leaving/moving nodes detected, cannot bootstrap while 
cassandra.consistent.rangemovement is true);
+}
+}
 Gossiper.instance.resetEndpointStateMap();
 }
 

[5/8] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1

[brandonwilliams]

Merge branch 'cassandra-2.0' into cassandra-2.1


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5f186581
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5f186581
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5f186581

Branch: refs/heads/trunk
Commit: 5f18658170b66714e46f82b8151c5fcab233d742
Parents: ad60b78 6b8b8e0
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Sep 29 09:46:47 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Sep 29 09:46:47 2014 -0500

--

--

[3/8] git commit: Ignore fat clients when checking for endpoint collision

[brandonwilliams]

Ignore fat clients when checking for endpoint collision

Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6b8b8e0f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6b8b8e0f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6b8b8e0f

Branch: refs/heads/trunk
Commit: 6b8b8e0f924b53b9f99854f88ff9ba84073cb295
Parents: 3db38d7
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Sep 29 09:46:02 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Sep 29 09:46:02 2014 -0500

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 40e2f2c..dd5f7dd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.11:
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
  * CrcCheckChance should adjust based on live CFMetadata not 
sstable metadata (CASSANDRA-7978)
  * token() should only accept columns in the partitioning

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index f693a0b..11eb91d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -444,7 +444,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 MessagingService.instance().listen(FBUtilities.getLocalAddress());
 Gossiper.instance.doShadowRound();
 EndpointState epState = 
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null  !Gossiper.instance.isDeadState(epState))
+if (epState != null  !Gossiper.instance.isDeadState(epState)  
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
 {
 throw new RuntimeException(String.format(A node with address %s 
already exists, cancelling join.  +
  Use 
cassandra.replace_address if you want to replace this node.,

[6/8] git commit: Ignore fat clients when checking for endpoint collision

[brandonwilliams]

Ignore fat clients when checking for endpoint collision

Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3ece6f23
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3ece6f23
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3ece6f23

Branch: refs/heads/trunk
Commit: 3ece6f2399fa15c97d889c5d43b4a7457825e8e1
Parents: 5f18658
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Sep 29 09:52:09 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Sep 29 09:52:09 2014 -0500

--
 CHANGES.txt |  1 +
 .../apache/cassandra/service/StorageService.java| 16 +++-
 2 files changed, 16 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ece6f23/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fca7ccb..354cb5d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.1
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
  * Make sstablerepairedset take a list of files (CASSANDRA-7995)
  * (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972)
  * (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ece6f23/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index a005c44..d2cb1ab 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -453,12 +453,26 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 MessagingService.instance().listen(FBUtilities.getLocalAddress());
 Gossiper.instance.doShadowRound();
 EndpointState epState = 
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null  !Gossiper.instance.isDeadState(epState))
+if (epState != null  !Gossiper.instance.isDeadState(epState)  
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
 {
 throw new RuntimeException(String.format(A node with address %s 
already exists, cancelling join.  +
  Use 
cassandra.replace_address if you want to replace this node.,
  
FBUtilities.getBroadcastAddress()));
 }
+if (RangeStreamer.useStrictConsistency)
+{
+for (Map.EntryInetAddress, EndpointState entry : 
Gossiper.instance.getEndpointStates())
+{
+
+if 
(entry.getValue().getApplicationState(ApplicationState.STATUS) == null)
+continue;
+String[] pieces = 
entry.getValue().getApplicationState(ApplicationState.STATUS).value.split(VersionedValue.DELIMITER_STR,
 -1);
+assert (pieces.length  0);
+String state = pieces[0];
+if (state.equals(VersionedValue.STATUS_BOOTSTRAPPING) || 
state.equals(VersionedValue.STATUS_LEAVING) || 
state.equals(VersionedValue.STATUS_MOVING))
+throw new UnsupportedOperationException(Other 
bootstrapping/leaving/moving nodes detected, cannot bootstrap while 
cassandra.consistent.rangemovement is true);
+}
+}
 Gossiper.instance.resetEndpointStateMap();
 }
 

[1/8] git commit: Ignore fat clients when checking for endpoint collision

[brandonwilliams]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.0 3db38d7ed - 6b8b8e0f9
  refs/heads/cassandra-2.1 ad60b7812 - 3ece6f239
  refs/heads/trunk 04f0d412b - 9391fc03d


Ignore fat clients when checking for endpoint collision

Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6b8b8e0f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6b8b8e0f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6b8b8e0f

Branch: refs/heads/cassandra-2.0
Commit: 6b8b8e0f924b53b9f99854f88ff9ba84073cb295
Parents: 3db38d7
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Sep 29 09:46:02 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Sep 29 09:46:02 2014 -0500

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 40e2f2c..dd5f7dd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.11:
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
  * CrcCheckChance should adjust based on live CFMetadata not 
sstable metadata (CASSANDRA-7978)
  * token() should only accept columns in the partitioning

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index f693a0b..11eb91d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -444,7 +444,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 MessagingService.instance().listen(FBUtilities.getLocalAddress());
 Gossiper.instance.doShadowRound();
 EndpointState epState = 
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null  !Gossiper.instance.isDeadState(epState))
+if (epState != null  !Gossiper.instance.isDeadState(epState)  
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
 {
 throw new RuntimeException(String.format(A node with address %s 
already exists, cancelling join.  +
  Use 
cassandra.replace_address if you want to replace this node.,

[2/8] git commit: Ignore fat clients when checking for endpoint collision

[brandonwilliams]

Ignore fat clients when checking for endpoint collision

Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6b8b8e0f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6b8b8e0f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6b8b8e0f

Branch: refs/heads/cassandra-2.1
Commit: 6b8b8e0f924b53b9f99854f88ff9ba84073cb295
Parents: 3db38d7
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Sep 29 09:46:02 2014 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Sep 29 09:46:02 2014 -0500

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 40e2f2c..dd5f7dd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.11:
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
  * CrcCheckChance should adjust based on live CFMetadata not 
sstable metadata (CASSANDRA-7978)
  * token() should only accept columns in the partitioning

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index f693a0b..11eb91d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -444,7 +444,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 MessagingService.instance().listen(FBUtilities.getLocalAddress());
 Gossiper.instance.doShadowRound();
 EndpointState epState = 
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null  !Gossiper.instance.isDeadState(epState))
+if (epState != null  !Gossiper.instance.isDeadState(epState)  
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
 {
 throw new RuntimeException(String.format(A node with address %s 
already exists, cancelling join.  +
  Use 
cassandra.replace_address if you want to replace this node.,

[jira] [Updated] (CASSANDRA-7766) Secondary index not working after a while

[Shawn Kumar (JIRA)]

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

Shawn Kumar updated CASSANDRA-7766:
---
Description: 
Since 2.1.0-rc2, it appears that the secondary indexes are not always working. 
Immediately after the INSERT of a row, the index seems to be there. But after a 
while (I do not know when or why), SELECT statements based on any secondary 
index do not return the corresponding row(s) anymore. I noticed that a restart 
of C* may have an impact (the data inserted before the restart may be seen 
through the index, even if it was not returned before the restart).

Here is a use-case example (in order to clarify my request) :
{code}
CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
{code}

The last SELECT statement may or may not return a row depending on the instant 
of the request. I experienced that with 2.1.0-rc5 through CQLSH with clusters 
of one and two nodes. Since it depends on the instant of the request, I am not 
able to deliver any way to reproduce that systematically (It appears to be 
linked with some scheduled job inside C*).


  was:
cSince 2.1.0-rc2, it appears that the secondary indexes are not always working. 
Immediately after the INSERT of a row, the index seems to be there. But after a 
while (I do not know when or why), SELECT statements based on any secondary 
index do not return the corresponding row(s) anymore. I noticed that a restart 
of C* may have an impact (the data inserted before the restart may be seen 
through the index, even if it was not returned before the restart).

Here is a use-case example (in order to clarify my request) :
{code}
CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
{code}

The last SELECT statement may or may not return a row depending on the instant 
of the request. I experienced that with 2.1.0-rc5 through CQLSH with clusters 
of one and two nodes. Since it depends on the instant of the request, I am not 
able to deliver any way to reproduce that systematically (It appears to be 
linked with some scheduled job inside C*).



 Secondary index not working after a while
 -

 Key: CASSANDRA-7766
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7766
 Project: Cassandra
  Issue Type: Bug
 Environment: C* 2.1.0-rc5 with small clusters (one or two nodes)
Reporter: Fabrice Larcher
 Attachments: result-failure.txt, result-success.txt


 Since 2.1.0-rc2, it appears that the secondary indexes are not always 
 working. Immediately after the INSERT of a row, the index seems to be there. 
 But after a while (I do not know when or why), SELECT statements based on any 
 secondary index do not return the corresponding row(s) anymore. I noticed 
 that a restart of C* may have an impact (the data inserted before the restart 
 may be seen through the index, even if it was not returned before the 
 restart).
 Here is a use-case example (in order to clarify my request) :
 {code}
 CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
 CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
 INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
 SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
 {code}
 The last SELECT statement may or may not return a row depending on the 
 instant of the request. I experienced that with 2.1.0-rc5 through CQLSH with 
 clusters of one and two nodes. Since it depends on the instant of the 
 request, I am not able to deliver any way to reproduce that systematically 
 (It appears to be linked with some scheduled job inside C*).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7766) Secondary index not working after a while

[Shawn Kumar (JIRA)]

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

Shawn Kumar commented on CASSANDRA-7766:


Was unable to reproduce this over a period of a few days. Please feel free to 
reopen the ticket if you come across any further information that could help us 
reproduce this.

 Secondary index not working after a while
 -

 Key: CASSANDRA-7766
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7766
 Project: Cassandra
  Issue Type: Bug
 Environment: C* 2.1.0-rc5 with small clusters (one or two nodes)
Reporter: Fabrice Larcher
 Attachments: result-failure.txt, result-success.txt


 Since 2.1.0-rc2, it appears that the secondary indexes are not always 
 working. Immediately after the INSERT of a row, the index seems to be there. 
 But after a while (I do not know when or why), SELECT statements based on any 
 secondary index do not return the corresponding row(s) anymore. I noticed 
 that a restart of C* may have an impact (the data inserted before the restart 
 may be seen through the index, even if it was not returned before the 
 restart).
 Here is a use-case example (in order to clarify my request) :
 {code}
 CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
 CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
 INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
 SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
 {code}
 The last SELECT statement may or may not return a row depending on the 
 instant of the request. I experienced that with 2.1.0-rc5 through CQLSH with 
 clusters of one and two nodes. Since it depends on the instant of the 
 request, I am not able to deliver any way to reproduce that systematically 
 (It appears to be linked with some scheduled job inside C*).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-7766) Secondary index not working after a while

[Shawn Kumar (JIRA)]

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

Shawn Kumar resolved CASSANDRA-7766.

Resolution: Cannot Reproduce

 Secondary index not working after a while
 -

 Key: CASSANDRA-7766
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7766
 Project: Cassandra
  Issue Type: Bug
 Environment: C* 2.1.0-rc5 with small clusters (one or two nodes)
Reporter: Fabrice Larcher
 Attachments: result-failure.txt, result-success.txt


 Since 2.1.0-rc2, it appears that the secondary indexes are not always 
 working. Immediately after the INSERT of a row, the index seems to be there. 
 But after a while (I do not know when or why), SELECT statements based on any 
 secondary index do not return the corresponding row(s) anymore. I noticed 
 that a restart of C* may have an impact (the data inserted before the restart 
 may be seen through the index, even if it was not returned before the 
 restart).
 Here is a use-case example (in order to clarify my request) :
 {code}
 CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
 CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
 INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
 SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
 {code}
 The last SELECT statement may or may not return a row depending on the 
 instant of the request. I experienced that with 2.1.0-rc5 through CQLSH with 
 clusters of one and two nodes. Since it depends on the instant of the 
 request, I am not able to deliver any way to reproduce that systematically 
 (It appears to be linked with some scheduled job inside C*).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8007) sstableloader throws exceptions when used with '-cph'

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-8007:
--
Attachment: 8007-2.1.txt

Looks like sstableloader is over releasing reference when '-cph'  1.
{{StreamCoordinator#sliceSSTableDetails}} needs to remove content from given 
SSTablesStreamingSection when splitting as in 
{{StreamSession#addTransferFile}}, so that the same SSTable does not get 
over-released after adding to StreamPlan 
(https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java#L195).

 sstableloader throws exceptions when used with '-cph'
 -

 Key: CASSANDRA-8007
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8007
 Project: Cassandra
  Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
  Labels: streaming
 Fix For: 2.1.1

 Attachments: 8007-2.1.txt


 When I use {{sstableloader}} with {{-cph}}(connections per host) option 
 greater than 1, I get the following exceptions.
 {code}
 java.lang.NullPointerException: null
 at 
 org.apache.cassandra.io.sstable.SSTableReader$6.run(SSTableReader.java:637) 
 ~[main/:na]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 ~[na:1.7.0_51]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 ~[na:1.7.0_51]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
  ~[na:1.7.0_51]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
  ~[na:1.7.0_51]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_51]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  [na:1.7.0_51]
 at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
 {code}
 also,
 {code}
 ERROR 14:33:52 [Stream #218f2470-458a-11e4-a929-cb31cb113424] Streaming error 
 occurred
 java.lang.AssertionError: Reference counter -1 for 
 /home/yuki/Keyspace1/Standard1-cb5e6f30458811e49349511b628b066f/Keyspace1-Standard1-ka-6-Data.db
 at 
 org.apache.cassandra.io.sstable.SSTableReader.releaseReference(SSTableReader.java:1597)
  ~[main/:na]
 at 
 org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:68)
  ~[main/:na]
 at 
 org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:522) 
 ~[main/:na]
 at 
 org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:404)
  ~[main/:na]
 at 
 org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:295)
  ~[main/:na]
 at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
 {code}
 Looks like there are conflict in grabbing SSTables to stream.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7983) nodetool repair triggers OOM

[JIRA]

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

Jimmy Mårdell updated CASSANDRA-7983:
-
Attachment: 7983-v1.patch

 nodetool repair triggers OOM
 

 Key: CASSANDRA-7983
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7983
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment:  
 {noformat}
  INFO [main] 2014-09-16 14:23:14,621 DseDaemon.java (line 368) DSE version: 
 4.5.0
  INFO [main] 2014-09-16 14:23:14,622 DseDaemon.java (line 369) Hadoop 
 version: 1.0.4.13
  INFO [main] 2014-09-16 14:23:14,627 DseDaemon.java (line 370) Hive version: 
 0.12.0.3
  INFO [main] 2014-09-16 14:23:14,628 DseDaemon.java (line 371) Pig version: 
 0.10.1
  INFO [main] 2014-09-16 14:23:14,629 DseDaemon.java (line 372) Solr version: 
 4.6.0.2.4
  INFO [main] 2014-09-16 14:23:14,630 DseDaemon.java (line 373) Sqoop version: 
 1.4.4.14.1
  INFO [main] 2014-09-16 14:23:14,630 DseDaemon.java (line 374) Mahout 
 version: 0.8
  INFO [main] 2014-09-16 14:23:14,631 DseDaemon.java (line 375) Appender 
 version: 3.0.2
  INFO [main] 2014-09-16 14:23:14,632 DseDaemon.java (line 376) Spark version: 
 0.9.1
  INFO [main] 2014-09-16 14:23:14,632 DseDaemon.java (line 377) Shark version: 
 0.9.1.1
  INFO [main] 2014-09-16 14:23:20,270 CassandraDaemon.java (line 160) JVM 
 vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0_51
  INFO [main] 2014-09-16 14:23:20,270 CassandraDaemon.java (line 188) Heap 
 size: 6316621824/6316621824
 {noformat}
Reporter: Jose Martinez Poblete
Assignee: Yuki Morishita
 Fix For: 2.0.11

 Attachments: 7983-v1.patch, gc.log.0, nbcqa-chc-a01_systemlog.tar.Z, 
 nbcqa-chc-a03_systemlog.tar.Z, system.log


 Customer has a 3 node cluster with 500Mb data on each node
 {noformat}
 [cassandra@nbcqa-chc-a02 ~]$ nodetool status
 Note: Ownership information does not include topology; for complete 
 information, specify a keyspace
 Datacenter: CH2
 ===
 Status=Up/Down
 |/ State=Normal/Leaving/Joining/Moving
 --  AddressLoad   Tokens  Owns   Host ID  
  Rack
 UN  162.150.4.234  255.26 MB  256 33.2%  
 4ad1b6a8-8759-4920-b54a-f059126900df  RAC1
 UN  162.150.4.235  318.37 MB  256 32.6%  
 3eb0ec58-4b81-442e-bee5-4c91da447f38  RAC1
 UN  162.150.4.167  243.7 MB   256 34.2%  
 5b2c1900-bf03-41c1-bb4e-82df1655b8d8  RAC1
 [cassandra@nbcqa-chc-a02 ~]$
 {noformat}
 After we run repair command, system runs into OOM after some 45 minutes
 Nothing else is running
 {noformat}
 [cassandra@nbcqa-chc-a02 ~]$ date
 Fri Sep 19 15:55:33 UTC 2014
 [cassandra@nbcqa-chc-a02 ~]$ nodetool repair -st -9220354588320251877 -et 
 -9220354588320251873
 Sep 19, 2014 4:06:08 PM ClientCommunicatorAdmin Checker-run
 WARNING: Failed to check the connection: java.net.SocketTimeoutException: 
 Read timed out
 {noformat}
 Herer is when we run OOM
 {noformat}
 ERROR [ReadStage:28914] 2014-09-19 16:34:50,381 CassandraDaemon.java (line 
 199) Exception in thread Thread[ReadStage:28914,5,main]
 java.lang.OutOfMemoryError: Java heap space
 at 
 org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:69)
 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:76)
 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:43)
 at 
 org.apache.cassandra.io.util.CompressedPoolingSegmentedFile.createReader(CompressedPoolingSegmentedFile.java:48)
 at 
 org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:39)
 at 
 org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:1195)
 at 
 org.apache.cassandra.db.columniterator.SimpleSliceReader.init(SimpleSliceReader.java:57)
 at 
 org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65)
 at 
 org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:42)
 at 
 org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:167)
 at 
 org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62)
 at 
 org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:250)
 at 
 org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1547)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1376)
 at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:333)
 at 
 

[jira] [Resolved] (CASSANDRA-6898) describing a table with compression should expand the compression options

[Shawn Kumar (JIRA)]

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

Shawn Kumar resolved CASSANDRA-6898.

Resolution: Fixed

 describing a table with compression should expand the compression options
 -

 Key: CASSANDRA-6898
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6898
 Project: Cassandra
  Issue Type: Bug
  Components: API
Reporter: Brandon Williams
Priority: Minor
 Fix For: 2.0.11


 {noformat}
 cqlsh:foo CREATE TABLE baz ( foo text, bar text, primary KEY (foo)) WITH 
 compression = {};
 cqlsh:foo DESCRIBE TABLE baz;
 CREATE TABLE baz (
   foo text,
   bar text,
   PRIMARY KEY (foo)
 ) WITH
   bloom_filter_fp_chance=0.01 AND
   caching='KEYS_ONLY' AND
   comment='' AND
   dclocal_read_repair_chance=0.00 AND
   gc_grace_seconds=864000 AND
   index_interval=128 AND
   read_repair_chance=0.10 AND
   replicate_on_write='true' AND
   populate_io_cache_on_flush='false' AND
   default_time_to_live=0 AND
   speculative_retry='99.0PERCENTILE' AND
   memtable_flush_period_in_ms=0 AND
   compaction={'class': 'SizeTieredCompactionStrategy'} AND
   compression={};
 cqlsh:foo
 {noformat}
 From this, you can't tell that LZ4 compression is enabled, even though it is. 
  It would be more friendly to expand the option to show the defaults.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8007) sstableloader throws exceptions when used with '-cph'

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-8007:


+1

 sstableloader throws exceptions when used with '-cph'
 -

 Key: CASSANDRA-8007
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8007
 Project: Cassandra
  Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
  Labels: streaming
 Fix For: 2.1.1

 Attachments: 8007-2.1.txt


 When I use {{sstableloader}} with {{-cph}}(connections per host) option 
 greater than 1, I get the following exceptions.
 {code}
 java.lang.NullPointerException: null
 at 
 org.apache.cassandra.io.sstable.SSTableReader$6.run(SSTableReader.java:637) 
 ~[main/:na]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 ~[na:1.7.0_51]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 ~[na:1.7.0_51]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
  ~[na:1.7.0_51]
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
  ~[na:1.7.0_51]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_51]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  [na:1.7.0_51]
 at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
 {code}
 also,
 {code}
 ERROR 14:33:52 [Stream #218f2470-458a-11e4-a929-cb31cb113424] Streaming error 
 occurred
 java.lang.AssertionError: Reference counter -1 for 
 /home/yuki/Keyspace1/Standard1-cb5e6f30458811e49349511b628b066f/Keyspace1-Standard1-ka-6-Data.db
 at 
 org.apache.cassandra.io.sstable.SSTableReader.releaseReference(SSTableReader.java:1597)
  ~[main/:na]
 at 
 org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:68)
  ~[main/:na]
 at 
 org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:522) 
 ~[main/:na]
 at 
 org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:404)
  ~[main/:na]
 at 
 org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:295)
  ~[main/:na]
 at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
 {code}
 Looks like there are conflict in grabbing SSTables to stream.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CASSANDRA-8014) NPE in Message.java line 324

[Brandon Williams (JIRA)]

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

Brandon Williams reassigned CASSANDRA-8014:
---

Assignee: Pavel Yaskevich

 NPE in Message.java line 324
 

 Key: CASSANDRA-8014
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8014
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 2.0.9
Reporter: Peter Haggerty
Assignee: Pavel Yaskevich
 Attachments: NPE_Message.java_line-324.txt


 We received this when a server was rebooting and attempted to shut Cassandra 
 down while it was still quite busy. While it's normal for us to have a 
 handful of the RejectedExecution exceptions on a sudden shutdown like this 
 these NPEs in Message.java are new.
 The attached file include the logs from StorageServiceShutdownHook to the 
 Logging initialized after the server restarts and Cassandra comes back up.
 {code}ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 
 324) Unexpected throwable while invoking!
 java.lang.NullPointerException
 at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
 at 
 com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
 at 
 com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
 at 
 org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
 at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
 at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
 at 
 com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
 at 
 com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
 at 
 com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
 at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
 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}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8014) NPE in Message.java line 324

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-8014:
---
Description: 
We received this when a server was rebooting and attempted to shut Cassandra 
down while it was still quite busy. While it's normal for us to have a handful 
of the RejectedExecution exceptions on a sudden shutdown like this these NPEs 
in Message.java are new.

The attached file include the logs from StorageServiceShutdownHook to the 
Logging initialized after the server restarts and Cassandra comes back up.


{code}ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 324) 
Unexpected throwable while invoking!
java.lang.NullPointerException
at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
at 
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
at 
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
at 
org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
at 
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
at 
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
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}

  was:
We received this when a server was rebooting and attempted to shut Cassandra 
down while it was still quite busy. While it's normal for us to have a handful 
of the RejectedExecution exceptions on a sudden shutdown like this these NPEs 
in Message.java are new.

The attached file include the logs from StorageServiceShutdownHook to the 
Logging initialized after the server restarts and Cassandra comes back up.


ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 324) 
Unexpected throwable while invoking!
java.lang.NullPointerException
at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
at 
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
at 
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
at 
org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
at 
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
at 
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
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)


 NPE in Message.java line 324
 

 Key: CASSANDRA-8014
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8014
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 2.0.9
Reporter: Peter Haggerty
 Attachments: NPE_Message.java_line-324.txt


 We received this when a server was rebooting and attempted to shut Cassandra 
 down while it was still quite busy. While it's normal for us to have a 
 handful of the RejectedExecution exceptions on a sudden shutdown like this 
 these NPEs in Message.java are new.
 The attached file include the logs from StorageServiceShutdownHook to the 
 Logging initialized after the server restarts and Cassandra comes back up.
 {code}ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 
 324) Unexpected throwable while invoking!
 java.lang.NullPointerException
 at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
 at 
 com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
 at 
 

[jira] [Updated] (CASSANDRA-8012) cqlsh DESCRIBE KEYSPACES; returns empty after upgrade

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-8012:
---
Labels: cqlsh  (was: )

 cqlsh DESCRIBE KEYSPACES; returns empty after upgrade
 ---

 Key: CASSANDRA-8012
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8012
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: cassandra 2.1.0 
Reporter: Shawn Zhou
  Labels: cqlsh

 after upgrade from 2.0.7 to 2.1.0
 run cqlsh  DESCRIBE KEYSPACES; returns empty result;
 query individual table does return data;
 See below:
 {noformat}
 [root@dc1-stg-cassandra-08 cassandra]# cqlsh 
 dc1-stg-cassandra-08.dc01.revsci.net -k as_user_segment
 Connected to Stage Cluster at dc1-stg-cassandra-08.dc01.revsci.net:9042.
 [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
 Use HELP for help.
 cqlsh:as_user_segment DESCRIBE KEYSPACES;
 empty
 cqlsh:as_user_segment  select * from user_segments_blob where id = 
 '8e6090087fc1a7591a99dc4cb744ac43';
  id   | segments
 --+
  8e6090087fc1a7591a99dc4cb744ac43 | 
 0x9416b015911d3b0e211aee227216ab1cdf0f4204
 (1 rows)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8014) NPE in Message.java line 324

[Brandon Williams (JIRA)]

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

Brandon Williams commented on CASSANDRA-8014:
-

Look like something in disuptor, [~xedin].  Harmless though.

 NPE in Message.java line 324
 

 Key: CASSANDRA-8014
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8014
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Cassandra 2.0.9
Reporter: Peter Haggerty
Assignee: Pavel Yaskevich
 Attachments: NPE_Message.java_line-324.txt


 We received this when a server was rebooting and attempted to shut Cassandra 
 down while it was still quite busy. While it's normal for us to have a 
 handful of the RejectedExecution exceptions on a sudden shutdown like this 
 these NPEs in Message.java are new.
 The attached file include the logs from StorageServiceShutdownHook to the 
 Logging initialized after the server restarts and Cassandra comes back up.
 {code}ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 
 324) Unexpected throwable while invoking!
 java.lang.NullPointerException
 at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
 at 
 com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
 at 
 com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
 at 
 org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
 at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
 at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
 at 
 com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
 at 
 com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
 at 
 com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
 at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
 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}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted

[AMIT KUMAR (JIRA)]

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

AMIT KUMAR updated CASSANDRA-7838:
--
Attachment: (was: 0002-added-missing-winnt-native.patch)

 Warn user when disks are network/ebs mounted
 

 Key: CASSANDRA-7838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7838
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Priority: Minor
  Labels: bootcamp, lhf
 Fix For: 3.0


 The Sigar project let's you probe os/cpu/filesystems across the major 
 platforms.
 https://github.com/hyperic/sigar
 It would be nice on start-up to use this to warn users if they are running 
 with settings that will make them sad, like Network drive or EBS on Ec2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8018) Cassandra seems to insert twice in custom PerColumnSecondaryIndex

[Pavel Chlupacek (JIRA)]

Pavel Chlupacek created CASSANDRA-8018:
--

 Summary: Cassandra seems to insert twice in custom 
PerColumnSecondaryIndex
 Key: CASSANDRA-8018
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8018
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Pavel Chlupacek
 Fix For: 2.1.0


When inserting data into Cassandra 2.1.0 into table with custom secondary 
index, the Cell is inserted twice, if inserting new entry into row with same 
rowId, but different cluster index columns. 



CREATE KEYSPACE fulltext WITH replication = {'class': 'SimpleStrategy',  
'replication_factor' : 1};

CREATE TABLE fulltext.test ( id uuid, name text, name2 text, json varchar, 
lucene text, primary key ( id , name));

sCREATE CUSTOM INDEX lucene_idx on fulltext.test(lucene) using 
'com.spinoco.fulltext.cassandra.TestIndex'; 

// this causes only one insert
 insertInto(fulltext,test)
  .value(id, id1.uuid)
  .value(name, goosh1) 
  .value(json, TestContent.message1.asJson)

// this causes 2 inserts to be done 
 insertInto(fulltext,test)
.value(id, id1.uuid)
.value(name, goosh2)
.value(json, TestContent.message2.asJson)


/// stacktraces for inserts (always same, for 1st and 2nd insert)

custom indexer stacktraces and then
at 
org.apache.cassandra.db.index.SecondaryIndexManager$StandardUpdater.insert(SecondaryIndexManager.java:707)
at 
org.apache.cassandra.db.AtomicBTreeColumns$ColumnUpdater.apply(AtomicBTreeColumns.java:344)
at 
org.apache.cassandra.db.AtomicBTreeColumns$ColumnUpdater.apply(AtomicBTreeColumns.java:319)
at 
org.apache.cassandra.utils.btree.NodeBuilder.addNewKey(NodeBuilder.java:323)
at 
org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:191)
at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74)
at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186)
at 
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:189)
at org.apache.cassandra.db.Memtable.put(Memtable.java:194)
at 
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:394)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:351)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
at 
org.apache.cassandra.service.StorageProxy$7.runMayThrow(StorageProxy.java:970)
at 
org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2080)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at 
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:163)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
at java.lang.Thread.run(Thread.java:744)


 Note that cell, rowkey and Group in public abstract void insert(ByteBuffer 
rowKey, Cell col, OpOrder.Group opGroup); are having for both successive calls 
same identity 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted

[AMIT KUMAR (JIRA)]

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

AMIT KUMAR updated CASSANDRA-7838:
--
Attachment: (was: 
0001-CASSANDRA-7838-log-warning-for-networked-drives.patch)

 Warn user when disks are network/ebs mounted
 

 Key: CASSANDRA-7838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7838
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Priority: Minor
  Labels: bootcamp, lhf
 Fix For: 3.0


 The Sigar project let's you probe os/cpu/filesystems across the major 
 platforms.
 https://github.com/hyperic/sigar
 It would be nice on start-up to use this to warn users if they are running 
 with settings that will make them sad, like Network drive or EBS on Ec2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted

[AMIT KUMAR (JIRA)]

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

AMIT KUMAR updated CASSANDRA-7838:
--
Attachment: 0010-Minor-log-change-happy-path.patch
0009-Bug-fix-swap-check-was-incorrect-fixed-logging-state.patch
0008-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch
0007-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch
0006-added-missing-winnt-native.patch
0005-CASSANDRA-7838-log-warning-for-networked-drives.patch

new patches with corrected log statement and swap check fix.

 Warn user when disks are network/ebs mounted
 

 Key: CASSANDRA-7838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7838
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Priority: Minor
  Labels: bootcamp, lhf
 Fix For: 3.0

 Attachments: 
 0005-CASSANDRA-7838-log-warning-for-networked-drives.patch, 
 0006-added-missing-winnt-native.patch, 
 0007-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch, 
 0008-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch, 
 0009-Bug-fix-swap-check-was-incorrect-fixed-logging-state.patch, 
 0010-Minor-log-change-happy-path.patch


 The Sigar project let's you probe os/cpu/filesystems across the major 
 platforms.
 https://github.com/hyperic/sigar
 It would be nice on start-up to use this to warn users if they are running 
 with settings that will make them sad, like Network drive or EBS on Ec2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7838) Warn user when disks are network/ebs mounted

[AMIT KUMAR (JIRA)]

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

AMIT KUMAR commented on CASSANDRA-7838:
---

Sorry for the swap disable snafu -I made the fix and the changed the log 
statements

Attached are the patches from the trunk.

-I am a little hesitant in saying OK in the happy path scenario, because we 
have not checked everything that could lead to bad performance of Cassandra  
due to sysctl and hardware issues and saying OK might give a false sense of 
security.

Let me know if you see any other issues -thanks for your help.

 Warn user when disks are network/ebs mounted
 

 Key: CASSANDRA-7838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7838
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Priority: Minor
  Labels: bootcamp, lhf
 Fix For: 3.0

 Attachments: 
 0001-CASSANDRA-7838-log-warning-for-networked-drives.patch, 
 0002-added-missing-winnt-native.patch, 
 0003-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch, 
 0004-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch


 The Sigar project let's you probe os/cpu/filesystems across the major 
 platforms.
 https://github.com/hyperic/sigar
 It would be nice on start-up to use this to warn users if they are running 
 with settings that will make them sad, like Network drive or EBS on Ec2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted

[AMIT KUMAR (JIRA)]

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

AMIT KUMAR updated CASSANDRA-7838:
--
Attachment: (was: 
0003-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch)

 Warn user when disks are network/ebs mounted
 

 Key: CASSANDRA-7838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7838
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Priority: Minor
  Labels: bootcamp, lhf
 Fix For: 3.0


 The Sigar project let's you probe os/cpu/filesystems across the major 
 platforms.
 https://github.com/hyperic/sigar
 It would be nice on start-up to use this to warn users if they are running 
 with settings that will make them sad, like Network drive or EBS on Ec2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7523) add date and time types

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-7523:
---
Labels: docs  (was: )

 add date and time types
 ---

 Key: CASSANDRA-7523
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7523
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Jonathan Ellis
Assignee: Joshua McKenzie
Priority: Minor
  Labels: docs
 Fix For: 2.1.1, 3.0


 http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
 (we already have timestamp; interval is out of scope for now, and see 
 CASSANDRA-6350 for discussion on timestamp-with-time-zone.  but date/time 
 should be pretty easy to add.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted

[AMIT KUMAR (JIRA)]

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

AMIT KUMAR updated CASSANDRA-7838:
--
Attachment: (was: 
0004-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch)

 Warn user when disks are network/ebs mounted
 

 Key: CASSANDRA-7838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7838
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Priority: Minor
  Labels: bootcamp, lhf
 Fix For: 3.0


 The Sigar project let's you probe os/cpu/filesystems across the major 
 platforms.
 https://github.com/hyperic/sigar
 It would be nice on start-up to use this to warn users if they are running 
 with settings that will make them sad, like Network drive or EBS on Ec2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error

[Philip Thompson (JIRA)]

Philip Thompson created CASSANDRA-8019:
--

 Summary: Windows Unit tests and Dtests erroring due to sstable 
deleting task error
 Key: CASSANDRA-8019
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows 7
Reporter: Philip Thompson
 Fix For: 2.1.1


Currently a large number of dtests and unit tests are erroring on windows with 
the following error in the node log:
{code}
ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383 SSTableDeletingTask.java:89 
- Unable to delete 
c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
 (it will be removed on server restart; we'll also retry after GC)\n
{code}

git bisect points to the following commit:
{code}
0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
commit 0e831007760bffced8687f51b99525b650d7e193
Author: Benedict Elliott Smith bened...@apache.org
Date:  Fri Sep 19 18:17:19 2014 +0100

Fix resource leak in event of corrupt sstable

patch by benedict; review by yukim for CASSANDRA-7932

:100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681 
f55e5d27c1c53db3485154cd16201fc5419f32df M  CHANGES.txt
:04 04 194f4c0569b6be9cc9e129c441433c5c14de7249 
3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M  src
:04 04 64f49266e328b9fdacc516c52ef1921fe42e994f 
de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M  test
{code}

You can reproduce this by running simple_bootstrap_test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8008) Timed out waiting for timer thread on large stress command

[Shawn Kumar (JIRA)]

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

Shawn Kumar commented on CASSANDRA-8008:


Was able to reproduce locally on a single node running stock 2.1.0 as well, 
attached an additional thread dump.

 Timed out waiting for timer thread on large stress command
 

 Key: CASSANDRA-8008
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Shawn Kumar
 Attachments: node1-2.log, node1.log, node2-2.log, node2.log, 
 perftest.log


 I've been using cstar_perf to test a performance scenario and was able to 
 reproduce this error on a two node cluster with stock 2.1.0 while carrying 
 out large stress writes (50M keys):
 {noformat}
 java.lang.RuntimeException: Timed out waiting for a timer thread - seems one 
 got stuck
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
 at 
 org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
 at 
 org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
 at 
 org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
 at java.lang.Thread.run(Thread.java:745)
 {noformat}
 It looks like a similar error to that found in CASSANDRA-6943. I've also 
 attached the test log and thread dumps. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8008) Timed out waiting for timer thread on large stress command

[Shawn Kumar (JIRA)]

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

Shawn Kumar updated CASSANDRA-8008:
---
Attachment: file.log

Locally on single node of 2.1.0

 Timed out waiting for timer thread on large stress command
 

 Key: CASSANDRA-8008
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Shawn Kumar
 Attachments: file.log, node1-2.log, node1.log, node2-2.log, 
 node2.log, perftest.log


 I've been using cstar_perf to test a performance scenario and was able to 
 reproduce this error on a two node cluster with stock 2.1.0 while carrying 
 out large stress writes (50M keys):
 {noformat}
 java.lang.RuntimeException: Timed out waiting for a timer thread - seems one 
 got stuck
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
 at 
 org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
 at 
 org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
 at 
 org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
 at java.lang.Thread.run(Thread.java:745)
 {noformat}
 It looks like a similar error to that found in CASSANDRA-6943. I've also 
 attached the test log and thread dumps. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (CASSANDRA-8008) Timed out waiting for timer thread on large stress command

[Shawn Kumar (JIRA)]

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

Shawn Kumar updated CASSANDRA-8008:
---
Comment: was deleted

(was: Locally on single node of 2.1.0)

 Timed out waiting for timer thread on large stress command
 

 Key: CASSANDRA-8008
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Shawn Kumar
 Attachments: file.log, node1-2.log, node1.log, node2-2.log, 
 node2.log, perftest.log


 I've been using cstar_perf to test a performance scenario and was able to 
 reproduce this error on a two node cluster with stock 2.1.0 while carrying 
 out large stress writes (50M keys):
 {noformat}
 java.lang.RuntimeException: Timed out waiting for a timer thread - seems one 
 got stuck
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
 at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
 at 
 org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
 at 
 org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
 at 
 org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
 at java.lang.Thread.run(Thread.java:745)
 {noformat}
 It looks like a similar error to that found in CASSANDRA-6943. I've also 
 attached the test log and thread dumps. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-8019:


Trunk isn't having any issues so this is probably related to the 
FILE_SHARE_DELETE flag problems we addressed with CASSANDRA-4050.  Also - 
simple unit tests are failing on Windows w/this in 2.1 branch so no need to go 
so far as dtesting to reproduce.

 Windows Unit tests and Dtests erroring due to sstable deleting task error
 -

 Key: CASSANDRA-8019
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows 7
Reporter: Philip Thompson
  Labels: windows
 Fix For: 2.1.1


 Currently a large number of dtests and unit tests are erroring on windows 
 with the following error in the node log:
 {code}
 ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383 
 SSTableDeletingTask.java:89 - Unable to delete 
 c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
  (it will be removed on server restart; we'll also retry after GC)\n
 {code}
 git bisect points to the following commit:
 {code}
 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
 commit 0e831007760bffced8687f51b99525b650d7e193
 Author: Benedict Elliott Smith bened...@apache.org
 Date:  Fri Sep 19 18:17:19 2014 +0100
 Fix resource leak in event of corrupt sstable
 patch by benedict; review by yukim for CASSANDRA-7932
 :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681 
 f55e5d27c1c53db3485154cd16201fc5419f32df M  CHANGES.txt
 :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249 
 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M  src
 :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f 
 de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M  test
 {code}
 You can reproduce this by running simple_bootstrap_test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie edited comment on CASSANDRA-8019 at 9/29/14 6:16 PM:
-

Trunk isn't having any issues so this is probably related to the 
FILE_SHARE_DELETE flag problems we addressed with CASSANDRA-4050.  Also - 
simple unit tests are failing on Windows w/this in 2.1 branch so no need to go 
so far as dtesting to reproduce.

edit: I should mention - a cursory inspection of the changes in here look like 
the try w/resources idiom should have closed the ScannerList references as 
expected.  [~benedict]: any initial thoughts, other than those that led to 
CASSANDRA-7705?


was (Author: joshuamckenzie):
Trunk isn't having any issues so this is probably related to the 
FILE_SHARE_DELETE flag problems we addressed with CASSANDRA-4050.  Also - 
simple unit tests are failing on Windows w/this in 2.1 branch so no need to go 
so far as dtesting to reproduce.

 Windows Unit tests and Dtests erroring due to sstable deleting task error
 -

 Key: CASSANDRA-8019
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows 7
Reporter: Philip Thompson
  Labels: windows
 Fix For: 2.1.1


 Currently a large number of dtests and unit tests are erroring on windows 
 with the following error in the node log:
 {code}
 ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383 
 SSTableDeletingTask.java:89 - Unable to delete 
 c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
  (it will be removed on server restart; we'll also retry after GC)\n
 {code}
 git bisect points to the following commit:
 {code}
 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
 commit 0e831007760bffced8687f51b99525b650d7e193
 Author: Benedict Elliott Smith bened...@apache.org
 Date:  Fri Sep 19 18:17:19 2014 +0100
 Fix resource leak in event of corrupt sstable
 patch by benedict; review by yukim for CASSANDRA-7932
 :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681 
 f55e5d27c1c53db3485154cd16201fc5419f32df M  CHANGES.txt
 :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249 
 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M  src
 :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f 
 de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M  test
 {code}
 You can reproduce this by running simple_bootstrap_test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8011) Fail on large batch sizes

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian updated CASSANDRA-8011:
--
Attachment: 8011-trunk-v2.txt

Adding a v2 which address [~kohlisankalp]'s comments.

 Fail on large batch sizes 
 --

 Key: CASSANDRA-8011
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Assignee: Carl Yeksigian
Priority: Minor
 Fix For: 3.0

 Attachments: 8011-trunk-v2.txt, 8011-trunk.txt


 Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
 Just education alone is not going to stop some of the largest batch sizes 
 from being used. Just like we have a tombstone fail threshold, I propose that 
 we have a batch size fail threshold.
 Maybe 10x warn?
 {{batch_fail_threshold: 50k}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-8011) Fail on large batch sizes

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian updated CASSANDRA-8011:
--
Reviewer: sankalp kohli

 Fail on large batch sizes 
 --

 Key: CASSANDRA-8011
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Assignee: Carl Yeksigian
Priority: Minor
 Fix For: 3.0

 Attachments: 8011-trunk-v2.txt, 8011-trunk.txt


 Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
 Just education alone is not going to stop some of the largest batch sizes 
 from being used. Just like we have a tombstone fail threshold, I propose that 
 we have a batch size fail threshold.
 Maybe 10x warn?
 {{batch_fail_threshold: 50k}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7734) Schema pushes (seemingly) randomly not happening

[graham sanderson (JIRA)]

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

graham sanderson commented on CASSANDRA-7734:
-

Giving this a little nudge - I am happy to take a look, but I don't really 
understand what the intention is with the original code (i.e. lifecycle of 
{{IncomingTcpConnection}})

 Schema pushes (seemingly) randomly not happening
 

 Key: CASSANDRA-7734
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7734
 Project: Cassandra
  Issue Type: Bug
Reporter: graham sanderson
Assignee: Aleksey Yeschenko

 We have been seeing problems since upgrade to 2.0.9 from 2.0.5.
 Basically after a while, new schema changes (we periodically add tables) 
 start propagating very slowly to some nodes and fast to others. It looks from 
 the logs and trace that in this case the push of the schema never happens 
 (note a node has decided not to push to another node, it doesn't seem to 
 start again) from the originating node to some of the other nodes. In this 
 case though, we do see the other node end up pulling the schema some time 
 later when it notices its schema is out of date.
 Here is code from 2.0.9 MigrationManager.announce
 {code}
for (InetAddress endpoint : Gossiper.instance.getLiveMembers())
 {
 // only push schema to nodes with known and equal versions
 if (!endpoint.equals(FBUtilities.getBroadcastAddress()) 
 MessagingService.instance().knowsVersion(endpoint) 
 MessagingService.instance().getRawVersion(endpoint) == 
 MessagingService.current_version)
 pushSchemaMutation(endpoint, schema);
 }
 {code}
 and from 2.0.5
 {code}
 for (InetAddress endpoint : Gossiper.instance.getLiveMembers())
 {
 if (endpoint.equals(FBUtilities.getBroadcastAddress()))
 continue; // we've dealt with localhost already
 // don't send schema to the nodes with the versions older than 
 current major
 if (MessagingService.instance().getVersion(endpoint)  
 MessagingService.current_version)
 continue;
 pushSchemaMutation(endpoint, schema);
   }
 {code}
 the old getVersion() call would return MessagingService.current_version if 
 the version was unknown, so the push would occur in this case. I don't have 
 logging to prove this, but have strong suspicion that the version may end up 
 null in some cases (which would have allowed schema propagation in 2.0.5, but 
 not by somewhere after that and = 2.0.9)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8021) Improve cqlsh autocomplete for alter keyspace

[Philip Thompson (JIRA)]

Philip Thompson created CASSANDRA-8021:
--

 Summary: Improve cqlsh autocomplete for alter keyspace
 Key: CASSANDRA-8021
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8021
 Project: Cassandra
  Issue Type: Improvement
Reporter: Philip Thompson
Assignee: Philip Thompson
Priority: Minor
 Fix For: 2.0.11


Cqlsh autocomplete stops giving suggestions for the statement
{code}ALTER KEYSPACE k WITH REPLICATION { 'class' : 'SimpleStrategy', 
'replication_factor' : 1'};{code} after the word WITH.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6904) commitlog segments may not be archived after restart

[Charles Cao (JIRA)]

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

Charles Cao commented on CASSANDRA-6904:


Is there anybody reviewing the patch now?

 commitlog segments may not be archived after restart
 

 Key: CASSANDRA-6904
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6904
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jonathan Ellis
Assignee: Sam Tunnicliffe
 Fix For: 2.0.11, 2.1.1

 Attachments: 2.0-6904.txt, 2.1-6904-v2.txt, 2.1-6904.txt


 commitlog segments are archived when they are full, so the current active 
 segment will not be archived on restart (and its contents will not be 
 available for pitr).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots

[Jeronimo A Barros (JIRA)]

Jeronimo A Barros created CASSANDRA-8020:


 Summary: nodetool repair on Cassandra 2.1.0 indexed tables returns 
java exception about creating snapshots
 Key: CASSANDRA-8020
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
 Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel 
3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB RAM
Reporter: Jeronimo A Barros
 Fix For: 2.1.0


Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java 
exception about creating snapshots:

Command line:
{noformat}
[2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec 
for range (-7298689860784559350,-7297558156602685286] failed with error 
java.io.IOException: Failed during snapshot creation.
[2014-09-29 11:25:24,945] Repair command #5 finished
{noformat}
Cassandra log:
{noformat}
ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 - Repair 
session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range 
(-7298689860784559350,-7297558156602685286] failed with error 
java.io.IOException: Failed during snapshot creation.
java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
java.io.IOException: Failed during snapshot creation.
at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
[na:1.7.0_67]
at java.util.concurrent.FutureTask.get(FutureTask.java:188) 
[na:1.7.0_67]
at 
org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
 ~[apache-cassandra-2.1.0.jar:2.1.0]
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
[apache-cassandra-2.1.0.jar:2.1.0]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
[na:1.7.0_67]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
Caused by: java.lang.RuntimeException: java.io.IOException: Failed during 
snapshot creation.
at com.google.common.base.Throwables.propagate(Throwables.java:160) 
~[guava-16.0.jar:na]
at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32) 
[apache-cassandra-2.1.0.jar:2.1.0]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
[na:1.7.0_67]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
[na:1.7.0_67]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
~[na:1.7.0_67]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
~[na:1.7.0_67]
... 1 common frames omitted
Caused by: java.io.IOException: Failed during snapshot creation.
at 
org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
 ~[apache-cassandra-2.1.0.jar:2.1.0]
at 
org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128) 
~[apache-cassandra-2.1.0.jar:2.1.0]
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172) 
~[guava-16.0.jar:na]
... 3 common frames omitted
{noformat}
If the index is dropped, the repair returns no error:
{noformat}
cqlsh:test drop INDEX user_pass_idx ;

root@test:~# nodetool repair test user
[2014-09-29 11:27:29,668] Starting repair command #6, repairing 743 ranges for 
keyspace test (seq=true, full=true)
.
.
[2014-09-29 11:28:38,030] Repair session e6d40e10-47e4-11e4-ba0f-c7788dc924ec 
for range (-7298689860784559350,-7297558156602685286] finished
[2014-09-29 11:28:38,030] Repair command #6 finished
{noformat}
The test table:
{noformat}
CREATE TABLE test.user (
login text PRIMARY KEY,
password text
)
create INDEX user_pass_idx on test.user (password) ;
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8016) Auth tables should use higher consistency level

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-8016:
---

I think the reasoning was to maximize availability.  Better to run with out of 
date permissions, than not run at all.

 Auth tables should use higher consistency level
 ---

 Key: CASSANDRA-8016
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8016
 Project: Cassandra
  Issue Type: Bug
Reporter: T Jake Luciani
 Fix For: 2.0.11


 The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of 
 the superuser.
 Since the Auth keyspace is created with RF=1 the default experience is fine.
 However if you change to RF  1 suddenly the select statements are open to 
 misses.
 We should change reads/writes in Auth, PasswordAuthenticator, 
 CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM.
 For reads we could optimize the code to start with CL.ONE and on a miss 
 increase to CL.QUORUM



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname

[Matthew O'Riordan (JIRA)]

Matthew O'Riordan created CASSANDRA-8022:


 Summary: cqlsh hangs indefinitely within a Docker container 
connecting to itself with hostname
 Key: CASSANDRA-8022
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 
container.  
Reporter: Matthew O'Riordan
 Fix For: 2.1.0


I am unable to use the `cqlsh` tool within a Docker container running 
Cassandra.  Previously I would use the Java  Thrift based `cqlsh` tool as 
follows:

```
cqlsh --username cassandra --password whatever $(hostname)
```

When I run the `cqlsh` command after attaching to a running container (I use 
LXC containerisation that allows attaching to a running container and running a 
console), it simply hangs and never reports an error.  With the `--debug` flag 
on, I get the following with:

**cqlsh 4.1.1**

```
$ cqlsh --debug --username cassandra --password obfuscated $(hostname) 
Using CQL driver: module 'cql' from 
'/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'
Using thrift lib: module 'thrift' from 
'/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'
```
It then hangs in this state indefinitely, I have no errors from `cqlsh` and no 
errors in the Cassandra log.

**cqlsh 5.0.1**

```
$ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) 
Using CQL driver: module 'cassandra' from 
'/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'
```
It then also hangs in this state indefinitely, I have no errors from `cqlsh` 
and no errors in the Cassandra log.

What's interesting, and quite confusing is that:

* I can telnet within the container as follows `telnet $(hostname) 9042` and I 
get a socket.  When trying to issue some commands, I see Protocol errors in the 
Cassandra log thus verifying that the port is indeed open on the host that 
resolves from $(hostname)
* If I `cqlsh` from another container or another host to the Cassandra 
container it works just fine.
* I have tried disabling authentication altogether and using the 
AllowAllAuthenticator, and I experience the same problem.
* `nodetool` works fine

In the mean time, I am forced to `cqlsh` from another container as a 
workaround.  Happy to try and do anything require to diagnose the cause of this 
problem.









--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6246) EPaxos

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-6246:
--

Currently we do a read on quorum/local_quorum and based on that value decide if 
the condition matches at the co-ordinator. 
With you approach, the decisions will now be local and could be different on 
different replicas. If some replica some how lags behind due to various 
reasons, the condition on it will never be satisfied going forward. 

Coming back to my suggestion from previous comment, if all replicas respond 
back with all committed before this instance and things are the same, we can 
use the read value. Correct?  

 EPaxos
 --

 Key: CASSANDRA-6246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Blake Eggleston
Priority: Minor

 One reason we haven't optimized our Paxos implementation with Multi-paxos is 
 that Multi-paxos requires leader election and hence, a period of 
 unavailability when the leader dies.
 EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
 (2) is particularly useful across multiple datacenters, and (3) allows any 
 node to act as coordinator: 
 http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
 However, there is substantial additional complexity involved if we choose to 
 implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-8020:
---

It looks like there was an error while trying to create the snapshot. Can you 
look through the logs for Error occurred during snapshot phase? This will 
help pin down the original cause of the failed repair.

 nodetool repair on Cassandra 2.1.0 indexed tables returns java exception 
 about creating snapshots
 -

 Key: CASSANDRA-8020
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
 Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel 
 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB 
 RAM
Reporter: Jeronimo A Barros
  Labels: newbie
 Fix For: 2.1.0

   Original Estimate: 24h
  Remaining Estimate: 24h

 Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java 
 exception about creating snapshots:
 Command line:
 {noformat}
 [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec 
 for range (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 [2014-09-29 11:25:24,945] Repair command #5 finished
 {noformat}
 Cassandra log:
 {noformat}
 ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 - 
 Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range 
 (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
 java.io.IOException: Failed during snapshot creation.
 at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.get(FutureTask.java:188) 
 [na:1.7.0_67]
 at 
 org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
  ~[apache-cassandra-2.1.0.jar:2.1.0]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [na:1.7.0_67]
 at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
 Caused by: java.lang.RuntimeException: java.io.IOException: Failed during 
 snapshot creation.
 at com.google.common.base.Throwables.propagate(Throwables.java:160) 
 ~[guava-16.0.jar:na]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [na:1.7.0_67]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_67]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_67]
 ... 1 common frames omitted
 Caused by: java.io.IOException: Failed during snapshot creation.
 at 
 org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
  ~[apache-cassandra-2.1.0.jar:2.1.0]
 at 
 org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128) 
 ~[apache-cassandra-2.1.0.jar:2.1.0]
 at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172) 
 ~[guava-16.0.jar:na]
 ... 3 common frames omitted
 {noformat}
 If the index is dropped, the repair returns no error:
 {noformat}
 cqlsh:test drop INDEX user_pass_idx ;
 root@test:~# nodetool repair test user
 [2014-09-29 11:27:29,668] Starting repair command #6, repairing 743 ranges 
 for keyspace test (seq=true, full=true)
 .
 .
 [2014-09-29 11:28:38,030] Repair session e6d40e10-47e4-11e4-ba0f-c7788dc924ec 
 for range (-7298689860784559350,-7297558156602685286] finished
 [2014-09-29 11:28:38,030] Repair command #6 finished
 {noformat}
 The test table:
 {noformat}
 CREATE TABLE test.user (
 login text PRIMARY KEY,
 password text
 )
 create INDEX user_pass_idx on test.user (password) ;
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6246) EPaxos

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-6246:


[~tjake] that'll solve the problem of having multiple mutations at a single 
timestamp, but might cause other problems when the calculated execution order 
puts an instance after an instance with a larger timestamp. Using arbitrary 
timestamps in uuid1s in this case might cause come collisions, but they 
wouldn't be on the same cells. In any case, collisions would be less likely 
than they are now.

 EPaxos
 --

 Key: CASSANDRA-6246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Blake Eggleston
Priority: Minor

 One reason we haven't optimized our Paxos implementation with Multi-paxos is 
 that Multi-paxos requires leader election and hence, a period of 
 unavailability when the leader dies.
 EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
 (2) is particularly useful across multiple datacenters, and (3) allows any 
 node to act as coordinator: 
 http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
 However, there is substantial additional complexity involved if we choose to 
 implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots

[Jeronimo A Barros (JIRA)]

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

Jeronimo A Barros commented on CASSANDRA-8020:
--

Carl, no Error occurred during snapshot phase. But I took another look (yes, 
I should have done this before) and the beginning of the nodetool repair 
points to the AntiEntropyStage class:

{noformat}
NFO  [Thread-49681] 2014-09-29 11:25:22,787 StorageService.java:2595 - Starting 
repair command #5, repairing 743 ranges for keyspace test (seq=true, full=true)
INFO  [AntiEntropySessions:17] 2014-09-29 11:25:24,264 RepairSession.java:260 - 
[repair #736daa80-47e4-11e4-ba0f-c7788dc924ec] new session: will sync 
c1.test.net/192.168.33.248, /192.168.33.250, /192.168.33.252 on range 
(-7990332010750800111,-7986163865225197304] for test.[user]
ERROR [AntiEntropyStage:1487] 2014-09-29 11:25:24,265 CassandraDaemon.java:166 
- Exception in thread Thread[AntiEntropyStage:1487,5,main]
java.lang.ClassCastException: null
ERROR [RepairJobTask:3] 2014-09-29 11:25:24,266 RepairJob.java:127 - Error 
occurred during snapshot phase
java.lang.RuntimeException: Could not create snapshot at /192.168.33.248
at 
org.apache.cassandra.repair.SnapshotTask$SnapshotCallback.onFailure(SnapshotTask.java:77)
 ~[apache-cassandra-2.1.0.jar:2.1.0]
at 
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:48)
 ~[apache-cassandra-2.1.0.jar:2.1.0]
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
~[apache-cassandra-2.1.0.jar:2.1.0]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
[na:1.7.0_67]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
ERROR [AntiEntropySessions:17] 2014-09-29 11:25:24,266 RepairSession.java:303 - 
[repair #736daa80-47e4-11e4-ba0f-c7788dc924ec] session completed with the 
following error
java.io.IOException: Failed during snapshot creation.
at 
org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
 ~[apache-cassandra-2.1.0.jar:2.1.0]
at 
org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128) 
~[apache-cassandra-2.1.0.jar:2.1.0]
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172) 
~[guava-16.0.jar:na]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
[na:1.7.0_67]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
{noformat}

I'm attaching the full log of the error.

 nodetool repair on Cassandra 2.1.0 indexed tables returns java exception 
 about creating snapshots
 -

 Key: CASSANDRA-8020
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
 Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel 
 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB 
 RAM
Reporter: Jeronimo A Barros
  Labels: newbie
 Fix For: 2.1.0

   Original Estimate: 24h
  Remaining Estimate: 24h

 Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java 
 exception about creating snapshots:
 Command line:
 {noformat}
 [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec 
 for range (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 [2014-09-29 11:25:24,945] Repair command #5 finished
 {noformat}
 Cassandra log:
 {noformat}
 ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 - 
 Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range 
 (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
 java.io.IOException: Failed during snapshot creation.
 at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.get(FutureTask.java:188) 
 [na:1.7.0_67]
 at 
 org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
  ~[apache-cassandra-2.1.0.jar:2.1.0]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 

[jira] [Updated] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots

[Jeronimo A Barros (JIRA)]

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

Jeronimo A Barros updated CASSANDRA-8020:
-
Attachment: system.log.2014-09-29_1127

nodetool repair system.log

 nodetool repair on Cassandra 2.1.0 indexed tables returns java exception 
 about creating snapshots
 -

 Key: CASSANDRA-8020
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
 Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel 
 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB 
 RAM
Reporter: Jeronimo A Barros
  Labels: newbie
 Fix For: 2.1.0

 Attachments: system.log.2014-09-29_1127

   Original Estimate: 24h
  Remaining Estimate: 24h

 Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java 
 exception about creating snapshots:
 Command line:
 {noformat}
 [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec 
 for range (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 [2014-09-29 11:25:24,945] Repair command #5 finished
 {noformat}
 Cassandra log:
 {noformat}
 ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 - 
 Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range 
 (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
 java.io.IOException: Failed during snapshot creation.
 at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.get(FutureTask.java:188) 
 [na:1.7.0_67]
 at 
 org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
  ~[apache-cassandra-2.1.0.jar:2.1.0]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [na:1.7.0_67]
 at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
 Caused by: java.lang.RuntimeException: java.io.IOException: Failed during 
 snapshot creation.
 at com.google.common.base.Throwables.propagate(Throwables.java:160) 
 ~[guava-16.0.jar:na]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [na:1.7.0_67]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_67]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_67]
 ... 1 common frames omitted
 Caused by: java.io.IOException: Failed during snapshot creation.
 at 
 org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
  ~[apache-cassandra-2.1.0.jar:2.1.0]
 at 
 org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128) 
 ~[apache-cassandra-2.1.0.jar:2.1.0]
 at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172) 
 ~[guava-16.0.jar:na]
 ... 3 common frames omitted
 {noformat}
 If the index is dropped, the repair returns no error:
 {noformat}
 cqlsh:test drop INDEX user_pass_idx ;
 root@test:~# nodetool repair test user
 [2014-09-29 11:27:29,668] Starting repair command #6, repairing 743 ranges 
 for keyspace test (seq=true, full=true)
 .
 .
 [2014-09-29 11:28:38,030] Repair session e6d40e10-47e4-11e4-ba0f-c7788dc924ec 
 for range (-7298689860784559350,-7297558156602685286] finished
 [2014-09-29 11:28:38,030] Repair command #6 finished
 {noformat}
 The test table:
 {noformat}
 CREATE TABLE test.user (
 login text PRIMARY KEY,
 password text
 )
 create INDEX user_pass_idx on test.user (password) ;
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6246) EPaxos

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-6246:


[~kohlisankalp] right, the incrementing ballot numbers per partition in the 
current implementation, and the quorum read basically synchronizes r/w for the 
partition being queried. But that synchronization creates a bottleneck, and the 
potential for live lock.

Epaxos doesn't need to synchronize any of it's reads or writes. The preaccept, 
accept, and commit steps are basically building a directed graph of queries. 
The constraints those steps impose/satisfy allow other nodes to figure out the 
state of the graph on other machines in case of failure, provided it can talk 
to a quorum of nodes, and even if the machines with a newer view of the graph 
are down. At execution time, this graph is sorted to determine the execution 
order. Since the graph will always be the same, the order instances are 
executed will always be the same. So even though each machine will perform it's 
read and write in isolation, the other nodes are guaranteed to execute 
instances in the same order, and therefore, guaranteed to reach the same 
decision. Even though they aren't talking to each other at execution time.

What can cause inconsistencies, since each node is executing instances in 
isolation, is users mixing serialized writes with unserialized writes. The 
quorum read/write in the current implementation mitigates this problem. 
However, like I mentioned in my comment yesterday, I think we can work out a 
way to detect and correct this.

 EPaxos
 --

 Key: CASSANDRA-6246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Blake Eggleston
Priority: Minor

 One reason we haven't optimized our Paxos implementation with Multi-paxos is 
 that Multi-paxos requires leader election and hence, a period of 
 unavailability when the leader dies.
 EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
 (2) is particularly useful across multiple datacenters, and (3) allows any 
 node to act as coordinator: 
 http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
 However, there is substantial additional complexity involved if we choose to 
 implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie reassigned CASSANDRA-8019:
--

Assignee: Joshua McKenzie

 Windows Unit tests and Dtests erroring due to sstable deleting task error
 -

 Key: CASSANDRA-8019
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
 Project: Cassandra
  Issue Type: Bug
 Environment: Windows 7
Reporter: Philip Thompson
Assignee: Joshua McKenzie
  Labels: windows
 Fix For: 2.1.1


 Currently a large number of dtests and unit tests are erroring on windows 
 with the following error in the node log:
 {code}
 ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383 
 SSTableDeletingTask.java:89 - Unable to delete 
 c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
  (it will be removed on server restart; we'll also retry after GC)\n
 {code}
 git bisect points to the following commit:
 {code}
 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
 commit 0e831007760bffced8687f51b99525b650d7e193
 Author: Benedict Elliott Smith bened...@apache.org
 Date:  Fri Sep 19 18:17:19 2014 +0100
 Fix resource leak in event of corrupt sstable
 patch by benedict; review by yukim for CASSANDRA-7932
 :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681 
 f55e5d27c1c53db3485154cd16201fc5419f32df M  CHANGES.txt
 :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249 
 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M  src
 :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f 
 de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M  test
 {code}
 You can reproduce this by running simple_bootstrap_test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-8020:
---

Confirmed.

When snapshotting, replica node is throwing the following on indexed table:

{code}
ERROR [AntiEntropyStage:768] 2014-09-29 17:34:25,654 CassandraDaemon.java:166 - 
Exception in thread Thread[AntiEntropyStage:768,5,main]
java.lang.ClassCastException: java.lang.Long cannot be cast to 
java.nio.ByteBuffer
at org.apache.cassandra.db.marshal.BytesType.compare(BytesType.java:29) 
~[main/:na]
at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:44) 
~[main/:na]
at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:24) 
~[main/:na]
at org.apache.cassandra.dht.Range.contains(Range.java:71) ~[main/:na]
at org.apache.cassandra.dht.Range.contains(Range.java:111) ~[main/:na]
at org.apache.cassandra.dht.Range.intersects(Range.java:142) ~[main/:na]
at org.apache.cassandra.dht.Range.intersects(Range.java:129) ~[main/:na]
at 
org.apache.cassandra.dht.AbstractBounds.intersects(AbstractBounds.java:83) 
~[main/:na]
at 
org.apache.cassandra.repair.RepairMessageVerbHandler$1.apply(RepairMessageVerbHandler.java:83)
 ~[main/:na]
at 
org.apache.cassandra.repair.RepairMessageVerbHandler$1.apply(RepairMessageVerbHandler.java:80)
 ~[main/:na]
at 
org.apache.cassandra.db.ColumnFamilyStore.snapshotWithoutFlush(ColumnFamilyStore.java:2152)
 ~[main/:na]
at 
org.apache.cassandra.db.ColumnFamilyStore.snapshot(ColumnFamilyStore.java:2215) 
~[main/:na]
at 
org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:79)
 ~[main/:na]
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) 
~[main/:na]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
~[na:1.7.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
~[na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) ~[na:1.7.0_51]
{code}

 nodetool repair on Cassandra 2.1.0 indexed tables returns java exception 
 about creating snapshots
 -

 Key: CASSANDRA-8020
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
 Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel 
 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB 
 RAM
Reporter: Jeronimo A Barros
  Labels: newbie
 Fix For: 2.1.0

 Attachments: system.log.2014-09-29_1127

   Original Estimate: 24h
  Remaining Estimate: 24h

 Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java 
 exception about creating snapshots:
 Command line:
 {noformat}
 [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec 
 for range (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 [2014-09-29 11:25:24,945] Repair command #5 finished
 {noformat}
 Cassandra log:
 {noformat}
 ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 - 
 Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range 
 (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
 java.io.IOException: Failed during snapshot creation.
 at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.get(FutureTask.java:188) 
 [na:1.7.0_67]
 at 
 org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
  ~[apache-cassandra-2.1.0.jar:2.1.0]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [na:1.7.0_67]
 at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
 Caused by: java.lang.RuntimeException: java.io.IOException: Failed during 
 snapshot creation.
 at com.google.common.base.Throwables.propagate(Throwables.java:160) 
 ~[guava-16.0.jar:na]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at 

[jira] [Commented] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-8020:
---

This is introduced in CASSANDRA-7024.

 nodetool repair on Cassandra 2.1.0 indexed tables returns java exception 
 about creating snapshots
 -

 Key: CASSANDRA-8020
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Tools
 Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel 
 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB 
 RAM
Reporter: Jeronimo A Barros
  Labels: newbie
 Fix For: 2.1.0

 Attachments: system.log.2014-09-29_1127

   Original Estimate: 24h
  Remaining Estimate: 24h

 Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java 
 exception about creating snapshots:
 Command line:
 {noformat}
 [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec 
 for range (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 [2014-09-29 11:25:24,945] Repair command #5 finished
 {noformat}
 Cassandra log:
 {noformat}
 ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 - 
 Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range 
 (-7298689860784559350,-7297558156602685286] failed with error 
 java.io.IOException: Failed during snapshot creation.
 java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
 java.io.IOException: Failed during snapshot creation.
 at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.get(FutureTask.java:188) 
 [na:1.7.0_67]
 at 
 org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
  ~[apache-cassandra-2.1.0.jar:2.1.0]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [na:1.7.0_67]
 at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
 Caused by: java.lang.RuntimeException: java.io.IOException: Failed during 
 snapshot creation.
 at com.google.common.base.Throwables.propagate(Throwables.java:160) 
 ~[guava-16.0.jar:na]
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32) 
 [apache-cassandra-2.1.0.jar:2.1.0]
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
 [na:1.7.0_67]
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [na:1.7.0_67]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  ~[na:1.7.0_67]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  ~[na:1.7.0_67]
 ... 1 common frames omitted
 Caused by: java.io.IOException: Failed during snapshot creation.
 at 
 org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
  ~[apache-cassandra-2.1.0.jar:2.1.0]
 at 
 org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128) 
 ~[apache-cassandra-2.1.0.jar:2.1.0]
 at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172) 
 ~[guava-16.0.jar:na]
 ... 3 common frames omitted
 {noformat}
 If the index is dropped, the repair returns no error:
 {noformat}
 cqlsh:test drop INDEX user_pass_idx ;
 root@test:~# nodetool repair test user
 [2014-09-29 11:27:29,668] Starting repair command #6, repairing 743 ranges 
 for keyspace test (seq=true, full=true)
 .
 .
 [2014-09-29 11:28:38,030] Repair session e6d40e10-47e4-11e4-ba0f-c7788dc924ec 
 for range (-7298689860784559350,-7297558156602685286] finished
 [2014-09-29 11:28:38,030] Repair command #6 finished
 {noformat}
 The test table:
 {noformat}
 CREATE TABLE test.user (
 login text PRIMARY KEY,
 password text
 )
 create INDEX user_pass_idx on test.user (password) ;
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname

[Mikhail Stepura (JIRA)]

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

Mikhail Stepura edited comment on CASSANDRA-8022 at 9/29/14 11:34 PM:
--

Can you enter commands into that hung cqlsh? 
Can you also check the output for {{lsof -a -p cqlsh_pid -d0,1,2}} ?



was (Author: mishail):
Can you enter commands into that hung cqlsh? 
Can you also check the output for {{ lsof -a -p cqlsh_pi -d0,1,2}} ?


 cqlsh hangs indefinitely within a Docker container connecting to itself with 
 hostname
 -

 Key: CASSANDRA-8022
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 
 container.  
Reporter: Matthew O'Riordan
 Fix For: 2.1.0


 I am unable to use the `cqlsh` tool within a Docker container running 
 Cassandra.  Previously I would use the Java  Thrift based `cqlsh` tool as 
 follows:
 ```
 cqlsh --username cassandra --password whatever $(hostname)
 ```
 When I run the `cqlsh` command after attaching to a running container (I use 
 LXC containerisation that allows attaching to a running container and running 
 a console), it simply hangs and never reports an error.  With the `--debug` 
 flag on, I get the following with:
 **cqlsh 4.1.1**
 ```
 $ cqlsh --debug --username cassandra --password obfuscated $(hostname) 
 Using CQL driver: module 'cql' from 
 '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'
 Using thrift lib: module 'thrift' from 
 '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'
 ```
 It then hangs in this state indefinitely, I have no errors from `cqlsh` and 
 no errors in the Cassandra log.
 **cqlsh 5.0.1**
 ```
 $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) 
 Using CQL driver: module 'cassandra' from 
 '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'
 ```
 It then also hangs in this state indefinitely, I have no errors from `cqlsh` 
 and no errors in the Cassandra log.
 What's interesting, and quite confusing is that:
 * I can telnet within the container as follows `telnet $(hostname) 9042` and 
 I get a socket.  When trying to issue some commands, I see Protocol errors in 
 the Cassandra log thus verifying that the port is indeed open on the host 
 that resolves from $(hostname)
 * If I `cqlsh` from another container or another host to the Cassandra 
 container it works just fine.
 * I have tried disabling authentication altogether and using the 
 AllowAllAuthenticator, and I experience the same problem.
 * `nodetool` works fine
 In the mean time, I am forced to `cqlsh` from another container as a 
 workaround.  Happy to try and do anything require to diagnose the cause of 
 this problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname

[Mikhail Stepura (JIRA)]

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

Mikhail Stepura commented on CASSANDRA-8022:


Can you enter commands into that hung cqlsh? 
Can you also check the output for {{ lsof -a -p cqlsh_pi -d0,1,2}} ?


 cqlsh hangs indefinitely within a Docker container connecting to itself with 
 hostname
 -

 Key: CASSANDRA-8022
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 
 container.  
Reporter: Matthew O'Riordan
 Fix For: 2.1.0


 I am unable to use the `cqlsh` tool within a Docker container running 
 Cassandra.  Previously I would use the Java  Thrift based `cqlsh` tool as 
 follows:
 ```
 cqlsh --username cassandra --password whatever $(hostname)
 ```
 When I run the `cqlsh` command after attaching to a running container (I use 
 LXC containerisation that allows attaching to a running container and running 
 a console), it simply hangs and never reports an error.  With the `--debug` 
 flag on, I get the following with:
 **cqlsh 4.1.1**
 ```
 $ cqlsh --debug --username cassandra --password obfuscated $(hostname) 
 Using CQL driver: module 'cql' from 
 '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'
 Using thrift lib: module 'thrift' from 
 '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'
 ```
 It then hangs in this state indefinitely, I have no errors from `cqlsh` and 
 no errors in the Cassandra log.
 **cqlsh 5.0.1**
 ```
 $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) 
 Using CQL driver: module 'cassandra' from 
 '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'
 ```
 It then also hangs in this state indefinitely, I have no errors from `cqlsh` 
 and no errors in the Cassandra log.
 What's interesting, and quite confusing is that:
 * I can telnet within the container as follows `telnet $(hostname) 9042` and 
 I get a socket.  When trying to issue some commands, I see Protocol errors in 
 the Cassandra log thus verifying that the port is indeed open on the host 
 that resolves from $(hostname)
 * If I `cqlsh` from another container or another host to the Cassandra 
 container it works just fine.
 * I have tried disabling authentication altogether and using the 
 AllowAllAuthenticator, and I experience the same problem.
 * `nodetool` works fine
 In the mean time, I am forced to `cqlsh` from another container as a 
 workaround.  Happy to try and do anything require to diagnose the cause of 
 this problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7949) LCS compaction low performance, many pending compactions, nodes are almost idle

[Nikolai Grigoriev (JIRA)]

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

Nikolai Grigoriev commented on CASSANDRA-7949:
--

Upgraded to Cassandra 2.0.10 (via DSE 4.5.2) today. Switched my tables that 
used STCS to LCS. Restarted. For last 8 hours I observe this on all nodes:

{code}
# nodetool compactionstats
pending tasks: 13808
  compaction typekeyspace   table   completed   
total  unit  progress
   Compaction  mykeyspacetable_1528230773591   
1616185183262 bytes32.68%
   Compaction  mykeyspace table_2456361916088   
4158821946280 bytes10.97%
Active compaction remaining time :   3h57m56s
{code}

In the beginning of these 8 hours the remaining time was about 4h08m. CPU 
activity - almost nothing (between 2 and 3 cores), disk I/O - nearly zero. So 
clearly it compacts in one thread per keyspace and almost does not progress.

 LCS compaction low performance, many pending compactions, nodes are almost 
 idle
 ---

 Key: CASSANDRA-7949
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7949
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: DSE 4.5.1-1, Cassandra 2.0.8
Reporter: Nikolai Grigoriev
 Attachments: iostats.txt, nodetool_compactionstats.txt, 
 nodetool_tpstats.txt, pending compactions 2day.png, system.log.gz, vmstat.txt


 I've been evaluating new cluster of 15 nodes (32 core, 6x800Gb SSD disks + 
 2x600Gb SAS, 128Gb RAM, OEL 6.5) and I've built a simulator that creates the 
 load similar to the load in our future product. Before running the simulator 
 I had to pre-generate enough data. This was done using Java code and DataStax 
 Java driver. To avoid going deep into details, two tables have been 
 generated. Each table currently has about 55M rows and between few dozens and 
 few thousands of columns in each row.
 This data generation process was generating massive amount of non-overlapping 
 data. Thus, the activity was write-only and highly parallel. This is not the 
 type of the traffic that the system will have ultimately to deal with, it 
 will be mix of reads and updates to the existing data in the future. This is 
 just to explain the choice of LCS, not mentioning the expensive SSD disk 
 space.
 At some point while generating the data I have noticed that the compactions 
 started to pile up. I knew that I was overloading the cluster but I still 
 wanted the genration test to complete. I was expecting to give the cluster 
 enough time to finish the pending compactions and get ready for real traffic.
 However, after the storm of write requests have been stopped I have noticed 
 that the number of pending compactions remained constant (and even climbed up 
 a little bit) on all nodes. After trying to tune some parameters (like 
 setting the compaction bandwidth cap to 0) I have noticed a strange pattern: 
 the nodes were compacting one of the CFs in a single stream using virtually 
 no CPU and no disk I/O. This process was taking hours. After that it would be 
 followed by a short burst of few dozens of compactions running in parallel 
 (CPU at 2000%, some disk I/O - up to 10-20%) and then getting stuck again for 
 many hours doing one compaction at time. So it looks like this:
 # nodetool compactionstats
 pending tasks: 3351
   compaction typekeyspace   table   completed 
   total  unit  progress
Compaction  myks table_list1 66499295588   
 1910515889913 bytes 3.48%
 Active compaction remaining time :n/a
 # df -h
 ...
 /dev/sdb1.5T  637G  854G  43% /cassandra-data/disk1
 /dev/sdc1.5T  425G  1.1T  29% /cassandra-data/disk2
 /dev/sdd1.5T  429G  1.1T  29% /cassandra-data/disk3
 # find . -name **table_list1**Data** | grep -v snapshot | wc -l
 1310
 Among these files I see:
 1043 files of 161Mb (my sstable size is 160Mb)
 9 large files - 3 between 1 and 2Gb, 3 of 5-8Gb, 55Gb, 70Gb and 370Gb
 263 files of various sized - between few dozens of Kb and 160Mb
 I've been running the heavy load for about 1,5days and it's been close to 3 
 days after that and the number of pending compactions does not go down.
 I have applied one of the not-so-obvious recommendations to disable 
 multithreaded compactions and that seems to be helping a bit - I see some 
 nodes started to have fewer pending compactions. About half of the cluster, 
 in fact. But even there I see they are sitting idle most of the time lazily 
 compacting in one stream with CPU at ~140% and occasionally doing the bursts 
 of compaction work for few minutes.
 I am wondering if this is really a bug 

[jira] [Commented] (CASSANDRA-6246) EPaxos

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-6246:
--

Inconsistencies can be introduced by machines being down or network partitioned 
for longer than we replay missed updates to it. Currently for normal writes, 
hint is for 1 hour. If you bring in a machine after 1 hour, you run a repair. 
But repair won't help here since it takes time to run the repair and new LWTs 
will come and will see a different view of the data and won't apply. 

However, like I mentioned in my comment yesterday, I think we can work out a 
way to detect and correct this.
+1

Assuming each instance is an average of ~170 bytes (uncompressed), sustained 
1000 instances per second for 3 hours would keep ~1.8GB of data around.
Here instance includes the condition and update. Update could be quite big and 
keeping it around could be problematic. 



 EPaxos
 --

 Key: CASSANDRA-6246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Blake Eggleston
Priority: Minor

 One reason we haven't optimized our Paxos implementation with Multi-paxos is 
 that Multi-paxos requires leader election and hence, a period of 
 unavailability when the leader dies.
 EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
 (2) is particularly useful across multiple datacenters, and (3) allows any 
 node to act as coordinator: 
 http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
 However, there is substantial additional complexity involved if we choose to 
 implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname

[Matthew O'Riordan (JIRA)]

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

Matthew O'Riordan commented on CASSANDRA-8022:
--

Yes, I can enter commands in, but they are simply echoed back to me, nothing 
happens.
I've attached another console to the container that is running cqlsh, and run 
the `lsof` command:

```
lsof -a -p 614 -d0,1,2
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
python  614 root0u   CHR 136,11  0t0 14 /dev/pts/11
python  614 root1w  FIFO0,8  0t0 661702 pipe
python  614 root2w  FIFO0,8  0t0 661702 pipe
```

PS. Sorry, I am not familiar with JIRA markup, and the link below does not work 
for help on the formatting, how do you mark text as code?



 cqlsh hangs indefinitely within a Docker container connecting to itself with 
 hostname
 -

 Key: CASSANDRA-8022
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 
 container.  
Reporter: Matthew O'Riordan
 Fix For: 2.1.0


 I am unable to use the `cqlsh` tool within a Docker container running 
 Cassandra.  Previously I would use the Java  Thrift based `cqlsh` tool as 
 follows:
 ```
 cqlsh --username cassandra --password whatever $(hostname)
 ```
 When I run the `cqlsh` command after attaching to a running container (I use 
 LXC containerisation that allows attaching to a running container and running 
 a console), it simply hangs and never reports an error.  With the `--debug` 
 flag on, I get the following with:
 **cqlsh 4.1.1**
 ```
 $ cqlsh --debug --username cassandra --password obfuscated $(hostname) 
 Using CQL driver: module 'cql' from 
 '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'
 Using thrift lib: module 'thrift' from 
 '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'
 ```
 It then hangs in this state indefinitely, I have no errors from `cqlsh` and 
 no errors in the Cassandra log.
 **cqlsh 5.0.1**
 ```
 $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) 
 Using CQL driver: module 'cassandra' from 
 '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'
 ```
 It then also hangs in this state indefinitely, I have no errors from `cqlsh` 
 and no errors in the Cassandra log.
 What's interesting, and quite confusing is that:
 * I can telnet within the container as follows `telnet $(hostname) 9042` and 
 I get a socket.  When trying to issue some commands, I see Protocol errors in 
 the Cassandra log thus verifying that the port is indeed open on the host 
 that resolves from $(hostname)
 * If I `cqlsh` from another container or another host to the Cassandra 
 container it works just fine.
 * I have tried disabling authentication altogether and using the 
 AllowAllAuthenticator, and I experience the same problem.
 * `nodetool` works fine
 In the mean time, I am forced to `cqlsh` from another container as a 
 workaround.  Happy to try and do anything require to diagnose the cause of 
 this problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6246) EPaxos

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-6246:


bq. Inconsistencies can be introduced by machines being down or network 
partitioned for longer than we replay missed updates to it. Currently for 
normal writes, hint is for 1 hour. If you bring in a machine after 1 hour, you 
run a repair. But repair won't help here since it takes time to run the repair 
and new LWTs will come and will see a different view of the data and won't 
apply.

For serialized queries, new instances sent to a machine that's recovering from 
a failure will be learn of missed instances during the preaccept phase, and 
will have to catch up before they can execute the instance and respond to client

{quote}
Assuming each instance is an average of ~170 bytes (uncompressed), sustained 
1000 instances per second for 3 hours would keep ~1.8GB of data around.
Here instance includes the condition and update. Update could be quite big and 
keeping it around could be problematic.
{quote}

Yeah... agree 100%. Keeping an extensive history of instances for failure 
recovery is not a good idea. Anyway, it doesn't even solve the problem of 
recovery since you'll start to get dangling pointers.

So let's forget about keeping a lot of history around.

For recovering from longer outages, here's my thinking:

To accurately determine dependencies for the preaccept phase, we'll need to 
keep references to active instances around. Otherwise we can get dependency 
graphs that are split, or have gaps. Active instances would be instances that 
both been executed, and that either a quorum of instances have accepted as a 
dependency for another instance, or that was a dependency of a committed 
instance.

This should be all the historical info we need to keep around. We might want to 
keep a little more so we can just use the prepare phase to recover from shorter 
outages.

In cases where a node is joining, or has been down for a while, it seems that 
if we immediately start including them in paxos messages (for record only, not 
to act on), then send them the current dependency data described above for a 
row/cell from a quorum of nodes and the current value for that row/cell, that 
should be enough for the node to start participating in instances. This way we 
can avoid a prepare phase that depends on persisting and transmitting a ton of 
data.

wdyt? I haven't spent a lot of time thinking through all the edge cases, but I 
think it has potential for making recovery practical.


 EPaxos
 --

 Key: CASSANDRA-6246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Blake Eggleston
Priority: Minor

 One reason we haven't optimized our Paxos implementation with Multi-paxos is 
 that Multi-paxos requires leader election and hence, a period of 
 unavailability when the leader dies.
 EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
 (2) is particularly useful across multiple datacenters, and (3) allows any 
 node to act as coordinator: 
 http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
 However, there is substantial additional complexity involved if we choose to 
 implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-6904) commitlog segments may not be archived after restart

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-6904:
--
Reviewer: Jonathan Ellis  (was: Benedict)

 commitlog segments may not be archived after restart
 

 Key: CASSANDRA-6904
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6904
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jonathan Ellis
Assignee: Sam Tunnicliffe
 Fix For: 2.0.11, 2.1.1

 Attachments: 2.0-6904.txt, 2.1-6904-v2.txt, 2.1-6904.txt


 commitlog segments are archived when they are full, so the current active 
 segment will not be archived on restart (and its contents will not be 
 available for pitr).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8011) Fail on large batch sizes

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-8011:
--

You are assigning the variable in DatabaseDescriptor. Why not do as it is done 
for similar stuff like tombstone_failure_threshold. 
In Config, you can make public volatile int batch_size_fail_threshold_in_kb = 
50 like it is done for tombstone_failure_threshold. 

 Fail on large batch sizes 
 --

 Key: CASSANDRA-8011
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
 Project: Cassandra
  Issue Type: Improvement
Reporter: Patrick McFadin
Assignee: Carl Yeksigian
Priority: Minor
 Fix For: 3.0

 Attachments: 8011-trunk-v2.txt, 8011-trunk.txt


 Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
 Just education alone is not going to stop some of the largest batch sizes 
 from being used. Just like we have a tombstone fail threshold, I propose that 
 we have a batch size fail threshold.
 Maybe 10x warn?
 {{batch_fail_threshold: 50k}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8023) DESCRIBE KEYSPACES / KEYSPACE no longer works with Cassandra 2.1 and cqlsh

[Matthew O'Riordan (JIRA)]

Matthew O'Riordan created CASSANDRA-8023:


 Summary: DESCRIBE KEYSPACES / KEYSPACE no longer works with 
Cassandra 2.1 and cqlsh
 Key: CASSANDRA-8023
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8023
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: Ubuntu 14.04, running in a Docker container with Ubuntu 
14.04
Reporter: Matthew O'Riordan
 Fix For: 2.1.0


Connecting to my Cassandra 2.1 cluster with the new 5.0.1 version of cqlsh, 
when I run DESCRIBE KEYSPACES I am told there are no keyspaces.  

```
cqlsh describe keyspaces
describe keyspaces
empty
```

Yet if I connect to that same cluster with version 4 of cqlsh it works fine, I 
can query the keyspaces, and if I run the query manually `select * from 
system.schema_keyspaces` I am given a list of keyspaces.

`DESCRIBE KEYSPACE` also fails with the new cqlsh tool, yet works with version 
4.

```
cqlshuse mykeyspace;
cqlsh:mykeyspace describe keyspace;
describe keyspace;
Keyspace 'ably_sandbox_0' not found.
```



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6246) EPaxos

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-6246:
--

Yes make sense. 

 EPaxos
 --

 Key: CASSANDRA-6246
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Ellis
Assignee: Blake Eggleston
Priority: Minor

 One reason we haven't optimized our Paxos implementation with Multi-paxos is 
 that Multi-paxos requires leader election and hence, a period of 
 unavailability when the leader dies.
 EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, 
 (2) is particularly useful across multiple datacenters, and (3) allows any 
 node to act as coordinator: 
 http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
 However, there is substantial additional complexity involved if we choose to 
 implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)