[jira] [Commented] (CASSANDRA-9433) TraceCompleteTest.testTraceComplete is failing infrequently

2015-05-20 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-9433:
-

For the record, I've also seen that test fail somewhat frequently on my box 
(which for some reason seems to be slower than anyone else box as far as 
running unit test is concerned) and bumping the timeout of the test pretty 
clearly fixes it.

 TraceCompleteTest.testTraceComplete is failing infrequently
 ---

 Key: CASSANDRA-9433
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9433
 Project: Cassandra
  Issue Type: Test
Reporter: Ariel Weisberg

 I have only seen this fail once, but haven't been looking hard.
 http://cassci.datastax.com/view/trunk/job/trunk_testall/98/testReport/junit/org.apache.cassandra.tracing/TraceCompleteTest/testTraceComplete/
 This is a weird one. It looks straightforward because the test is waiting for 
 an event, but for only 250 milliseconds which is within the amount of time a 
 node can just up and pause because life is hard.
 However if you look at the test run it failed twice! Once in test and again 
 in test-compression. Those odds aren't great.
 I am tempted to increase the timeout and keep an eye open. It returns as soon 
 as the event is available so it shouldn't have an impact on how long the test 
 runs on average.



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


[jira] [Updated] (CASSANDRA-9393) Cassandra 2.1.5 fails to build with IBM Java 7

2015-05-20 Thread Benjamin Lerer (JIRA)

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

Benjamin Lerer updated CASSANDRA-9393:
--
Assignee: Carl Yeksigian

 Cassandra 2.1.5 fails to build with IBM Java 7
 --

 Key: CASSANDRA-9393
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9393
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 7, 
 java version 1.7.0
 Java(TM) SE Runtime Environment
 IBM J9 VM (build 2.7, JRE 1.7.0 Linux s390x-64 Compressed References)
Reporter: Karan Dhiman
Assignee: Carl Yeksigian
Priority: Minor
 Attachments: build-project.log


 com.sun.* packages are not available in the IBM JDK.
 The error that is generated claims that 
 com.sun.management.GarbageCollectionNotificationInfo is not available.
 The build log is attached.



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


[jira] [Commented] (CASSANDRA-9396) Canonical view of compacting SSTables not working as expected

2015-05-20 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-9396:
-

bq. Obviously, we need to be stringent about going through the new commit 
process (with cassci vetting) even for relatively innocuous changes.

My view is it did not, although I'm not sure we still have a clearly defined 
document outlining our definition of done. It would be nice to get that on the 
Wiki to point people to.

To dissect what happened here, we did not go through the normal commit process 
due to timezone issues and it being a pressing issue, so Yuki committed in my 
stead. Since I had uploaded only a one-line fix and both of us had run the unit 
test, I assume Yuki considered it safe to commit without running through 
cassci. In fact, from a product perspective it was; the issue was with the 
tests. However he should have run it through cassci, and I should perhaps have 
not submitted a patch for review until it had run in cassci, or at least until 
it was _setup_ in cassci. This latter is up for debate, as it may be a bit 
onerous to always wait for cassci to begin review, and this was a fairly 
uncommon occurrence with extraordinarily low impact while everyone is still 
acclimatizing to the new process. 

We could perhaps require that a link to passing cassci results be posted prior 
to Patch Available? Or we could introduce a new workflow step for Passing 
CI which is required before starting review? This is probably not the best 
place to discuss this, but we should formalize clearly what our process is to 
be, and try to introduce steps to aid adherence.

 Canonical view of compacting SSTables not working as expected
 -

 Key: CASSANDRA-9396
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9396
 Project: Cassandra
  Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Benedict
 Fix For: 2.2.0 beta 1, 2.1.6

 Attachments: 0001-canonical-view-test-while-compacting.patch, 9396.txt


 ColumnFamilyStore.CANONICAL_VIEW filter does not seem to filter out early 
 opened SSTable as expected.
 Attached test shows that canonical view contains both compacting SSTable and 
 early opened SSTable.



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


[jira] [Updated] (CASSANDRA-9436) Expose private rpc_address of each Cassandra node

2015-05-20 Thread JIRA

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

Piotr Kołaczkowski updated CASSANDRA-9436:
--
Description: 
When running Cassandra nodes with collocated Spark nodes and accessing such 
cluster from remote, to get data-locality right, we need to tell Spark the 
locations of the Cassandra nodes and they should match the addresses that Spark 
nodes bind to. Therefore in cloud environments we need to use private IPs for 
that. Unfortunately, the client which connects from remote would know only the 
broadcast rpc_addresses which are different.

Can we have the IP/hostname that every C* node binds to exposed in a system 
table? 
I believe system.peers table contains that information (I need to check , but 
it is missing for the system.local table.

  was:
When running Cassandra nodes with collocated Spark nodes and accessing such 
cluster from remote, to get data-locality right, we need to tell Spark the 
locations of the Cassandra nodes and they should match the addresses that Spark 
nodes bind to. Therefore in cloud environments we need to use private IPs for 
that. Unfortunately, the client which connects from remote would know only the 
broadcast rpc_addresses which are different.

Can we have the IP/hostname that every C* node binds to exposed in a system 
table? 


 Expose private rpc_address of each Cassandra node
 -

 Key: CASSANDRA-9436
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9436
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Piotr Kołaczkowski

 When running Cassandra nodes with collocated Spark nodes and accessing such 
 cluster from remote, to get data-locality right, we need to tell Spark the 
 locations of the Cassandra nodes and they should match the addresses that 
 Spark nodes bind to. Therefore in cloud environments we need to use private 
 IPs for that. Unfortunately, the client which connects from remote would know 
 only the broadcast rpc_addresses which are different.
 Can we have the IP/hostname that every C* node binds to exposed in a system 
 table? 
 I believe system.peers table contains that information (I need to check , but 
 it is missing for the system.local table.



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


[jira] [Commented] (CASSANDRA-8492) Support IF NOT EXISTS for ALTER TABLE ADD COLUMN

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-8492:
--

I'm a bit wary of adding this. It's not crucial, it's not present in Postgres 
or MySQL, and it's not mirrored by a matching {{ALTER TABLE DROP COLUMN IF 
EXISTS}}.

 Support IF NOT EXISTS for ALTER TABLE ADD COLUMN
 

 Key: CASSANDRA-8492
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8492
 Project: Cassandra
  Issue Type: Improvement
Reporter: Peter Mädel
Priority: Minor
 Attachments: 8492.patch


 would enable creation of schema update scripts that can be repeatable 
 executed without having to worry about invalid query exceptions



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


[jira] [Resolved] (CASSANDRA-9393) Cassandra 2.1.5 fails to build with IBM Java 7

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko resolved CASSANDRA-9393.
--
Resolution: Later

Supporting IMB Java is not an official priority to us, but we will accept a 
patch in case you provide one.

Feel free to reopen then.

 Cassandra 2.1.5 fails to build with IBM Java 7
 --

 Key: CASSANDRA-9393
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9393
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 7, 
 java version 1.7.0
 Java(TM) SE Runtime Environment
 IBM J9 VM (build 2.7, JRE 1.7.0 Linux s390x-64 Compressed References)
Reporter: Karan Dhiman
Priority: Minor
 Attachments: build-project.log


 com.sun.* packages are not available in the IBM JDK.
 The error that is generated claims that 
 com.sun.management.GarbageCollectionNotificationInfo is not available.
 The build log is attached.



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


[jira] [Commented] (CASSANDRA-9393) Cassandra 2.1.5 fails to build with IBM Java 7

2015-05-20 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-9393:
-

bq. but we will accept a patch in case you provide one.

Assuming it introduces no performance regressions.

 Cassandra 2.1.5 fails to build with IBM Java 7
 --

 Key: CASSANDRA-9393
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9393
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 7, 
 java version 1.7.0
 Java(TM) SE Runtime Environment
 IBM J9 VM (build 2.7, JRE 1.7.0 Linux s390x-64 Compressed References)
Reporter: Karan Dhiman
Priority: Minor
 Attachments: build-project.log


 com.sun.* packages are not available in the IBM JDK.
 The error that is generated claims that 
 com.sun.management.GarbageCollectionNotificationInfo is not available.
 The build log is attached.



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


[jira] [Updated] (CASSANDRA-9422) SystemKeyspaceTest fails with non-release version string

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-9422:
-
Reviewer: Aleksey Yeschenko

 SystemKeyspaceTest fails with non-release version string
 

 Key: CASSANDRA-9422
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9422
 Project: Cassandra
  Issue Type: Bug
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
 Fix For: 2.2.0 rc1


 {{SystemKeyspaceTest#snapshotSystemKeyspaceIfUpgrading}} is currently failing 
 on the 2.2 branch because the build version {{2.2.0-beta1-SNAPSHOT}} cannot 
 be parsed as a {{SemanticVersion}}. This is only a problem with the test, as 
 the code under test doesn't actually use {{SemanticVersion}}, it just checks 
 whether the old  new version strings are different.



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


[jira] [Commented] (CASSANDRA-9420) Table option for promising that you will never touch a column twice

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-9420:
--

bq. If gcGrace == 0, which you seem fine with, then we'll get rid of expired 
column on the spot. 

Can we really? Even if gc gs is 0, we must ensure that there is no intersection 
with other sstables, before purging it.

This option would allow us to skip that check and indeed be able to drop it on 
the spot.


 Table option for promising that you will never touch a column twice
 ---

 Key: CASSANDRA-9420
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9420
 Project: Cassandra
  Issue Type: New Feature
Reporter: Björn Hegerfors

 There are time series use cases where you write all values with various TTLs, 
 have GC grace = 0 and never ever update or delete a column after insertion. 
 In the case where all TTLs are the same, DTCS with recent patches works 
 great. But when there is lots of variations in TTLs, you are forced to choose 
 between splitting your table into multiple TTL tiers or having your SSTables 
 filled to the majority with tombstones. Or running frequent major compactions.
 The problem stems from the fact that Cassandra plays safe when a TTL has 
 expired, and turns it into a tombstone, rather than getting rid of it on the 
 spot. The reason is that this TTL _may_ have been in a column which has had 
 an earlier write without (or with a higher) TTL. And then that one should now 
 be deleted too.
 I propose that there should be table level setting to say I guarantee that 
 there will never be any updates to any columns. The effect of enabling that 
 option is that all tombstones and expired TTLs should always be immediately 
 removed during compaction. And the check for dropping entirely expired 
 SSTables can be very loosened for these tables.
 This option should probably require gc_grace_seconds to be set to zero. It's 
 also questionable if writes without TTL should be allowed to such a table, 
 since those would become constants.



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


[jira] [Created] (CASSANDRA-9436) Expose private rpc_address of each Cassandra node

2015-05-20 Thread JIRA
Piotr Kołaczkowski created CASSANDRA-9436:
-

 Summary: Expose private rpc_address of each Cassandra node
 Key: CASSANDRA-9436
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9436
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Piotr Kołaczkowski


When running Cassandra nodes with collocated Spark nodes and accessing such 
cluster from remote, to get data-locality right, we need to tell Spark the 
locations of the Cassandra nodes and they should match the addresses that Spark 
nodes bind to. Therefore in cloud environments we need to use private IPs for 
that. Unfortunately, the client which connects from remote would know only the 
broadcast rpc_addresses which are different.

Can we have the IP/hostname that every C* node binds to exposed in a system 
table? 



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


[jira] [Commented] (CASSANDRA-8723) Cassandra 2.1.2 Memory issue - java process memory usage continuously increases until process is killed by OOM killer

2015-05-20 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-8723:
-

[~pasthelod]: You may have a lot of large bloom filters and other data 
structures that reside off heap. I would strongly recommend upgrading to the 
latest 2.1 series, though, as there were many significant stability 
improvements introduced since 2.1.2

 Cassandra 2.1.2 Memory issue - java process memory usage continuously 
 increases until process is killed by OOM killer
 -

 Key: CASSANDRA-8723
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8723
 Project: Cassandra
  Issue Type: Bug
Reporter: Jeff Liu
 Fix For: 2.1.x

 Attachments: cassandra.yaml


 Issue:
 We have an on-going issue with cassandra nodes running with continuously 
 increasing memory until killed by OOM.
 {noformat}
 Jan 29 10:15:41 cass-chisel19 kernel: [24533109.783481] Out of memory: Kill 
 process 13919 (java) score 911 or sacrifice child
 Jan 29 10:15:41 cass-chisel19 kernel: [24533109.783557] Killed process 13919 
 (java) total-vm:18366340kB, anon-rss:6461472kB, file-rss:6684kB
 {noformat}
 System Profile:
 cassandra version 2.1.2
 system: aws c1.xlarge instance with 8 cores, 7.1G memory.
 cassandra jvm:
 -Xms1792M -Xmx1792M -Xmn400M -Xss256k
 {noformat}
 java -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.8.jar 
 -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1792M -Xmx1792M 
 -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss256k -XX:StringTableSize=103 
 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled 
 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 
 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly 
 -XX:+UseTLAB -XX:+CMSClassUnloadingEnabled -XX:+UseCondCardMark 
 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC 
 -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime 
 -XX:+PrintPromotionFailure -Xloggc:/var/log/cassandra/gc-1421511249.log 
 -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=48M 
 -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=7199 
 -Dcom.sun.management.jmxremote.ssl=false 
 -Dcom.sun.management.jmxremote.authenticate=false 
 -javaagent:/usr/share/java/graphite-reporter-agent-1.0-SNAPSHOT.jar=graphiteServer=metrics-a.hq.nest.com;graphitePort=2003;graphitePollInt=60
  -Dlogback.configurationFile=logback.xml 
 -Dcassandra.logdir=/var/log/cassandra -Dcassandra.storagedir= 
 -Dcassandra-pidfile=/var/run/cassandra/cassandra.pid -cp 
 /etc/cassandra:/usr/share/cassandra/lib/airline-0.6.jar:/usr/share/cassandra/lib/antlr-runtime-3.5.2.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang3-3.1.jar:/usr/share/cassandra/lib/commons-math3-3.2.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.4.jar:/usr/share/cassandra/lib/disruptor-3.0.1.jar:/usr/share/cassandra/lib/guava-16.0.jar:/usr/share/cassandra/lib/high-scale-lib-1.0.6.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.8.jar:/usr/share/cassandra/lib/javax.inject.jar:/usr/share/cassandra/lib/jbcrypt-0.3m.jar:/usr/share/cassandra/lib/jline-1.0.jar:/usr/share/cassandra/lib/jna-4.0.0.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.9.1.jar:/usr/share/cassandra/lib/logback-classic-1.1.2.jar:/usr/share/cassandra/lib/logback-core-1.1.2.jar:/usr/share/cassandra/lib/lz4-1.2.0.jar:/usr/share/cassandra/lib/metrics-core-2.2.0.jar:/usr/share/cassandra/lib/metrics-graphite-2.2.0.jar:/usr/share/cassandra/lib/mx4j-tools.jar:/usr/share/cassandra/lib/netty-all-4.0.23.Final.jar:/usr/share/cassandra/lib/reporter-config-2.1.0.jar:/usr/share/cassandra/lib/slf4j-api-1.7.2.jar:/usr/share/cassandra/lib/snakeyaml-1.11.jar:/usr/share/cassandra/lib/snappy-java-1.0.5.2.jar:/usr/share/cassandra/lib/stream-2.5.2.jar:/usr/share/cassandra/lib/stringtemplate-4.0.2.jar:/usr/share/cassandra/lib/super-csv-2.1.0.jar:/usr/share/cassandra/lib/thrift-server-0.3.7.jar:/usr/share/cassandra/apache-cassandra-2.1.2.jar:/usr/share/cassandra/apache-cassandra-thrift-2.1.2.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/cassandra-driver-core-2.0.5.jar:/usr/share/cassandra/netty-3.9.0.Final.jar:/usr/share/cassandra/stress.jar:
  -XX:HeapDumpPath=/var/lib/cassandra/java_1421511248.hprof 
 -XX:ErrorFile=/var/lib/cassandra/hs_err_1421511248.log 
 org.apache.cassandra.service.CassandraDaemon
 {noformat}



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


[2/3] cassandra git commit: Revert CASSANDRA-7807 (tracing completion client notifications) (CASSANDRA-9429)

2015-05-20 Thread snazy
Revert CASSANDRA-7807 (tracing completion client notifications) (CASSANDRA-9429)

patch by Robert Stupp; reviewed by Aleksey Yeschenko for CASSANDRA-9429


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

Branch: refs/heads/trunk
Commit: e4eba2538255fdc23cad59642be69c8b27f04218
Parents: 6eea3ea
Author: Robert Stupp sn...@snazy.de
Authored: Wed May 20 08:48:53 2015 +0200
Committer: Robert Stupp sn...@snazy.de
Committed: Wed May 20 08:48:53 2015 +0200

--
 CHANGES.txt |   1 +
 doc/native_protocol_v4.spec |   6 -
 .../apache/cassandra/service/QueryState.java|  10 +-
 .../apache/cassandra/tracing/TraceState.java|  42 +---
 .../org/apache/cassandra/tracing/Tracing.java   |  24 +--
 .../apache/cassandra/transport/Connection.java  |   9 -
 .../org/apache/cassandra/transport/Event.java   |  54 -
 .../org/apache/cassandra/transport/Server.java  |   5 -
 .../transport/messages/BatchMessage.java|   2 +-
 .../transport/messages/ExecuteMessage.java  |   2 +-
 .../transport/messages/PrepareMessage.java  |   2 +-
 .../transport/messages/QueryMessage.java|   2 +-
 .../cassandra/tracing/TraceCompleteTest.java| 204 ---
 13 files changed, 19 insertions(+), 344 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4eba253/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4e79ea0..a227f5e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 2.2
  * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
+ * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
 Merged from 2.1:
  * Use configured gcgs in anticompaction (CASSANDRA-9397)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4eba253/doc/native_protocol_v4.spec
--
diff --git a/doc/native_protocol_v4.spec b/doc/native_protocol_v4.spec
index ba3d3b3..f040323 100644
--- a/doc/native_protocol_v4.spec
+++ b/doc/native_protocol_v4.spec
@@ -130,8 +130,6 @@ Table of Contents
   ignored by the default QueryHandler implementation.
   Currently, only QUERY, PREPARE, EXECUTE and BATCH requests support
   payload.
-  If both trace-flag and payload-flag are set, the generic key-value
-  payload appears after trace's data.
   Type of custom payload is [bytes map] (see below).
 0x08: Warning flag. The response contains warnings from the server which
   were generated by the server to go along with this response.
@@ -755,9 +753,6 @@ Table of Contents
 - [string] keyspace containing the user defined function / 
aggregate
 - [string] the function/aggregate name
 - [string list] one string for each argument type (as CQL type)
-- TRACE_COMPLETE: notification that a trace session has completed at 
least
-  on the coordinator. After the event type, the rest of the message will
-  contain the trace session-ID [uuid] as the only argument.
 
   All EVENT messages have a streamId of -1 (Section 2.3).
 
@@ -1162,7 +1157,6 @@ Table of Contents
   * Read_failure error code was added.
   * Function_failure error code was added.
   * Add custom payload to frames for custom QueryHandler implementations 
(ignored by Cassandra's standard QueryHandler)
-  * Add TRACE_COMPLETE event (section 4.2.6).
   * Add warnings to frames for responses for which the server generated a 
warning during processing, which the client needs to address.
   * Add the date and time data types
   * Add the tinyint and smallint data types

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4eba253/src/java/org/apache/cassandra/service/QueryState.java
--
diff --git a/src/java/org/apache/cassandra/service/QueryState.java 
b/src/java/org/apache/cassandra/service/QueryState.java
index 5e89ac8..ddbc959 100644
--- a/src/java/org/apache/cassandra/service/QueryState.java
+++ b/src/java/org/apache/cassandra/service/QueryState.java
@@ -22,7 +22,6 @@ import java.util.UUID;
 import java.util.concurrent.ThreadLocalRandom;
 
 import org.apache.cassandra.tracing.Tracing;
-import org.apache.cassandra.transport.Connection;
 
 /**
  * Represents the state related to a given query.
@@ -77,19 +76,14 @@ public class QueryState
 
 public void createTracingSession()
 {
-createTracingSession(null);
-}
-
-public void createTracingSession(Connection connection)
-{
   

[1/3] cassandra git commit: Revert CASSANDRA-7807 (tracing completion client notifications) (CASSANDRA-9429)

2015-05-20 Thread snazy
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 6eea3ea39 - e4eba2538
  refs/heads/trunk 6ed3c1958 - eaf7d81e7


Revert CASSANDRA-7807 (tracing completion client notifications) (CASSANDRA-9429)

patch by Robert Stupp; reviewed by Aleksey Yeschenko for CASSANDRA-9429


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

Branch: refs/heads/cassandra-2.2
Commit: e4eba2538255fdc23cad59642be69c8b27f04218
Parents: 6eea3ea
Author: Robert Stupp sn...@snazy.de
Authored: Wed May 20 08:48:53 2015 +0200
Committer: Robert Stupp sn...@snazy.de
Committed: Wed May 20 08:48:53 2015 +0200

--
 CHANGES.txt |   1 +
 doc/native_protocol_v4.spec |   6 -
 .../apache/cassandra/service/QueryState.java|  10 +-
 .../apache/cassandra/tracing/TraceState.java|  42 +---
 .../org/apache/cassandra/tracing/Tracing.java   |  24 +--
 .../apache/cassandra/transport/Connection.java  |   9 -
 .../org/apache/cassandra/transport/Event.java   |  54 -
 .../org/apache/cassandra/transport/Server.java  |   5 -
 .../transport/messages/BatchMessage.java|   2 +-
 .../transport/messages/ExecuteMessage.java  |   2 +-
 .../transport/messages/PrepareMessage.java  |   2 +-
 .../transport/messages/QueryMessage.java|   2 +-
 .../cassandra/tracing/TraceCompleteTest.java| 204 ---
 13 files changed, 19 insertions(+), 344 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4eba253/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4e79ea0..a227f5e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
 2.2
  * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
+ * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
 Merged from 2.1:
  * Use configured gcgs in anticompaction (CASSANDRA-9397)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4eba253/doc/native_protocol_v4.spec
--
diff --git a/doc/native_protocol_v4.spec b/doc/native_protocol_v4.spec
index ba3d3b3..f040323 100644
--- a/doc/native_protocol_v4.spec
+++ b/doc/native_protocol_v4.spec
@@ -130,8 +130,6 @@ Table of Contents
   ignored by the default QueryHandler implementation.
   Currently, only QUERY, PREPARE, EXECUTE and BATCH requests support
   payload.
-  If both trace-flag and payload-flag are set, the generic key-value
-  payload appears after trace's data.
   Type of custom payload is [bytes map] (see below).
 0x08: Warning flag. The response contains warnings from the server which
   were generated by the server to go along with this response.
@@ -755,9 +753,6 @@ Table of Contents
 - [string] keyspace containing the user defined function / 
aggregate
 - [string] the function/aggregate name
 - [string list] one string for each argument type (as CQL type)
-- TRACE_COMPLETE: notification that a trace session has completed at 
least
-  on the coordinator. After the event type, the rest of the message will
-  contain the trace session-ID [uuid] as the only argument.
 
   All EVENT messages have a streamId of -1 (Section 2.3).
 
@@ -1162,7 +1157,6 @@ Table of Contents
   * Read_failure error code was added.
   * Function_failure error code was added.
   * Add custom payload to frames for custom QueryHandler implementations 
(ignored by Cassandra's standard QueryHandler)
-  * Add TRACE_COMPLETE event (section 4.2.6).
   * Add warnings to frames for responses for which the server generated a 
warning during processing, which the client needs to address.
   * Add the date and time data types
   * Add the tinyint and smallint data types

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4eba253/src/java/org/apache/cassandra/service/QueryState.java
--
diff --git a/src/java/org/apache/cassandra/service/QueryState.java 
b/src/java/org/apache/cassandra/service/QueryState.java
index 5e89ac8..ddbc959 100644
--- a/src/java/org/apache/cassandra/service/QueryState.java
+++ b/src/java/org/apache/cassandra/service/QueryState.java
@@ -22,7 +22,6 @@ import java.util.UUID;
 import java.util.concurrent.ThreadLocalRandom;
 
 import org.apache.cassandra.tracing.Tracing;
-import org.apache.cassandra.transport.Connection;
 
 /**
  * Represents the state related to a given query.
@@ -77,19 +76,14 @@ public class QueryState
 
 public void 

[3/3] cassandra git commit: Merge branch 'cassandra-2.2' into trunk

2015-05-20 Thread snazy
Merge branch 'cassandra-2.2' into trunk


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

Branch: refs/heads/trunk
Commit: eaf7d81e7af89033ca8dcd3605b12076c3ec1757
Parents: 6ed3c19 e4eba25
Author: Robert Stupp sn...@snazy.de
Authored: Wed May 20 08:49:25 2015 +0200
Committer: Robert Stupp sn...@snazy.de
Committed: Wed May 20 08:49:25 2015 +0200

--
 CHANGES.txt |   1 +
 doc/native_protocol_v4.spec |   6 -
 .../apache/cassandra/service/QueryState.java|  10 +-
 .../apache/cassandra/tracing/TraceState.java|  42 +---
 .../org/apache/cassandra/tracing/Tracing.java   |  24 +--
 .../apache/cassandra/transport/Connection.java  |   9 -
 .../org/apache/cassandra/transport/Event.java   |  54 -
 .../org/apache/cassandra/transport/Server.java  |   5 -
 .../transport/messages/BatchMessage.java|   2 +-
 .../transport/messages/ExecuteMessage.java  |   2 +-
 .../transport/messages/PrepareMessage.java  |   2 +-
 .../transport/messages/QueryMessage.java|   2 +-
 .../cassandra/tracing/TraceCompleteTest.java| 204 ---
 13 files changed, 19 insertions(+), 344 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaf7d81e/CHANGES.txt
--
diff --cc CHANGES.txt
index 9954948,a227f5e..5642cd4
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,6 +1,10 @@@
 +3.0:
 + * Decommissioned nodes will not rejoin the cluster (CASSANDRA-8801)
 + * Change gossip stabilization to use endpoit size (CASSANDRA-9401)
 +
  2.2
   * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
+  * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
  Merged from 2.1:
   * Use configured gcgs in anticompaction (CASSANDRA-9397)
  



[jira] [Commented] (CASSANDRA-9422) SystemKeyspaceTest fails with non-release version string

2015-05-20 Thread Sam Tunnicliffe (JIRA)

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

Sam Tunnicliffe commented on CASSANDRA-9422:


The only place we do that is in {{AntiCompactionTask}} where we have an 
appropriate null check to handle an unparseable string. The code being tested 
here needs to do a simple string comparison so we make sure we snapshot even 
when there's garbage/nothing in {{system.local}} at startup. The test only uses 
{{SemanticVersion}} as a convenience so I prefer fixing the test to match the 
actual implementation.

FTR, it's only the 'double barrelled' postfix that the issue here. i.e. 
{{-SNAPSHOT}}, {{-beta1}}, {{-RC1}} are all fine, but {{-beta1-SNAPSHOT}} isn't 
a valid semver. 


 SystemKeyspaceTest fails with non-release version string
 

 Key: CASSANDRA-9422
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9422
 Project: Cassandra
  Issue Type: Bug
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
 Fix For: 2.2.0 rc1


 {{SystemKeyspaceTest#snapshotSystemKeyspaceIfUpgrading}} is currently failing 
 on the 2.2 branch because the build version {{2.2.0-beta1-SNAPSHOT}} cannot 
 be parsed as a {{SemanticVersion}}. This is only a problem with the test, as 
 the code under test doesn't actually use {{SemanticVersion}}, it just checks 
 whether the old  new version strings are different.



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


[1/3] cassandra git commit: Check connection errors more reliably in CqlRecordWriter

2015-05-20 Thread samt
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 e4eba2538 - f970de557
  refs/heads/trunk eaf7d81e7 - 16736314b


Check connection errors more reliably in CqlRecordWriter

Patch by Philip Thompson; reviewed by Sam Tunnicliffe for CASSANDRA-9419


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

Branch: refs/heads/cassandra-2.2
Commit: f970de55746dd074843d8cfd5385b12acda56ee9
Parents: e4eba25
Author: Philip Thompson ptnapol...@gmail.com
Authored: Wed May 20 10:49:02 2015 +0100
Committer: Sam Tunnicliffe s...@beobal.com
Committed: Wed May 20 10:51:45 2015 +0100

--
 .../org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f970de55/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java 
b/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java
index 132273c..c507197 100644
--- a/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java
+++ b/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java
@@ -28,6 +28,7 @@ import org.slf4j.LoggerFactory;
 
 
 import com.datastax.driver.core.exceptions.AuthenticationException;
+import com.datastax.driver.core.exceptions.DriverException;
 import com.datastax.driver.core.exceptions.InvalidQueryException;
 import com.datastax.driver.core.exceptions.NoHostAvailableException;
 import com.datastax.driver.core.BoundStatement;
@@ -321,7 +322,10 @@ class CqlRecordWriter extends RecordWriterMapString, 
ByteBuffer, ListByteBuf
 catch (Exception e)
 {
 //If connection died due to Interrupt, just try 
connecting to the endpoint again.
-if (Thread.interrupted()) {
+//There are too many ways for the Thread.interrupted() 
state to be cleared, so
+//we can't rely on that here. Until the java driver 
gives us a better way of knowing
+//that this exception came from an 
InterruptedException, this is the best solution.
+if (e instanceof DriverException  
e.getMessage().contains(Connection thread interrupted)) {
 lastException = new IOException(e);
 iter.previous();
 }
@@ -334,6 +338,7 @@ class CqlRecordWriter extends RecordWriterMapString, 
ByteBuffer, ListByteBuf
 lastException = new IOException(e);
 break outer;
 }
+continue;
 }
 
 try



[3/3] cassandra git commit: Merge branch 'cassandra-2.2' into trunk

2015-05-20 Thread samt
Merge branch 'cassandra-2.2' into trunk


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

Branch: refs/heads/trunk
Commit: 16736314b7a40de4c35eeccb8c88dfea03fb20e0
Parents: eaf7d81 f970de5
Author: Sam Tunnicliffe s...@beobal.com
Authored: Wed May 20 10:58:53 2015 +0100
Committer: Sam Tunnicliffe s...@beobal.com
Committed: Wed May 20 10:58:53 2015 +0100

--
 .../org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)
--




[jira] [Updated] (CASSANDRA-9188) cqlsh does not display properly the modified UDTs

2015-05-20 Thread Benjamin Lerer (JIRA)

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

Benjamin Lerer updated CASSANDRA-9188:
--
Assignee: Carl Yeksigian  (was: Benjamin Lerer)

 cqlsh does not display properly the modified UDTs
 -

 Key: CASSANDRA-9188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9188
 Project: Cassandra
  Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Carl Yeksigian
Priority: Minor
  Labels: cqlsh
 Fix For: 2.1.x


 The problem can be reproduced as follow:
 {code}
 cqlsh:test2 create type myType (a int);
 cqlsh:test2 create table myTable (a int primary key, b frozenmyType);
 cqlsh:test2 insert into myTable (a, b) values (1, {a: 1});
 cqlsh:test2 select * from myTable;
  a | b
 ---+
  1 | {a: 1}
 (1 rows)
 cqlsh:test2 alter type myType add b int;
 cqlsh:test2 insert into myTable (a, b) values (2, {a: 2, b :2});
 cqlsh:test2 select * from myTable;
  a | b
 ---+
  1 | {a: 1}
  2 | {a: 2}
 (2 rows)
 {code}
 If {{cqlsh}} is then restarted it will display the data properly.
 {code}
 cqlsh:test2 select * from mytable;
  a | b
 ---+-
  1 | {a: 1, b: null}
  2 |{a: 2, b: 2}
 (2 rows)
 {code} 



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


[jira] [Updated] (CASSANDRA-9247) DROP INDEX ks.index_name is a syntax error in 2.0

2015-05-20 Thread Benjamin Lerer (JIRA)

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

Benjamin Lerer updated CASSANDRA-9247:
--
Assignee: Carl Yeksigian  (was: Benjamin Lerer)

 DROP INDEX ks.index_name is a syntax error in 2.0
 -

 Key: CASSANDRA-9247
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9247
 Project: Cassandra
  Issue Type: Bug
Reporter: Jim Witschey
Assignee: Carl Yeksigian
 Fix For: 2.0.x


 In all versions of 2.0, statements like
 {{DROP INDEX ks.index_to_drop;}}
 fail with the error
 {{ErrorMessage code=2000 [Syntax error in CQL query] message=line 1:13 
 missing EOF at '.'}}
 The error doesn't happen in any 2.1 versions or trunk. [The 
 docs|http://docs.datastax.com/en/cql/3.1/cql/cql_reference/drop_index_r.html] 
 don't indicate that the {{DROP INDEX}} statement should work any differently 
 on 2.0.
 [Here|https://github.com/mambocab/cassandra-dtest/blob/drop_index_keyspace_bug/index_keyspace_bug.py]
  is a dtest that produces the error, but I think a patch should include a 
 more isolated test for the component that's failing here.



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


[jira] [Created] (CASSANDRA-9435) Documetation bug

2015-05-20 Thread jincer (JIRA)
jincer created CASSANDRA-9435:
-

 Summary: Documetation bug
 Key: CASSANDRA-9435
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9435
 Project: Cassandra
  Issue Type: Bug
  Components: Documentation  website
 Environment: Debian 7
Reporter: jincer
Priority: Minor
 Fix For: 2.1.5


Hello, you have some inaccuracy at docs on your website. 
When i try to change snitch from default to EC2Snitch (endpoint_snitch: 
EC2Snitch) i have message, that  Unable to find snitch class 
'org.apache.cassandra.locator.EC2Snitch'  .
Only when i change endpoint_snitch: EC2Snitch to endpoint_snitch: Ec2Snitch 
it has been started. 

Thank you.



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


[jira] [Commented] (CASSANDRA-9393) Cassandra 2.1.5 fails to build with IBM Java 7

2015-05-20 Thread Benedict (JIRA)

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

Benedict commented on CASSANDRA-9393:
-

It really isn't recommended to use a non-Oracle JDK, due to strong dependency 
on sun.misc.Unsafe. According to [this 
discussion|http://osdir.com/ml/akka/2013-09/msg00104.html] this will cause an 
UnsatisfiedLinkError on J9. It may be possible to include the JDK and get it to 
work via regular JNI, I'm not sure, but this would be tricky, unsupported, and 
if it worked probably have serious performance implications.

We also have a dependency on sun.nio.ch.DirectBuffer and com.sun.jna.Native, 
and these are unlikely to be removed anytime soon.

Introducing support for arbitrary JVMs would be quite onerous. Is it something 
we want to pursure?

 Cassandra 2.1.5 fails to build with IBM Java 7
 --

 Key: CASSANDRA-9393
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9393
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 7, 
 java version 1.7.0
 Java(TM) SE Runtime Environment
 IBM J9 VM (build 2.7, JRE 1.7.0 Linux s390x-64 Compressed References)
Reporter: Karan Dhiman
Assignee: Carl Yeksigian
Priority: Minor
 Attachments: build-project.log


 com.sun.* packages are not available in the IBM JDK.
 The error that is generated claims that 
 com.sun.management.GarbageCollectionNotificationInfo is not available.
 The build log is attached.



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


[jira] [Updated] (CASSANDRA-9393) Cassandra 2.1.5 fails to build with IBM Java 7

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-9393:
-
Assignee: (was: Carl Yeksigian)

 Cassandra 2.1.5 fails to build with IBM Java 7
 --

 Key: CASSANDRA-9393
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9393
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 7, 
 java version 1.7.0
 Java(TM) SE Runtime Environment
 IBM J9 VM (build 2.7, JRE 1.7.0 Linux s390x-64 Compressed References)
Reporter: Karan Dhiman
Priority: Minor
 Attachments: build-project.log


 com.sun.* packages are not available in the IBM JDK.
 The error that is generated claims that 
 com.sun.management.GarbageCollectionNotificationInfo is not available.
 The build log is attached.



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


[2/3] cassandra git commit: Check connection errors more reliably in CqlRecordWriter

2015-05-20 Thread samt
Check connection errors more reliably in CqlRecordWriter

Patch by Philip Thompson; reviewed by Sam Tunnicliffe for CASSANDRA-9419


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

Branch: refs/heads/trunk
Commit: f970de55746dd074843d8cfd5385b12acda56ee9
Parents: e4eba25
Author: Philip Thompson ptnapol...@gmail.com
Authored: Wed May 20 10:49:02 2015 +0100
Committer: Sam Tunnicliffe s...@beobal.com
Committed: Wed May 20 10:51:45 2015 +0100

--
 .../org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f970de55/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java 
b/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java
index 132273c..c507197 100644
--- a/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java
+++ b/src/java/org/apache/cassandra/hadoop/cql3/CqlRecordWriter.java
@@ -28,6 +28,7 @@ import org.slf4j.LoggerFactory;
 
 
 import com.datastax.driver.core.exceptions.AuthenticationException;
+import com.datastax.driver.core.exceptions.DriverException;
 import com.datastax.driver.core.exceptions.InvalidQueryException;
 import com.datastax.driver.core.exceptions.NoHostAvailableException;
 import com.datastax.driver.core.BoundStatement;
@@ -321,7 +322,10 @@ class CqlRecordWriter extends RecordWriterMapString, 
ByteBuffer, ListByteBuf
 catch (Exception e)
 {
 //If connection died due to Interrupt, just try 
connecting to the endpoint again.
-if (Thread.interrupted()) {
+//There are too many ways for the Thread.interrupted() 
state to be cleared, so
+//we can't rely on that here. Until the java driver 
gives us a better way of knowing
+//that this exception came from an 
InterruptedException, this is the best solution.
+if (e instanceof DriverException  
e.getMessage().contains(Connection thread interrupted)) {
 lastException = new IOException(e);
 iter.previous();
 }
@@ -334,6 +338,7 @@ class CqlRecordWriter extends RecordWriterMapString, 
ByteBuffer, ListByteBuf
 lastException = new IOException(e);
 break outer;
 }
+continue;
 }
 
 try



[jira] [Commented] (CASSANDRA-9419) CqlRecordWriter does not adequately determine if driver failed to connect due to interrupt

2015-05-20 Thread Sam Tunnicliffe (JIRA)

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

Sam Tunnicliffe commented on CASSANDRA-9419:


LGTM, thanks. Committed in {{f970de55746dd074843d8cfd5385b12acda56ee9}}

 CqlRecordWriter does not adequately determine if driver failed to connect due 
 to interrupt
 --

 Key: CASSANDRA-9419
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9419
 Project: Cassandra
  Issue Type: Bug
Reporter: Philip Thompson
Assignee: Philip Thompson
 Fix For: 2.2.0 rc1

 Attachments: 9419.txt


 Until https://datastax-oss.atlassian.net/browse/JAVA-769 is implemented, I 
 have had to implement a workaround.
 Java's thread interrupt status flag can be cleared for any number of reasons. 
 After discussion, I've changed to parsing the driver's DriverException to 
 tell if we are safe to retry the failed connection.



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


[jira] [Commented] (CASSANDRA-6328) Allow deleting records with a secondary index lookup

2015-05-20 Thread Benjamin Lerer (JIRA)

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

Benjamin Lerer commented on CASSANDRA-6328:
---

The problem with the scenario that you describe is that reading the data and 
deleting them are 2 different operations. Between the time where the data was 
retrieved and the time where delete operation is performed somebody might have 
change the user_id. In which case you might end up deleting the wrong data.

Due to this reason, we try to avoid as much as possible to implements read 
before write operations and let's the user choose to do these things manually 
if he is sure that it is really what he want.

 Allow deleting records with a secondary index lookup
 

 Key: CASSANDRA-6328
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6328
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: David Huang
Priority: Minor
 Fix For: 3.x


 Currently, clients must query for row keys from a specific secondary index 
 and delete the results. This incurs network traffic whereas a single server 
 operation would be enough.
  Example 
 In C* we would have to query for all playlist_id for user JohnSmith and 
 issue deletes for each key. Deleting by secondary index would allow the 
 entire operation to occur within C* without the client needing to issue 
 multiple statements.
 Delete By Secondary Index
 CREATE TABLE playlist (
 playlist_id text,
 user_id text,
 song_name settext,
 PRIMARY_KEY (playlist_id)
 );
 CREATE INDEX on playlist (user_id);
 DELETE FROM playlist WHERE user_id = JohnSmith;
 Delete By Client
 // Schema
 CREATE TABLE playlist (
 playlist_id text,
 user_id text,
 song_name settext,
 PRIMARY_KEY (playlist_id)
 );
 CREATE INDEX on playlist (user_id);
 // Client
 ResultSet resultSet = session.execute(select playlist_id from playlist where 
 userid = JohnSmith);
 PreparedStatement delete = session.prepare(DELETE FROM playlist WHERE 
 playlist_id =  ?);
 for(Row row : resultSet){
 session.execute(delete.bind(row.getString(playlist_id)));
 }
   



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


[jira] [Resolved] (CASSANDRA-6328) Allow deleting records with a secondary index lookup

2015-05-20 Thread Benjamin Lerer (JIRA)

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

Benjamin Lerer resolved CASSANDRA-6328.
---
Resolution: Won't Fix

 Allow deleting records with a secondary index lookup
 

 Key: CASSANDRA-6328
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6328
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: David Huang
Priority: Minor
 Fix For: 3.x


 Currently, clients must query for row keys from a specific secondary index 
 and delete the results. This incurs network traffic whereas a single server 
 operation would be enough.
  Example 
 In C* we would have to query for all playlist_id for user JohnSmith and 
 issue deletes for each key. Deleting by secondary index would allow the 
 entire operation to occur within C* without the client needing to issue 
 multiple statements.
 Delete By Secondary Index
 CREATE TABLE playlist (
 playlist_id text,
 user_id text,
 song_name settext,
 PRIMARY_KEY (playlist_id)
 );
 CREATE INDEX on playlist (user_id);
 DELETE FROM playlist WHERE user_id = JohnSmith;
 Delete By Client
 // Schema
 CREATE TABLE playlist (
 playlist_id text,
 user_id text,
 song_name settext,
 PRIMARY_KEY (playlist_id)
 );
 CREATE INDEX on playlist (user_id);
 // Client
 ResultSet resultSet = session.execute(select playlist_id from playlist where 
 userid = JohnSmith);
 PreparedStatement delete = session.prepare(DELETE FROM playlist WHERE 
 playlist_id =  ?);
 for(Row row : resultSet){
 session.execute(delete.bind(row.getString(playlist_id)));
 }
   



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


[jira] [Comment Edited] (CASSANDRA-9431) Static Analysis to warn on unsafe use of Autocloseable instances

2015-05-20 Thread Benedict (JIRA)

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

Benedict edited comment on CASSANDRA-9431 at 5/20/15 8:47 AM:
--

My (out of date) experience with ecj (back in the days of -1.6 and 1.7- 1.5 
(edit: I sometimes forget I'm not so young anymore) language features being 
introduced) was that ecj was actually always much more solid than javac on 
handling edge cases in the language.

However I agree that we should stick to javac for compilation, as I would not 
want to risk weird bytecode production, which is much more important.


was (Author: benedict):
My (out of date) experience with ecj (back in the days of 1.6 and 1.7 language 
features being introduced) was that ecj was actually always much more solid 
than javac on handling edge cases in the language.

However I agree that we should stick to javac for compilation, as I would not 
want to risk weird bytecode production, which is much more important.

 Static Analysis to warn on unsafe use of Autocloseable instances
 

 Key: CASSANDRA-9431
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9431
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: T Jake Luciani
 Fix For: 3.0 beta 1


 The ideal goal would be to fail the build under any unsafe (and not annotated 
 as considered safe independently) uses of Autocloseable. It looks as though 
 eclipse (and hence, hopefully ecj) has support for this feature, so we should 
 investigate if it meets our requirements and we can get it integrated



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


[jira] [Commented] (CASSANDRA-8492) Support IF NOT EXISTS for ALTER TABLE ADD COLUMN

2015-05-20 Thread Oded Peer (JIRA)

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

Oded Peer commented on CASSANDRA-8492:
--

[~Sachin Janani] Can you add a unit test for your change to AlterTableTest?

 Support IF NOT EXISTS for ALTER TABLE ADD COLUMN
 

 Key: CASSANDRA-8492
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8492
 Project: Cassandra
  Issue Type: Improvement
Reporter: Peter Mädel
Priority: Minor
 Attachments: 8492.patch


 would enable creation of schema update scripts that can be repeatable 
 executed without having to worry about invalid query exceptions



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


[jira] [Commented] (CASSANDRA-9422) SystemKeyspaceTest fails with non-release version string

2015-05-20 Thread Sam Tunnicliffe (JIRA)

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

Sam Tunnicliffe commented on CASSANDRA-9422:


thanks, committed in {{f9b6d3dac7d60b4409f05c25e743dfbbf32a50f4}}

 SystemKeyspaceTest fails with non-release version string
 

 Key: CASSANDRA-9422
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9422
 Project: Cassandra
  Issue Type: Bug
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
 Fix For: 2.2.0 rc1


 {{SystemKeyspaceTest#snapshotSystemKeyspaceIfUpgrading}} is currently failing 
 on the 2.2 branch because the build version {{2.2.0-beta1-SNAPSHOT}} cannot 
 be parsed as a {{SemanticVersion}}. This is only a problem with the test, as 
 the code under test doesn't actually use {{SemanticVersion}}, it just checks 
 whether the old  new version strings are different.



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


[jira] [Assigned] (CASSANDRA-8103) Secondary Indices for Static Columns

2015-05-20 Thread Sam Tunnicliffe (JIRA)

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

Sam Tunnicliffe reassigned CASSANDRA-8103:
--

Assignee: Sam Tunnicliffe

 Secondary Indices for Static Columns
 

 Key: CASSANDRA-8103
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8103
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Ron Cohen
Assignee: Sam Tunnicliffe
Priority: Blocker
 Fix For: 3.0 beta 1

 Attachments: in_progress.patch


 We should add secondary index support for static columns.  



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


[2/2] cassandra git commit: Merge branch 'cassandra-2.2' into trunk

2015-05-20 Thread aleksey
Merge branch 'cassandra-2.2' into trunk


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

Branch: refs/heads/trunk
Commit: 684ef27dc8c6469f896491cb56bed28f7fdacd93
Parents: 66772b7 0088e5f
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed May 20 15:33:34 2015 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 15:33:34 2015 +0300

--

--




[1/2] cassandra git commit: Add a more verbose assert to SQFWTT.testBeyondThresholdSelect()

2015-05-20 Thread aleksey
Repository: cassandra
Updated Branches:
  refs/heads/trunk 66772b7ab - 684ef27dc


Add a more verbose assert to SQFWTT.testBeyondThresholdSelect()

patch by Ariel Weisberg; reveiwed by Aleksey Yeschenko for
CASSANDRA-9432


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

Branch: refs/heads/trunk
Commit: 0088e5f1e85bd344cbbc7f7ab2200b238fc855c4
Parents: f970de5
Author: Ariel Weisberg ar...@weisberg.ws
Authored: Tue May 19 17:16:10 2015 -0400
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 15:33:12 2015 +0300

--
 .../cassandra/cql3/SliceQueryFilterWithTombstonesTest.java   | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0088e5f1/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java 
b/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
index 0cb9819..a3f7197 100644
--- 
a/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
@@ -19,10 +19,11 @@ package org.apache.cassandra.cql3;
 
 import java.util.concurrent.TimeUnit;
 
+import com.google.common.base.Throwables;
+
 import org.junit.AfterClass;
 import org.junit.BeforeClass;
 import org.junit.Test;
-
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.filter.TombstoneOverwhelmingException;
 
@@ -84,7 +85,10 @@ public class SliceQueryFilterWithTombstonesTest extends 
CQLTester
 }
 catch (Throwable e)
 {
-assertTrue(e instanceof TombstoneOverwhelmingException);
+String error = Expected exception instanceof 
TombstoneOverwhelmingException instead got 
+  + System.lineSeparator()
+  + Throwables.getStackTraceAsString(e);
+assertTrue(error, e instanceof TombstoneOverwhelmingException);
 }
 }
 



cassandra git commit: Add a more verbose assert to SQFWTT.testBeyondThresholdSelect()

2015-05-20 Thread aleksey
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 f970de557 - 0088e5f1e


Add a more verbose assert to SQFWTT.testBeyondThresholdSelect()

patch by Ariel Weisberg; reveiwed by Aleksey Yeschenko for
CASSANDRA-9432


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

Branch: refs/heads/cassandra-2.2
Commit: 0088e5f1e85bd344cbbc7f7ab2200b238fc855c4
Parents: f970de5
Author: Ariel Weisberg ar...@weisberg.ws
Authored: Tue May 19 17:16:10 2015 -0400
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 15:33:12 2015 +0300

--
 .../cassandra/cql3/SliceQueryFilterWithTombstonesTest.java   | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0088e5f1/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java 
b/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
index 0cb9819..a3f7197 100644
--- 
a/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
@@ -19,10 +19,11 @@ package org.apache.cassandra.cql3;
 
 import java.util.concurrent.TimeUnit;
 
+import com.google.common.base.Throwables;
+
 import org.junit.AfterClass;
 import org.junit.BeforeClass;
 import org.junit.Test;
-
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.filter.TombstoneOverwhelmingException;
 
@@ -84,7 +85,10 @@ public class SliceQueryFilterWithTombstonesTest extends 
CQLTester
 }
 catch (Throwable e)
 {
-assertTrue(e instanceof TombstoneOverwhelmingException);
+String error = Expected exception instanceof 
TombstoneOverwhelmingException instead got 
+  + System.lineSeparator()
+  + Throwables.getStackTraceAsString(e);
+assertTrue(error, e instanceof TombstoneOverwhelmingException);
 }
 }
 



[jira] [Commented] (CASSANDRA-9434) If a node loses schema_columns SSTables it could delete all secondary indexes from the schema

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-9434:
--

Fundamentally the issue is the loss of those sstables, and some of the ways we 
store schema. A lot will be addressed by CASSANDRA-6717 in 3.0.0.

That said, I'll to look into minimizing the damage from this edge case on 2.0. 
This is no good.

 If a node loses schema_columns SSTables it could delete all secondary indexes 
 from the schema
 -

 Key: CASSANDRA-9434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9434
 Project: Cassandra
  Issue Type: Bug
Reporter: Richard Low

 It is possible that a single bad node can delete all secondary indexes if it 
 restarts and cannot read its schema_columns SSTables. Here's a reproduction:
 * Create a 2 node cluster (we saw it on 2.0.11)
 * Create the schema:
 {code}
 create keyspace myks with replication = {'class':'SimpleStrategy', 
 'replication_factor':1};
 use myks;
 create table mytable (a text, b text, c text, PRIMARY KEY (a, b) );
 create index myindex on mytable(b);
 {code}
 NB index must be on clustering column to repro
 * Kill one node
 * Wipe its commitlog and system/schema_columns sstables.
 * Start it again
 * Run on this node
 select index_name from system.schema_columns where keyspace_name = 'myks' and 
 columnfamily_name = 'mytable' and column_name = 'b';
 and you'll see the index is null.
 * Run 'describe schema' on the other node. Sometimes it will not show the 
 index, but you might need to bounce for it to disappear.
 I think the culprit is SystemKeyspace.copyAllAliasesToColumnsProper.



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


[jira] [Updated] (CASSANDRA-9434) If a node loses schema_columns SSTables it could delete all secondary indexes from the schema

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-9434:
-
Fix Version/s: 2.0.x

 If a node loses schema_columns SSTables it could delete all secondary indexes 
 from the schema
 -

 Key: CASSANDRA-9434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9434
 Project: Cassandra
  Issue Type: Bug
Reporter: Richard Low
Assignee: Aleksey Yeschenko
 Fix For: 2.0.x


 It is possible that a single bad node can delete all secondary indexes if it 
 restarts and cannot read its schema_columns SSTables. Here's a reproduction:
 * Create a 2 node cluster (we saw it on 2.0.11)
 * Create the schema:
 {code}
 create keyspace myks with replication = {'class':'SimpleStrategy', 
 'replication_factor':1};
 use myks;
 create table mytable (a text, b text, c text, PRIMARY KEY (a, b) );
 create index myindex on mytable(b);
 {code}
 NB index must be on clustering column to repro
 * Kill one node
 * Wipe its commitlog and system/schema_columns sstables.
 * Start it again
 * Run on this node
 select index_name from system.schema_columns where keyspace_name = 'myks' and 
 columnfamily_name = 'mytable' and column_name = 'b';
 and you'll see the index is null.
 * Run 'describe schema' on the other node. Sometimes it will not show the 
 index, but you might need to bounce for it to disappear.
 I think the culprit is SystemKeyspace.copyAllAliasesToColumnsProper.



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


[jira] [Commented] (CASSANDRA-9420) Table option for promising that you will never touch a column twice

2015-05-20 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-9420:
-

bq. What we should have done back then was to make that option not a default, 
but an enforced constrain. So that every update/insert always comes with the 
same TTL

The problem Björn wants to improve is explicitly the case where there is lots 
of variations in TTLs, so such option won't really help. And as he said, when 
all TTLs are the same, DTCS is able to drop expired sstable very efficiently so 
that this kind of option is not really needed for that case either.

bq. Even if gc gs is 0, we must ensure that there is no intersection with other 
sstables, before purging it.

Yes, but as the description mentions time series and DTCS, so I assumed the 
min timestamp checks would solve this. But I was wrong. As Björn says, with 
variable TTLs, the min timestamp check will rarely help.  

That said, there is probably  better heuristics to improve this case.  For 
instance, in theory, we could use the the sstable max/min clustering values 
which, for time series with DTCS, would allow to decide that most cells can't 
intersect any non-compacted sstable (one question being how efficient we can 
make that check be).

Because Cassandra cannot guarantee you won't override a column, so adding an 
option that tells it to assume it blindly feels pretty dangerous and I'm 
personally really not a fan.

 Table option for promising that you will never touch a column twice
 ---

 Key: CASSANDRA-9420
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9420
 Project: Cassandra
  Issue Type: New Feature
Reporter: Björn Hegerfors

 There are time series use cases where you write all values with various TTLs, 
 have GC grace = 0 and never ever update or delete a column after insertion. 
 In the case where all TTLs are the same, DTCS with recent patches works 
 great. But when there is lots of variations in TTLs, you are forced to choose 
 between splitting your table into multiple TTL tiers or having your SSTables 
 filled to the majority with tombstones. Or running frequent major compactions.
 The problem stems from the fact that Cassandra plays safe when a TTL has 
 expired, and turns it into a tombstone, rather than getting rid of it on the 
 spot. The reason is that this TTL _may_ have been in a column which has had 
 an earlier write without (or with a higher) TTL. And then that one should now 
 be deleted too.
 I propose that there should be table level setting to say I guarantee that 
 there will never be any updates to any columns. The effect of enabling that 
 option is that all tombstones and expired TTLs should always be immediately 
 removed during compaction. And the check for dropping entirely expired 
 SSTables can be very loosened for these tables.
 This option should probably require gc_grace_seconds to be set to zero. It's 
 also questionable if writes without TTL should be allowed to such a table, 
 since those would become constants.



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


[jira] [Created] (CASSANDRA-9437) Improve checking of internal invariants in LCS

2015-05-20 Thread Marcus Eriksson (JIRA)
Marcus Eriksson created CASSANDRA-9437:
--

 Summary: Improve checking of internal invariants in LCS
 Key: CASSANDRA-9437
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9437
 Project: Cassandra
  Issue Type: Improvement
Reporter: Marcus Eriksson


There are quite a few invariants in LCS (not having overlaps within a level 
being the big one)

We should add more checks for these things, at least when running tests



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


[jira] [Commented] (CASSANDRA-9420) Table option for promising that you will never touch a column twice

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-9420:
--

Right. I was speaking slightly out of context of this ticket.

Anecdotally, from observing #cassandra and talking to Field people, it seems 
like there are many users relying just on TTL and never doing any updates. 
Having an option for them to express it in metadata, and for us to enforce it, 
would allow us to drop expired TTL cells much more aggressively.

I'm speaking of using the same TTL everywhere, here, which should be at least 
as common as varying TTLs. We don't care about overwrites here at all, only 
need to enforce that all UPDATEs and INSERTs come with the same default TTL at 
all times. Maybe forbid DELETEs too.

[~mstump] Am I talking nonsense here? Is this relevant at all?

 Table option for promising that you will never touch a column twice
 ---

 Key: CASSANDRA-9420
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9420
 Project: Cassandra
  Issue Type: New Feature
Reporter: Björn Hegerfors

 There are time series use cases where you write all values with various TTLs, 
 have GC grace = 0 and never ever update or delete a column after insertion. 
 In the case where all TTLs are the same, DTCS with recent patches works 
 great. But when there is lots of variations in TTLs, you are forced to choose 
 between splitting your table into multiple TTL tiers or having your SSTables 
 filled to the majority with tombstones. Or running frequent major compactions.
 The problem stems from the fact that Cassandra plays safe when a TTL has 
 expired, and turns it into a tombstone, rather than getting rid of it on the 
 spot. The reason is that this TTL _may_ have been in a column which has had 
 an earlier write without (or with a higher) TTL. And then that one should now 
 be deleted too.
 I propose that there should be table level setting to say I guarantee that 
 there will never be any updates to any columns. The effect of enabling that 
 option is that all tombstones and expired TTLs should always be immediately 
 removed during compaction. And the check for dropping entirely expired 
 SSTables can be very loosened for these tables.
 This option should probably require gc_grace_seconds to be set to zero. It's 
 also questionable if writes without TTL should be allowed to such a table, 
 since those would become constants.



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


[jira] [Updated] (CASSANDRA-9247) DROP INDEX ks.index_name is a syntax error in 2.0

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-9247:
-
Priority: Minor  (was: Major)

 DROP INDEX ks.index_name is a syntax error in 2.0
 -

 Key: CASSANDRA-9247
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9247
 Project: Cassandra
  Issue Type: Bug
Reporter: Jim Witschey
Assignee: Carl Yeksigian
Priority: Minor
 Fix For: 2.0.x


 In all versions of 2.0, statements like
 {{DROP INDEX ks.index_to_drop;}}
 fail with the error
 {{ErrorMessage code=2000 [Syntax error in CQL query] message=line 1:13 
 missing EOF at '.'}}
 The error doesn't happen in any 2.1 versions or trunk. [The 
 docs|http://docs.datastax.com/en/cql/3.1/cql/cql_reference/drop_index_r.html] 
 don't indicate that the {{DROP INDEX}} statement should work any differently 
 on 2.0.
 [Here|https://github.com/mambocab/cassandra-dtest/blob/drop_index_keyspace_bug/index_keyspace_bug.py]
  is a dtest that produces the error, but I think a patch should include a 
 more isolated test for the component that's failing here.



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


[jira] [Commented] (CASSANDRA-9422) SystemKeyspaceTest fails with non-release version string

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-9422:
--

+1

 SystemKeyspaceTest fails with non-release version string
 

 Key: CASSANDRA-9422
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9422
 Project: Cassandra
  Issue Type: Bug
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
 Fix For: 2.2.0 rc1


 {{SystemKeyspaceTest#snapshotSystemKeyspaceIfUpgrading}} is currently failing 
 on the 2.2 branch because the build version {{2.2.0-beta1-SNAPSHOT}} cannot 
 be parsed as a {{SemanticVersion}}. This is only a problem with the test, as 
 the code under test doesn't actually use {{SemanticVersion}}, it just checks 
 whether the old  new version strings are different.



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


[1/3] cassandra git commit: SystemKeyspaceTest handles dev versions properly

2015-05-20 Thread samt
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 0088e5f1e - f9b6d3dac
  refs/heads/trunk 684ef27dc - 3faa17be5


SystemKeyspaceTest handles dev versions properly

Patch by Sam Tunnicliffe; reviewed by Aleksey Yeschenko for
CASSANDRA-9422


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

Branch: refs/heads/cassandra-2.2
Commit: f9b6d3dac7d60b4409f05c25e743dfbbf32a50f4
Parents: 0088e5f
Author: Sam Tunnicliffe s...@beobal.com
Authored: Tue May 19 13:11:21 2015 +0100
Committer: Sam Tunnicliffe s...@beobal.com
Committed: Wed May 20 14:17:24 2015 +0100

--
 .../org/apache/cassandra/db/SystemKeyspaceTest.java | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f9b6d3da/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java 
b/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
index b0101bc..7531b06 100644
--- a/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
+++ b/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
@@ -90,8 +90,7 @@ public class SystemKeyspaceTest
 assertTrue(getSystemSnapshotFiles().isEmpty());
 
 // now setup system.local as if we're upgrading from a previous version
-SemanticVersion next = getCurrentReleaseVersion();
-setupReleaseVersion(new SemanticVersion(String.format(%s.%s.%s, 
next.major - 1, next.minor, next.patch)));
+setupReleaseVersion(getOlderVersionString());
 Keyspace.clearSnapshot(null, SystemKeyspace.NAME);
 assertTrue(getSystemSnapshotFiles().isEmpty());
 
@@ -102,15 +101,18 @@ public class SystemKeyspaceTest
 // clear out the snapshots  set the previous recorded version equal 
to the latest, we shouldn't
 // see any new snapshots created this time.
 Keyspace.clearSnapshot(null, SystemKeyspace.NAME);
-setupReleaseVersion(getCurrentReleaseVersion());
+setupReleaseVersion(FBUtilities.getReleaseVersionString());
 
 SystemKeyspace.snapshotOnVersionChange();
 assertTrue(getSystemSnapshotFiles().isEmpty());
 }
 
-private SemanticVersion getCurrentReleaseVersion()
+private String getOlderVersionString()
 {
-return new SemanticVersion(FBUtilities.getReleaseVersionString());
+String version = FBUtilities.getReleaseVersionString();
+SemanticVersion semver = new SemanticVersion(version.contains(-) ? 
version.substring(0, version.indexOf('-'))
+   : 
version);
+return (String.format(%s.%s.%s, semver.major - 1, semver.minor, 
semver.patch));
 }
 
 private SetString getSystemSnapshotFiles()
@@ -124,7 +126,7 @@ public class SystemKeyspaceTest
 return snapshottedTableNames;
 }
 
-private void setupReleaseVersion(SemanticVersion version)
+private void setupReleaseVersion(String version)
 {
 // besides the release_version, we also need to insert the 
cluster_name or the check
 // in SystemKeyspace.checkHealth were we verify it matches 
DatabaseDescriptor will fail
@@ -133,7 +135,7 @@ public class SystemKeyspaceTest
  version,
  
DatabaseDescriptor.getClusterName()));
 String r = readLocalVersion();
-assertEquals(String.format(Expected %s, got %s, version, r), 
version.toString(), r);
+assertEquals(String.format(Expected %s, got %s, version, r), 
version, r);
 }
 
 private String readLocalVersion()



[2/3] cassandra git commit: SystemKeyspaceTest handles dev versions properly

2015-05-20 Thread samt
SystemKeyspaceTest handles dev versions properly

Patch by Sam Tunnicliffe; reviewed by Aleksey Yeschenko for
CASSANDRA-9422


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

Branch: refs/heads/trunk
Commit: f9b6d3dac7d60b4409f05c25e743dfbbf32a50f4
Parents: 0088e5f
Author: Sam Tunnicliffe s...@beobal.com
Authored: Tue May 19 13:11:21 2015 +0100
Committer: Sam Tunnicliffe s...@beobal.com
Committed: Wed May 20 14:17:24 2015 +0100

--
 .../org/apache/cassandra/db/SystemKeyspaceTest.java | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f9b6d3da/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java 
b/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
index b0101bc..7531b06 100644
--- a/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
+++ b/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
@@ -90,8 +90,7 @@ public class SystemKeyspaceTest
 assertTrue(getSystemSnapshotFiles().isEmpty());
 
 // now setup system.local as if we're upgrading from a previous version
-SemanticVersion next = getCurrentReleaseVersion();
-setupReleaseVersion(new SemanticVersion(String.format(%s.%s.%s, 
next.major - 1, next.minor, next.patch)));
+setupReleaseVersion(getOlderVersionString());
 Keyspace.clearSnapshot(null, SystemKeyspace.NAME);
 assertTrue(getSystemSnapshotFiles().isEmpty());
 
@@ -102,15 +101,18 @@ public class SystemKeyspaceTest
 // clear out the snapshots  set the previous recorded version equal 
to the latest, we shouldn't
 // see any new snapshots created this time.
 Keyspace.clearSnapshot(null, SystemKeyspace.NAME);
-setupReleaseVersion(getCurrentReleaseVersion());
+setupReleaseVersion(FBUtilities.getReleaseVersionString());
 
 SystemKeyspace.snapshotOnVersionChange();
 assertTrue(getSystemSnapshotFiles().isEmpty());
 }
 
-private SemanticVersion getCurrentReleaseVersion()
+private String getOlderVersionString()
 {
-return new SemanticVersion(FBUtilities.getReleaseVersionString());
+String version = FBUtilities.getReleaseVersionString();
+SemanticVersion semver = new SemanticVersion(version.contains(-) ? 
version.substring(0, version.indexOf('-'))
+   : 
version);
+return (String.format(%s.%s.%s, semver.major - 1, semver.minor, 
semver.patch));
 }
 
 private SetString getSystemSnapshotFiles()
@@ -124,7 +126,7 @@ public class SystemKeyspaceTest
 return snapshottedTableNames;
 }
 
-private void setupReleaseVersion(SemanticVersion version)
+private void setupReleaseVersion(String version)
 {
 // besides the release_version, we also need to insert the 
cluster_name or the check
 // in SystemKeyspace.checkHealth were we verify it matches 
DatabaseDescriptor will fail
@@ -133,7 +135,7 @@ public class SystemKeyspaceTest
  version,
  
DatabaseDescriptor.getClusterName()));
 String r = readLocalVersion();
-assertEquals(String.format(Expected %s, got %s, version, r), 
version.toString(), r);
+assertEquals(String.format(Expected %s, got %s, version, r), 
version, r);
 }
 
 private String readLocalVersion()



cassandra git commit: Add a more verbose assert to SQFWTT.testBeyondThresholdSelect()

2015-05-20 Thread aleksey
Repository: cassandra
Updated Branches:
  refs/heads/trunk 16736314b - 66772b7ab


Add a more verbose assert to SQFWTT.testBeyondThresholdSelect()

patch by Ariel Weisberg; reveiwed by Aleksey Yeschenko for
CASSANDRA-9432


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

Branch: refs/heads/trunk
Commit: 66772b7ab5396f373a77c8f9a02e14aad5669065
Parents: 1673631
Author: Ariel Weisberg ar...@weisberg.ws
Authored: Tue May 19 17:16:10 2015 -0400
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 15:29:08 2015 +0300

--
 .../cassandra/cql3/SliceQueryFilterWithTombstonesTest.java   | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/66772b7a/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java 
b/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
index 0cb9819..a3f7197 100644
--- 
a/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/SliceQueryFilterWithTombstonesTest.java
@@ -19,10 +19,11 @@ package org.apache.cassandra.cql3;
 
 import java.util.concurrent.TimeUnit;
 
+import com.google.common.base.Throwables;
+
 import org.junit.AfterClass;
 import org.junit.BeforeClass;
 import org.junit.Test;
-
 import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.db.filter.TombstoneOverwhelmingException;
 
@@ -84,7 +85,10 @@ public class SliceQueryFilterWithTombstonesTest extends 
CQLTester
 }
 catch (Throwable e)
 {
-assertTrue(e instanceof TombstoneOverwhelmingException);
+String error = Expected exception instanceof 
TombstoneOverwhelmingException instead got 
+  + System.lineSeparator()
+  + Throwables.getStackTraceAsString(e);
+assertTrue(error, e instanceof TombstoneOverwhelmingException);
 }
 }
 



[jira] [Updated] (CASSANDRA-9434) If a node loses schema_columns SSTables it could delete all secondary indexes from the schema

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko updated CASSANDRA-9434:
-
Assignee: Aleksey Yeschenko

 If a node loses schema_columns SSTables it could delete all secondary indexes 
 from the schema
 -

 Key: CASSANDRA-9434
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9434
 Project: Cassandra
  Issue Type: Bug
Reporter: Richard Low
Assignee: Aleksey Yeschenko
 Fix For: 2.0.x


 It is possible that a single bad node can delete all secondary indexes if it 
 restarts and cannot read its schema_columns SSTables. Here's a reproduction:
 * Create a 2 node cluster (we saw it on 2.0.11)
 * Create the schema:
 {code}
 create keyspace myks with replication = {'class':'SimpleStrategy', 
 'replication_factor':1};
 use myks;
 create table mytable (a text, b text, c text, PRIMARY KEY (a, b) );
 create index myindex on mytable(b);
 {code}
 NB index must be on clustering column to repro
 * Kill one node
 * Wipe its commitlog and system/schema_columns sstables.
 * Start it again
 * Run on this node
 select index_name from system.schema_columns where keyspace_name = 'myks' and 
 columnfamily_name = 'mytable' and column_name = 'b';
 and you'll see the index is null.
 * Run 'describe schema' on the other node. Sometimes it will not show the 
 index, but you might need to bounce for it to disappear.
 I think the culprit is SystemKeyspace.copyAllAliasesToColumnsProper.



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


[jira] [Updated] (CASSANDRA-9400) smallint, tinyint, date + time types in UDFs

2015-05-20 Thread Sam Tunnicliffe (JIRA)

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

Sam Tunnicliffe updated CASSANDRA-9400:
---
Reviewer: Sam Tunnicliffe

 smallint, tinyint, date + time types in UDFs
 

 Key: CASSANDRA-9400
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9400
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Robert Stupp
Assignee: Robert Stupp
 Fix For: 2.2.0 rc1


 Cassandra 2.2 adds new types {{smallint}}, {{tinyint, {{date}} + {{time}}.
 However the bundled Java driver does not support them.
 There are two options:
 # Do not allow the new types {{smallint}}, {{tinyint}}, {{date}} + {{time}} 
 for UDFs
 # Use a new Java Driver version that can handle these types.
 Probably we should go with option 1 and update the driver in a 2.2.x release?



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


[jira] [Updated] (CASSANDRA-8609) Remove depency of hadoop to internals (Cell/CellName)

2015-05-20 Thread Sam Tunnicliffe (JIRA)

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

Sam Tunnicliffe updated CASSANDRA-8609:
---
Reviewer: Sam Tunnicliffe

 Remove depency of hadoop to internals (Cell/CellName)
 -

 Key: CASSANDRA-8609
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8609
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Philip Thompson
 Fix For: 2.2.0 rc1

 Attachments: 8609-2.2.txt, CASSANDRA-8609-3.0-branch.txt


 For some reason most of the Hadoop code (ColumnFamilyRecordReader, 
 CqlStorage, ...) uses the {{Cell}} and {{CellName}} classes. That dependency 
 is entirely artificial: all this code is really client code that communicate 
 with Cassandra over thrift/native protocol and there is thus no reason for it 
 to use internal classes. And in fact, thoses classes are used in a very crude 
 way, as a {{PairByteBuffer, ByteBuffer}} really.
 But this dependency is really painful when we make changes to the internals. 
 Further, every time we do so, I believe we break some of those the APIs due 
 to the change. This has been painful for CASSANDRA-5417 and this is now 
 painful for CASSANDRA-8099. But while I somewhat hack over it in 
 CASSANDRA-5417, this was a mistake and we should have removed the depency 
 back then. So let do that now.



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


[3/3] cassandra git commit: Merge branch 'cassandra-2.2' into trunk

2015-05-20 Thread samt
Merge branch 'cassandra-2.2' into trunk


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

Branch: refs/heads/trunk
Commit: 3faa17be5f8136ecc8ca3e3cb1074103fca1055f
Parents: 684ef27 f9b6d3d
Author: Sam Tunnicliffe s...@beobal.com
Authored: Wed May 20 14:20:32 2015 +0100
Committer: Sam Tunnicliffe s...@beobal.com
Committed: Wed May 20 14:20:32 2015 +0100

--
 .../org/apache/cassandra/db/SystemKeyspaceTest.java | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)
--




[jira] [Comment Edited] (CASSANDRA-9420) Table option for promising that you will never touch a column twice

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko edited comment on CASSANDRA-9420 at 5/20/15 1:34 PM:
---

Right. I was speaking slightly out of context of this ticket.

Anecdotally, from observing #cassandra and talking to Field people, it seems 
like there are many users relying just on TTL and never doing any deletes. 
Having an option for them to express it in metadata, and for us to enforce it, 
would allow us to drop expired TTL cells much more aggressively.

I'm speaking of using the same TTL everywhere, here, which should be at least 
as common as varying TTLs. We don't care about overwrites here at all, only 
need to enforce that all UPDATEs and INSERTs come with the same default TTL at 
all times. Maybe forbid DELETEs too.

[~mstump] Am I talking nonsense here? Is this relevant at all?


was (Author: iamaleksey):
Right. I was speaking slightly out of context of this ticket.

Anecdotally, from observing #cassandra and talking to Field people, it seems 
like there are many users relying just on TTL and never doing any updates. 
Having an option for them to express it in metadata, and for us to enforce it, 
would allow us to drop expired TTL cells much more aggressively.

I'm speaking of using the same TTL everywhere, here, which should be at least 
as common as varying TTLs. We don't care about overwrites here at all, only 
need to enforce that all UPDATEs and INSERTs come with the same default TTL at 
all times. Maybe forbid DELETEs too.

[~mstump] Am I talking nonsense here? Is this relevant at all?

 Table option for promising that you will never touch a column twice
 ---

 Key: CASSANDRA-9420
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9420
 Project: Cassandra
  Issue Type: New Feature
Reporter: Björn Hegerfors

 There are time series use cases where you write all values with various TTLs, 
 have GC grace = 0 and never ever update or delete a column after insertion. 
 In the case where all TTLs are the same, DTCS with recent patches works 
 great. But when there is lots of variations in TTLs, you are forced to choose 
 between splitting your table into multiple TTL tiers or having your SSTables 
 filled to the majority with tombstones. Or running frequent major compactions.
 The problem stems from the fact that Cassandra plays safe when a TTL has 
 expired, and turns it into a tombstone, rather than getting rid of it on the 
 spot. The reason is that this TTL _may_ have been in a column which has had 
 an earlier write without (or with a higher) TTL. And then that one should now 
 be deleted too.
 I propose that there should be table level setting to say I guarantee that 
 there will never be any updates to any columns. The effect of enabling that 
 option is that all tombstones and expired TTLs should always be immediately 
 removed during compaction. And the check for dropping entirely expired 
 SSTables can be very loosened for these tables.
 This option should probably require gc_grace_seconds to be set to zero. It's 
 also questionable if writes without TTL should be allowed to such a table, 
 since those would become constants.



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


[jira] [Assigned] (CASSANDRA-9436) Expose private rpc_address of each Cassandra node

2015-05-20 Thread Carl Yeksigian (JIRA)

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

Carl Yeksigian reassigned CASSANDRA-9436:
-

Assignee: Carl Yeksigian

 Expose private rpc_address of each Cassandra node
 -

 Key: CASSANDRA-9436
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9436
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Piotr Kołaczkowski
Assignee: Carl Yeksigian

 When running Cassandra nodes with collocated Spark nodes and accessing such 
 cluster from remote, to get data-locality right, we need to tell Spark the 
 locations of the Cassandra nodes and they should match the addresses that 
 Spark nodes bind to. Therefore in cloud environments we need to use private 
 IPs for that. Unfortunately, the client which connects from remote would know 
 only the broadcast rpc_addresses which are different.
 Can we have the IP/hostname that every C* node binds to exposed in a system 
 table? 
 I believe system.peers table contains that information (I need to check , but 
 it is missing for the system.local table.



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


[jira] [Commented] (CASSANDRA-7973) cqlsh connect error member_descriptor' object is not callable

2015-05-20 Thread JIRA

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

Per Otterström commented on CASSANDRA-7973:
---

I have reproduced this on Cassandra 2.1.2 and 2.1.5 using python 2.6.6. When 
using python 2.7.7 things work for me.

 cqlsh connect error member_descriptor' object is not callable
 ---

 Key: CASSANDRA-7973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7973
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0
Reporter: Digant Modha
Priority: Minor
  Labels: cqlsh, lhf
 Fix For: 2.1.x


 When using cqlsh (Cassandra 2.1.0) with ssl, python 2.6.9. I get Connection 
 error: ('Unable to connect to any servers', {...: 
 TypeError('member_descriptor' object is not callable,)}) 
 I am able to connect from another machine using python 2.7.5.



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


[jira] [Commented] (CASSANDRA-9393) Cassandra 2.1.5 fails to build with IBM Java 7

2015-05-20 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis commented on CASSANDRA-9393:
---

To be clear, no regressions for Hotspot.  It's okay to have a lower-performing 
alternative for non-Hotspot VMs.

 Cassandra 2.1.5 fails to build with IBM Java 7
 --

 Key: CASSANDRA-9393
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9393
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 7, 
 java version 1.7.0
 Java(TM) SE Runtime Environment
 IBM J9 VM (build 2.7, JRE 1.7.0 Linux s390x-64 Compressed References)
Reporter: Karan Dhiman
Priority: Minor
 Attachments: build-project.log


 com.sun.* packages are not available in the IBM JDK.
 The error that is generated claims that 
 com.sun.management.GarbageCollectionNotificationInfo is not available.
 The build log is attached.



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


[jira] [Commented] (CASSANDRA-7207) nodetool: Allow to stop a specific compaction

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-7207:
--

Is there a good reason to not put it into 2.2 as well?

 nodetool: Allow to stop a specific compaction
 -

 Key: CASSANDRA-7207
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7207
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: PJ
Assignee: Lyuben Todorov
Priority: Minor
  Labels: compaction, nodetool
 Fix For: 3.0 beta 1

 Attachments: trunk-7207.txt


 Currently, 'nodetool stop TYPE' cancels all compactions under the specified 
 type. This is not ideal in a situation where you just want to stop a specific 
 disruptive compaction (in my case, a compaction that is too large for my 
 drive's remaining space).
 This feature request calls for extending the nodetool 'stop' command to allow 
 stopping a specific compaction by ID. To make this possible, nodetool 
 'compactionstats' should be updated to expose the ID from 
 system.compactions_in_progress.



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


[jira] [Updated] (CASSANDRA-7973) cqlsh connect error member_descriptor' object is not callable

2015-05-20 Thread Philip Thompson (JIRA)

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

Philip Thompson updated CASSANDRA-7973:
---
Assignee: Stefania

 cqlsh connect error member_descriptor' object is not callable
 ---

 Key: CASSANDRA-7973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7973
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0
Reporter: Digant Modha
Assignee: Stefania
Priority: Minor
  Labels: cqlsh, lhf
 Fix For: 2.1.x


 When using cqlsh (Cassandra 2.1.0) with ssl, python 2.6.9. I get Connection 
 error: ('Unable to connect to any servers', {...: 
 TypeError('member_descriptor' object is not callable,)}) 
 I am able to connect from another machine using python 2.7.5.



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


[jira] [Commented] (CASSANDRA-9435) Documetation bug

2015-05-20 Thread Philip Thompson (JIRA)

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

Philip Thompson commented on CASSANDRA-9435:


Thanks, could I have a link to the incorrect page?

 Documetation bug
 

 Key: CASSANDRA-9435
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9435
 Project: Cassandra
  Issue Type: Bug
  Components: Documentation  website
 Environment: Debian 7
Reporter: jincer
Priority: Minor
 Fix For: 2.1.5


 Hello, you have some inaccuracy at docs on your website. 
 When i try to change snitch from default to EC2Snitch (endpoint_snitch: 
 EC2Snitch) i have message, that  Unable to find snitch class 
 'org.apache.cassandra.locator.EC2Snitch'  .
 Only when i change endpoint_snitch: EC2Snitch to endpoint_snitch: 
 Ec2Snitch it has been started. 
 Thank you.



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


[jira] [Updated] (CASSANDRA-9409) Ensure that UDF and UDAs are keyspace-isolated

2015-05-20 Thread Alan Boudreault (JIRA)

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

Alan Boudreault updated CASSANDRA-9409:
---
Flags: Patch

 Ensure that UDF and UDAs are keyspace-isolated
 --

 Key: CASSANDRA-9409
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9409
 Project: Cassandra
  Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Robert Stupp
 Fix For: 2.2.0 rc1

 Attachments: 9409-with-system.txt, 9409.txt


 In table columns we don't allow to use UDTs from other keyspaces.
 We should also make sure that the following is *not* allowed:
 - UDFs taking UDTs from other keyspaces as arguments or return types
 - UDAs using UDFs from other keyspaces as its subfunctions
 The only exception should be made for {{system}} keyspace. UDAs and UDFs from 
 any keyspace should be able to reference and reuse those.
 Having no dependencies between keyspaces makes this consistent with the way 
 we treat UDTs, which is important, but also simplifies auth in multi-tenant 
 environments, and is also crucial to upcoming 3.X strongly consistent schema 
 work (the ability to treat keyspace as a unit of change and not having to 
 worry about cross-keyspace dependencies).
 P.S. Should *probably* still allow using other keyspaces UDFs and UDAs in 
 {{SELECT}} statements. Strict isolation in schema dependencies is what 
 matters to me here.



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


[jira] [Assigned] (CASSANDRA-9409) Ensure that UDF and UDAs are keyspace-isolated

2015-05-20 Thread Alan Boudreault (JIRA)

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

Alan Boudreault reassigned CASSANDRA-9409:
--

Assignee: Alan Boudreault  (was: Robert Stupp)

 Ensure that UDF and UDAs are keyspace-isolated
 --

 Key: CASSANDRA-9409
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9409
 Project: Cassandra
  Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Alan Boudreault
 Fix For: 2.2.0 rc1

 Attachments: 9409-with-system.txt, 9409.txt


 In table columns we don't allow to use UDTs from other keyspaces.
 We should also make sure that the following is *not* allowed:
 - UDFs taking UDTs from other keyspaces as arguments or return types
 - UDAs using UDFs from other keyspaces as its subfunctions
 The only exception should be made for {{system}} keyspace. UDAs and UDFs from 
 any keyspace should be able to reference and reuse those.
 Having no dependencies between keyspaces makes this consistent with the way 
 we treat UDTs, which is important, but also simplifies auth in multi-tenant 
 environments, and is also crucial to upcoming 3.X strongly consistent schema 
 work (the ability to treat keyspace as a unit of change and not having to 
 worry about cross-keyspace dependencies).
 P.S. Should *probably* still allow using other keyspaces UDFs and UDAs in 
 {{SELECT}} statements. Strict isolation in schema dependencies is what 
 matters to me here.



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


[jira] [Created] (CASSANDRA-9438) Repair version gating will do the wrong thing in rc/beta dev builds

2015-05-20 Thread Jeremiah Jordan (JIRA)
Jeremiah Jordan created CASSANDRA-9438:
--

 Summary: Repair version gating will do the wrong thing in rc/beta 
dev builds
 Key: CASSANDRA-9438
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9438
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jeremiah Jordan
 Fix For: 2.2.0 rc1


The version check gate in AnticompactionTask will fail with -betaX-SNAPSHOT and 
-rcX-SNAPSHOT builds. As SystemKeyspace.getReleaseVersion will return null for 
those.  This means dtests and anyone else testing with dev builds will be 
getting the wrong repair behavior.

[AnticompactionTask.java|https://github.com/apache/cassandra/blob/a583f70eeeada31478a55b5774ef222c55956220/src/java/org/apache/cassandra/repair/AnticompactionTask.java#L59]

{code}
SemanticVersion peerVersion = 
SystemKeyspace.getReleaseVersion(neighbor);
if (peerVersion != null  peerVersion.compareTo(VERSION_CHECKER)  0)
{
MessagingService.instance().sendRR(acr.createMessage(), neighbor, 
new AnticompactionCallback(this), TimeUnit.DAYS.toMillis(1), true);
}
else
{
MessagingService.instance().sendOneWay(acr.createMessage(), 
neighbor);
// immediately return after sending request
set(neighbor);
}
{code}



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


[jira] [Updated] (CASSANDRA-9409) Ensure that UDF and UDAs are keyspace-isolated

2015-05-20 Thread Alan Boudreault (JIRA)

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

Alan Boudreault updated CASSANDRA-9409:
---
Assignee: Robert Stupp  (was: Alan Boudreault)

 Ensure that UDF and UDAs are keyspace-isolated
 --

 Key: CASSANDRA-9409
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9409
 Project: Cassandra
  Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Robert Stupp
 Fix For: 2.2.0 rc1

 Attachments: 9409-with-system.txt, 9409.txt


 In table columns we don't allow to use UDTs from other keyspaces.
 We should also make sure that the following is *not* allowed:
 - UDFs taking UDTs from other keyspaces as arguments or return types
 - UDAs using UDFs from other keyspaces as its subfunctions
 The only exception should be made for {{system}} keyspace. UDAs and UDFs from 
 any keyspace should be able to reference and reuse those.
 Having no dependencies between keyspaces makes this consistent with the way 
 we treat UDTs, which is important, but also simplifies auth in multi-tenant 
 environments, and is also crucial to upcoming 3.X strongly consistent schema 
 work (the ability to treat keyspace as a unit of change and not having to 
 worry about cross-keyspace dependencies).
 P.S. Should *probably* still allow using other keyspaces UDFs and UDAs in 
 {{SELECT}} statements. Strict isolation in schema dependencies is what 
 matters to me here.



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


cassandra git commit: Add ability to stop compaction by ID

2015-05-20 Thread yukim
Repository: cassandra
Updated Branches:
  refs/heads/trunk 3faa17be5 - e194fe9d8


Add ability to stop compaction by ID

patch by Lyuben Todorov; reviewed by yukim for CASSANDRA-7207


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

Branch: refs/heads/trunk
Commit: e194fe9d8ca01718277ec316e2d19b5c75e387cd
Parents: 3faa17b
Author: Lyuben Todorov lyu...@mail.com
Authored: Tue May 19 11:36:38 2015 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Wed May 20 08:41:28 2015 -0500

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java |  4 +++-
 .../compaction/AbstractCompactionIterable.java  |  8 ++--
 .../cassandra/db/compaction/CompactionInfo.java | 20 +--
 .../db/compaction/CompactionIterable.java   |  9 +++--
 .../db/compaction/CompactionManager.java| 21 +---
 .../db/compaction/CompactionManagerMBean.java   |  8 
 .../cassandra/db/compaction/CompactionTask.java |  2 +-
 .../cassandra/db/compaction/Scrubber.java   |  6 +-
 .../cassandra/db/compaction/Upgrader.java   |  3 ++-
 .../cassandra/db/compaction/Verifier.java   |  6 +-
 .../db/index/SecondaryIndexBuilder.java |  7 ++-
 .../org/apache/cassandra/tools/NodeProbe.java   |  5 +
 .../tools/nodetool/CompactionStats.java |  9 +
 .../apache/cassandra/tools/nodetool/Stop.java   | 17 ++--
 15 files changed, 101 insertions(+), 25 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e194fe9d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5642cd4..1912372 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 3.0:
  * Decommissioned nodes will not rejoin the cluster (CASSANDRA-8801)
  * Change gossip stabilization to use endpoit size (CASSANDRA-9401)
+ * Add ability to stop compaction by ID (CASSANDRA-7207)
 
 2.2
  * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e194fe9d/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--
diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java 
b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
index 7a9c3da..b381224 100644
--- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
+++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
@@ -42,6 +42,7 @@ import org.apache.cassandra.io.util.*;
 import org.apache.cassandra.service.CacheService;
 import org.apache.cassandra.utils.JVMStabilityInspector;
 import org.apache.cassandra.utils.Pair;
+import org.apache.cassandra.utils.UUIDGen;
 
 public class AutoSavingCacheK extends CacheKey, V extends 
InstrumentingCacheK, V
 {
@@ -210,7 +211,8 @@ public class AutoSavingCacheK extends CacheKey, V extends 
InstrumentingCacheK
   type,
   0,
   keysEstimate,
-  keys);
+  keys,
+  UUIDGen.getTimeUUID());
 }
 
 public CacheService.CacheType cacheType()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e194fe9d/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java 
b/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
index 5ac2c8b..9fe8fd9 100644
--- 
a/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
@@ -18,6 +18,7 @@
 package org.apache.cassandra.db.compaction;
 
 import java.util.List;
+import java.util.UUID;
 import java.util.concurrent.atomic.AtomicLong;
 
 import org.apache.cassandra.io.sstable.ISSTableScanner;
@@ -30,6 +31,7 @@ public abstract class AbstractCompactionIterable extends 
CompactionInfo.Holder i
 protected final long totalBytes;
 protected volatile long bytesRead;
 protected final ListISSTableScanner scanners;
+protected final UUID compactionId;
 /*
  * counters for merged rows.
  * array index represents (number of merged rows - 1), so index 0 is 
counter for no merge (1 row),
@@ -37,12 +39,13 @@ public abstract class AbstractCompactionIterable extends 
CompactionInfo.Holder i
   

[jira] [Updated] (CASSANDRA-7973) cqlsh connect error member_descriptor' object is not callable

2015-05-20 Thread Philip Thompson (JIRA)

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

Philip Thompson updated CASSANDRA-7973:
---
Reproduced In: 2.1.5, 2.1.0  (was: 2.1.0)

 cqlsh connect error member_descriptor' object is not callable
 ---

 Key: CASSANDRA-7973
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7973
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.1.0
Reporter: Digant Modha
Assignee: Stefania
Priority: Minor
  Labels: cqlsh, lhf
 Fix For: 2.1.x


 When using cqlsh (Cassandra 2.1.0) with ssl, python 2.6.9. I get Connection 
 error: ('Unable to connect to any servers', {...: 
 TypeError('member_descriptor' object is not callable,)}) 
 I am able to connect from another machine using python 2.7.5.



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


[jira] [Reopened] (CASSANDRA-9409) Ensure that UDF and UDAs are keyspace-isolated

2015-05-20 Thread Alan Boudreault (JIRA)

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

Alan Boudreault reopened CASSANDRA-9409:


 Ensure that UDF and UDAs are keyspace-isolated
 --

 Key: CASSANDRA-9409
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9409
 Project: Cassandra
  Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Robert Stupp
 Fix For: 2.2.0 rc1

 Attachments: 9409-with-system.txt, 9409.txt


 In table columns we don't allow to use UDTs from other keyspaces.
 We should also make sure that the following is *not* allowed:
 - UDFs taking UDTs from other keyspaces as arguments or return types
 - UDAs using UDFs from other keyspaces as its subfunctions
 The only exception should be made for {{system}} keyspace. UDAs and UDFs from 
 any keyspace should be able to reference and reuse those.
 Having no dependencies between keyspaces makes this consistent with the way 
 we treat UDTs, which is important, but also simplifies auth in multi-tenant 
 environments, and is also crucial to upcoming 3.X strongly consistent schema 
 work (the ability to treat keyspace as a unit of change and not having to 
 worry about cross-keyspace dependencies).
 P.S. Should *probably* still allow using other keyspaces UDFs and UDAs in 
 {{SELECT}} statements. Strict isolation in schema dependencies is what 
 matters to me here.



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


[jira] [Commented] (CASSANDRA-9420) Table option for promising that you will never touch a column twice

2015-05-20 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-9420:
-

bq.  I was speaking slightly out of context of this ticket.

Then would you mind filing a separate ticket so things are talked of in context?

 Table option for promising that you will never touch a column twice
 ---

 Key: CASSANDRA-9420
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9420
 Project: Cassandra
  Issue Type: New Feature
Reporter: Björn Hegerfors

 There are time series use cases where you write all values with various TTLs, 
 have GC grace = 0 and never ever update or delete a column after insertion. 
 In the case where all TTLs are the same, DTCS with recent patches works 
 great. But when there is lots of variations in TTLs, you are forced to choose 
 between splitting your table into multiple TTL tiers or having your SSTables 
 filled to the majority with tombstones. Or running frequent major compactions.
 The problem stems from the fact that Cassandra plays safe when a TTL has 
 expired, and turns it into a tombstone, rather than getting rid of it on the 
 spot. The reason is that this TTL _may_ have been in a column which has had 
 an earlier write without (or with a higher) TTL. And then that one should now 
 be deleted too.
 I propose that there should be table level setting to say I guarantee that 
 there will never be any updates to any columns. The effect of enabling that 
 option is that all tombstones and expired TTLs should always be immediately 
 removed during compaction. And the check for dropping entirely expired 
 SSTables can be very loosened for these tables.
 This option should probably require gc_grace_seconds to be set to zero. It's 
 also questionable if writes without TTL should be allowed to such a table, 
 since those would become constants.



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


[jira] [Commented] (CASSANDRA-9409) Ensure that UDF and UDAs are keyspace-isolated

2015-05-20 Thread Alan Boudreault (JIRA)

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

Alan Boudreault commented on CASSANDRA-9409:


Sorry for the last 73 Jira actions ... it is damn complicated for nothing to 
set the ticket back to the TESTING status.

 Ensure that UDF and UDAs are keyspace-isolated
 --

 Key: CASSANDRA-9409
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9409
 Project: Cassandra
  Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Robert Stupp
 Fix For: 2.2.0 rc1

 Attachments: 9409-with-system.txt, 9409.txt


 In table columns we don't allow to use UDTs from other keyspaces.
 We should also make sure that the following is *not* allowed:
 - UDFs taking UDTs from other keyspaces as arguments or return types
 - UDAs using UDFs from other keyspaces as its subfunctions
 The only exception should be made for {{system}} keyspace. UDAs and UDFs from 
 any keyspace should be able to reference and reuse those.
 Having no dependencies between keyspaces makes this consistent with the way 
 we treat UDTs, which is important, but also simplifies auth in multi-tenant 
 environments, and is also crucial to upcoming 3.X strongly consistent schema 
 work (the ability to treat keyspace as a unit of change and not having to 
 worry about cross-keyspace dependencies).
 P.S. Should *probably* still allow using other keyspaces UDFs and UDAs in 
 {{SELECT}} statements. Strict isolation in schema dependencies is what 
 matters to me here.



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


[jira] [Resolved] (CASSANDRA-9439) 'list index out of range' when selecting counter column

2015-05-20 Thread Tyler Hobbs (JIRA)

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

Tyler Hobbs resolved CASSANDRA-9439.

Resolution: Fixed
  Assignee: Tyler Hobbs

I'm not sure which 2.1 release fixed this, but it does not reproduce on 2.1.5, 
so I'm resolving this as Fixed.

 'list index out of range' when selecting counter column
 ---

 Key: CASSANDRA-9439
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9439
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native 
 protocol v3
Reporter: Jason Walton
Assignee: Tyler Hobbs

 Trying to 'select' a counter column results in list index out of range.
 {code}
 cqlsh:db select * from my_table limit 5;
  bucket_type | type | account_id   | location_id  | 
 bucket   | type_id   | count
 -+--+--+--+--+---+---
 week |  |  |  | 
 20141130 | uncategorized | 1
 week |  |  |  | 
 20140608 | uncategorized | 1
 week |  |  |  | 
 20140525 | uncategorized | 1
 week |  |  |  | 
 20140413 | uncategorized | 1
 week |  |  |  | 
 20140209 | uncategorized | 1
 (5 rows)
 cqlsh:db select bucket_type from my_table limit 5;
  bucket_type
 -
 week
 week
 week
 week
 week
 (5 rows)
 cqlsh:db select count from my_table;
 list index out of range
 cqlsh:db DESCRIBE TABLE my_table
 CREATE TABLE loopdb.my_table (
 bucket_type text,
 type text,
 account_id text,
 location_id text,
 bucket int,
 type_id text,
 count counter,
 PRIMARY KEY ((bucket_type, type, account_id, location_id), bucket, 
 type_id)
 ) WITH CLUSTERING ORDER BY (bucket DESC, type_id ASC)
 AND bloom_filter_fp_chance = 0.01
 AND caching = '{keys:ALL, rows_per_partition:NONE}'
 AND comment = ''
 AND compaction = {'min_threshold': '4', 'class': 
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
 'max_threshold': '32'}
 AND compression = {'sstable_compression': 
 'org.apache.cassandra.io.compress.LZ4Compressor'}
 AND dclocal_read_repair_chance = 0.1
 AND default_time_to_live = 0
 AND gc_grace_seconds = 864000
 AND max_index_interval = 2048
 AND memtable_flush_period_in_ms = 0
 AND min_index_interval = 128
 AND read_repair_chance = 0.0
 AND speculative_retry = '99.0PERCENTILE';
 {code}
 Works on '[cqlsh 4.1.1 | Cassandra 2.0.6 | CQL spec 3.1.1 | Thrift protocol 
 19.39.0]'.
 Broken on '[cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol 
 v3]'.
 With --debug:
 {code}
 cqlsh:db select count from my_table limit 5;
 Traceback (most recent call last):
   File /usr/bin/cqlsh, line 861, in onecmd
 self.handle_statement(st, statementtext)
   File /usr/bin/cqlsh, line 901, in handle_statement
 return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
   File /usr/bin/cqlsh, line 910, in handle_parse_error
 return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
   File /usr/bin/cqlsh, line 935, in perform_statement
 result = self.perform_simple_statement(stmt)
   File /usr/bin/cqlsh, line 968, in perform_simple_statement
 self.print_result(rows, self.parse_for_table_meta(statement.query_string))
   File /usr/bin/cqlsh, line 946, in parse_for_table_meta
 parsed = cqlruleset.cql_parse(query_string)[1]
 IndexError: list index out of range
 {code}



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


[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2015-05-20 Thread aleksey
Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-2.2
Commit: 76b5f30e73ec8bcef03e81a51181d2ee89c85360
Parents: 52dc63b 2248780
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed May 20 20:02:56 2015 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 20:02:56 2015 +0300

--
 CHANGES.txt  | 2 ++
 src/java/org/apache/cassandra/db/RangeTombstone.java | 4 
 2 files changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/76b5f30e/CHANGES.txt
--
diff --cc CHANGES.txt
index 44f9e4c,92d4d54..281d10b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,127 -1,6 +1,129 @@@
 +2.2
 + * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
 + * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
 + * Add ability to stop compaction by ID (CASSANDRA-7207)
 +Merged from 2.1:
+ 2.1.6
+  * Optimize range tombstone memory footprint (CASSANDRA-8603)
   * Use configured gcgs in anticompaction (CASSANDRA-9397)
 +
 +
 +2.2.0-beta1
 + * Introduce Transactional API for internal state changes (CASSANDRA-8984)
 + * Add a flag in cassandra.yaml to enable UDFs (CASSANDRA-9404)
 + * Better support of null for UDF (CASSANDRA-8374)
 + * Use ecj instead of javassist for UDFs (CASSANDRA-8241)
 + * faster async logback configuration for tests (CASSANDRA-9376)
 + * Add `smallint` and `tinyint` data types (CASSANDRA-8951)
 + * Avoid thrift schema creation when native driver is used in stress tool 
(CASSANDRA-9374)
 + * Populate TokenMetadata early during startup (CASSANDRA-9317)
 + * Make Functions.declared thread-safe
 + * Add client warnings to native protocol v4 (CASSANDRA-8930)
 + * Allow roles cache to be invalidated (CASSANDRA-8967)
 + * Upgrade Snappy (CASSANDRA-9063)
 + * Don't start Thrift rpc by default (CASSANDRA-9319)
 + * Only stream from unrepaired sstables with incremental repair 
(CASSANDRA-8267)
 + * Aggregate UDFs allow SFUNC return type to differ from STYPE if FFUNC 
specified (CASSANDRA-9321)
 + * Remove Thrift dependencies in bundled tools (CASSANDRA-8358)
 + * Disable memory mapping of hsperfdata file for JVM statistics 
(CASSANDRA-9242)
 + * Add pre-startup checks to detect potential incompatibilities 
(CASSANDRA-8049)
 + * Distinguish between null and unset in protocol v4 (CASSANDRA-7304)
 + * Add user/role permissions for user-defined functions (CASSANDRA-7557)
 + * Allow cassandra config to be updated to restart daemon without unloading 
classes (CASSANDRA-9046)
 + * Don't initialize compaction writer before checking if iter is empty 
(CASSANDRA-9117)
 + * Don't execute any functions at prepare-time (CASSANDRA-9037)
 + * Share file handles between all instances of a SegmentedFile 
(CASSANDRA-8893)
 + * Make it possible to major compact LCS (CASSANDRA-7272)
 + * Make FunctionExecutionException extend RequestExecutionException
 +   (CASSANDRA-9055)
 + * Add support for SELECT JSON, INSERT JSON syntax and new toJson(), 
fromJson()
 +   functions (CASSANDRA-7970)
 + * Optimise max purgeable timestamp calculation in compaction (CASSANDRA-8920)
 + * Constrain internode message buffer sizes, and improve IO class hierarchy 
(CASSANDRA-8670) 
 + * New tool added to validate all sstables in a node (CASSANDRA-5791)
 + * Push notification when tracing completes for an operation (CASSANDRA-7807)
 + * Delay node up and node added notifications until native protocol 
server is started (CASSANDRA-8236)
 + * Compressed Commit Log (CASSANDRA-6809)
 + * Optimise IntervalTree (CASSANDRA-8988)
 + * Add a key-value payload for third party usage (CASSANDRA-8553, 9212)
 + * Bump metrics-reporter-config dependency for metrics 3.0 (CASSANDRA-8149)
 + * Partition intra-cluster message streams by size, not type (CASSANDRA-8789)
 + * Add WriteFailureException to native protocol, notify coordinator of
 +   write failures (CASSANDRA-8592)
 + * Convert SequentialWriter to nio (CASSANDRA-8709)
 + * Add role based access control (CASSANDRA-7653, 8650, 7216, 8760, 8849, 
8761, 8850)
 + * Record client ip address in tracing sessions (CASSANDRA-8162)
 + * Indicate partition key columns in response metadata for prepared
 +   statements (CASSANDRA-7660)
 + * Merge UUIDType and TimeUUIDType parse logic (CASSANDRA-8759)
 + * Avoid memory allocation when searching index summary (CASSANDRA-8793)
 + * Optimise (Time)?UUIDType Comparisons (CASSANDRA-8730)
 + * Make CRC32Ex into a separate maven dependency (CASSANDRA-8836)
 + * 

[jira] [Updated] (CASSANDRA-9438) Repair version gating will do the wrong thing in rc/beta dev builds

2015-05-20 Thread Yuki Morishita (JIRA)

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

Yuki Morishita updated CASSANDRA-9438:
--
Attachment: 0001-Support-SNAPSHOT-in-CassandraVersion-formerly-Semant.patch

Patch to ignore {{-SNAPSHOT}} when parsing version string in 
{{CassandraVersion}} (renamed from {{SemanticVersion}}), with some unit tests.

 Repair version gating will do the wrong thing in rc/beta dev builds
 ---

 Key: CASSANDRA-9438
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9438
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jeremiah Jordan
Assignee: Yuki Morishita
 Fix For: 2.2.0 rc1

 Attachments: 
 0001-Support-SNAPSHOT-in-CassandraVersion-formerly-Semant.patch


 The version check gate in AnticompactionTask will fail with -betaX-SNAPSHOT 
 and -rcX-SNAPSHOT builds. As SystemKeyspace.getReleaseVersion will return 
 null for those.  This means dtests and anyone else testing with dev builds 
 will be getting the wrong repair behavior.
 [AnticompactionTask.java|https://github.com/apache/cassandra/blob/a583f70eeeada31478a55b5774ef222c55956220/src/java/org/apache/cassandra/repair/AnticompactionTask.java#L59]
 {code}
 SemanticVersion peerVersion = 
 SystemKeyspace.getReleaseVersion(neighbor);
 if (peerVersion != null  peerVersion.compareTo(VERSION_CHECKER)  0)
 {
 MessagingService.instance().sendRR(acr.createMessage(), neighbor, 
 new AnticompactionCallback(this), TimeUnit.DAYS.toMillis(1), true);
 }
 else
 {
 MessagingService.instance().sendOneWay(acr.createMessage(), 
 neighbor);
 // immediately return after sending request
 set(neighbor);
 }
 {code}



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


[1/2] cassandra git commit: Optimize range tombstone memory footprint

2015-05-20 Thread aleksey
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 52dc63b6c - 76b5f30e7


Optimize range tombstone memory footprint

patch by Benjamin Lerer; reviewed by Aleksey Yeschenko for
CASSANDRA-8603


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

Branch: refs/heads/cassandra-2.2
Commit: 2248780eae46d98be8a9414d3e833fb6c16c7137
Parents: 7af9c6a
Author: blerer benjamin.le...@datastax.com
Authored: Tue May 19 16:12:53 2015 +0200
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 19:57:35 2015 +0300

--
 CHANGES.txt  | 1 +
 src/java/org/apache/cassandra/db/RangeTombstone.java | 4 
 2 files changed, 5 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2248780e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6fc1c9c..92d4d54 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.6
+ * Optimize range tombstone memory footprint (CASSANDRA-8603)
  * Use configured gcgs in anticompaction (CASSANDRA-9397)
  * Warn on misuse of unlogged batches (CASSANDRA-9282)
  * Failure detector detects and ignores local pauses (CASSANDRA-9183)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2248780e/src/java/org/apache/cassandra/db/RangeTombstone.java
--
diff --git a/src/java/org/apache/cassandra/db/RangeTombstone.java 
b/src/java/org/apache/cassandra/db/RangeTombstone.java
index 3f3d675..feeadbb 100644
--- a/src/java/org/apache/cassandra/db/RangeTombstone.java
+++ b/src/java/org/apache/cassandra/db/RangeTombstone.java
@@ -273,6 +273,10 @@ public class RangeTombstone extends IntervalComposite, 
DeletionTime implements
 {
 Composite max = type.serializer().deserialize(in);
 DeletionTime dt = DeletionTime.serializer.deserialize(in);
+// If the max equals the min.end(), we can avoid keeping an extra 
ByteBuffer in memory by using
+// min.end() instead of max
+Composite minEnd = min.end();
+max = minEnd.equals(max) ? minEnd : max;
 return new RangeTombstone(min, max, dt);
 }
 



[jira] [Commented] (CASSANDRA-9440) Bootstrap fails without any hint of prior stream failure

2015-05-20 Thread Omid Aladini (JIRA)

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

Omid Aladini commented on CASSANDRA-9440:
-

It might be relevant that the cluster was running with the default 
streaming_socket_timeout_in_ms = 0, but if that's the cause of the failure, 
shouldn't the bootstrap just get stuck?

 Bootstrap fails without any hint of prior stream failure
 

 Key: CASSANDRA-9440
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9440
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.0.14
 2 DCs on EC2
Reporter: Omid Aladini

 I'm working on a cluster running Cassandra 2.0.14 and the bootstrap fails but 
 there is no prior hint of failed streams:
 {code}
  WARN [StreamReceiveTask:177] 2015-05-20 04:20:55,251 StreamResultFuture.java 
 (line 215) [Stream #0b42c640-fe03-11e4-8a6f-dd5dc9b30af4] Stream failed
 ERROR [main] 2015-05-20 04:20:55,252 CassandraDaemon.java (line 584) 
 Exception encountered during startup
 java.lang.RuntimeException: Error during boostrap: Stream failed
 at 
 org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:86)
 at 
 org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1005)
 at 
 org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:808)
 at 
 org.apache.cassandra.service.StorageService.initServer(StorageService.java:621)
 at 
 org.apache.cassandra.service.StorageService.initServer(StorageService.java:510)
 at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:437)
 at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
 at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:656)
 Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
 at 
 org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
 at com.google.common.util.concurrent.Futures$4.run(Futures.java:1160)
 at 
 com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
 at 
 com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
 at 
 com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
 at 
 com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
 at 
 org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:216)
 at 
 org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:191)
 at 
 org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:377)
 at 
 org.apache.cassandra.streaming.StreamSession.maybeCompleted(StreamSession.java:662)
 at 
 org.apache.cassandra.streaming.StreamSession.taskCompleted(StreamSession.java:613)
 at 
 org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:143)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 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)
  INFO [StorageServiceShutdownHook] 2015-05-20 04:20:55,286 Gossiper.java 
 (line 1330) Announcing shutdown
 {code}
 There are no WARN or ERROR prior to this in the log files of the 
 bootstrapping node or other nodes in the cluster. Only relevant log lines are 
 Session with 11.22.33.44/11.22.33.44 is complete
 Is it possible that individual stream sessions fail silently? 



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


[jira] [Updated] (CASSANDRA-7207) nodetool: Allow to stop a specific compaction

2015-05-20 Thread Yuki Morishita (JIRA)

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

Yuki Morishita updated CASSANDRA-7207:
--
Fix Version/s: 2.2.0 rc1

 nodetool: Allow to stop a specific compaction
 -

 Key: CASSANDRA-7207
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7207
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: PJ
Assignee: Lyuben Todorov
Priority: Minor
  Labels: compaction, nodetool
 Fix For: 3.0 beta 1, 2.2.0 rc1

 Attachments: trunk-7207.txt


 Currently, 'nodetool stop TYPE' cancels all compactions under the specified 
 type. This is not ideal in a situation where you just want to stop a specific 
 disruptive compaction (in my case, a compaction that is too large for my 
 drive's remaining space).
 This feature request calls for extending the nodetool 'stop' command to allow 
 stopping a specific compaction by ID. To make this possible, nodetool 
 'compactionstats' should be updated to expose the ID from 
 system.compactions_in_progress.



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


[jira] [Commented] (CASSANDRA-7207) nodetool: Allow to stop a specific compaction

2015-05-20 Thread Yuki Morishita (JIRA)

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

Yuki Morishita commented on CASSANDRA-7207:
---

Alright, committed to 2.2 as well.

 nodetool: Allow to stop a specific compaction
 -

 Key: CASSANDRA-7207
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7207
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: PJ
Assignee: Lyuben Todorov
Priority: Minor
  Labels: compaction, nodetool
 Fix For: 3.0 beta 1, 2.2.0 rc1

 Attachments: trunk-7207.txt


 Currently, 'nodetool stop TYPE' cancels all compactions under the specified 
 type. This is not ideal in a situation where you just want to stop a specific 
 disruptive compaction (in my case, a compaction that is too large for my 
 drive's remaining space).
 This feature request calls for extending the nodetool 'stop' command to allow 
 stopping a specific compaction by ID. To make this possible, nodetool 
 'compactionstats' should be updated to expose the ID from 
 system.compactions_in_progress.



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


[jira] [Commented] (CASSANDRA-9438) Repair version gating will do the wrong thing in rc/beta dev builds

2015-05-20 Thread Yuki Morishita (JIRA)

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

Yuki Morishita commented on CASSANDRA-9438:
---

I think the easier way to fix is to ignore {{-SNAPSHOT}} part when parsing 
version string into {{SemanticVersion}} object.
Also we should rename the class to CassandraVersion as it is no longer dealing 
with semver.

 Repair version gating will do the wrong thing in rc/beta dev builds
 ---

 Key: CASSANDRA-9438
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9438
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jeremiah Jordan
Assignee: Yuki Morishita
 Fix For: 2.2.0 rc1


 The version check gate in AnticompactionTask will fail with -betaX-SNAPSHOT 
 and -rcX-SNAPSHOT builds. As SystemKeyspace.getReleaseVersion will return 
 null for those.  This means dtests and anyone else testing with dev builds 
 will be getting the wrong repair behavior.
 [AnticompactionTask.java|https://github.com/apache/cassandra/blob/a583f70eeeada31478a55b5774ef222c55956220/src/java/org/apache/cassandra/repair/AnticompactionTask.java#L59]
 {code}
 SemanticVersion peerVersion = 
 SystemKeyspace.getReleaseVersion(neighbor);
 if (peerVersion != null  peerVersion.compareTo(VERSION_CHECKER)  0)
 {
 MessagingService.instance().sendRR(acr.createMessage(), neighbor, 
 new AnticompactionCallback(this), TimeUnit.DAYS.toMillis(1), true);
 }
 else
 {
 MessagingService.instance().sendOneWay(acr.createMessage(), 
 neighbor);
 // immediately return after sending request
 set(neighbor);
 }
 {code}



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


[jira] [Commented] (CASSANDRA-9152) Offline tools tests

2015-05-20 Thread Jim Witschey (JIRA)

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

Jim Witschey commented on CASSANDRA-9152:
-

[{{sstableverify}}|https://issues.apache.org/jira/browse/CASSANDRA-5791] 
doesn't seem to have any unit test or dtest coverage either.

 Offline tools tests
 ---

 Key: CASSANDRA-9152
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9152
 Project: Cassandra
  Issue Type: Test
Reporter: Marcus Eriksson
Assignee: Shawn Kumar
  Labels: retrospective_generated
 Fix For: 2.2.x


 we need more tests of our offline tools, sstablescrubber, sstablelevelreset, 
 sstableofflinerelevel, sstablerepairedset, sstabeloader



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


cassandra git commit: Optimize range tombstone memory footprint

2015-05-20 Thread aleksey
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 7af9c6ac8 - 2248780ea


Optimize range tombstone memory footprint

patch by Benjamin Lerer; reviewed by Aleksey Yeschenko for
CASSANDRA-8603


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

Branch: refs/heads/cassandra-2.1
Commit: 2248780eae46d98be8a9414d3e833fb6c16c7137
Parents: 7af9c6a
Author: blerer benjamin.le...@datastax.com
Authored: Tue May 19 16:12:53 2015 +0200
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 19:57:35 2015 +0300

--
 CHANGES.txt  | 1 +
 src/java/org/apache/cassandra/db/RangeTombstone.java | 4 
 2 files changed, 5 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2248780e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6fc1c9c..92d4d54 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.6
+ * Optimize range tombstone memory footprint (CASSANDRA-8603)
  * Use configured gcgs in anticompaction (CASSANDRA-9397)
  * Warn on misuse of unlogged batches (CASSANDRA-9282)
  * Failure detector detects and ignores local pauses (CASSANDRA-9183)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2248780e/src/java/org/apache/cassandra/db/RangeTombstone.java
--
diff --git a/src/java/org/apache/cassandra/db/RangeTombstone.java 
b/src/java/org/apache/cassandra/db/RangeTombstone.java
index 3f3d675..feeadbb 100644
--- a/src/java/org/apache/cassandra/db/RangeTombstone.java
+++ b/src/java/org/apache/cassandra/db/RangeTombstone.java
@@ -273,6 +273,10 @@ public class RangeTombstone extends IntervalComposite, 
DeletionTime implements
 {
 Composite max = type.serializer().deserialize(in);
 DeletionTime dt = DeletionTime.serializer.deserialize(in);
+// If the max equals the min.end(), we can avoid keeping an extra 
ByteBuffer in memory by using
+// min.end() instead of max
+Composite minEnd = min.end();
+max = minEnd.equals(max) ? minEnd : max;
 return new RangeTombstone(min, max, dt);
 }
 



[jira] [Commented] (CASSANDRA-8603) Cut tombstone memory footprint in half for cql deletes

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-8603:
--

Committed to 2.1 as {{2248780eae46d98be8a9414d3e833fb6c16c7137}} and merged up, 
thanks.

 Cut tombstone memory footprint in half for cql deletes
 --

 Key: CASSANDRA-8603
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8603
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Dominic Letz
Assignee: Benjamin Lerer
  Labels: tombstone
 Attachments: 8603-2.1-V3.txt, cassandra-2.0.11-8603.txt, 
 cassandra-2.1-8603.txt, cassandra-2.1-8603_v2.txt, system.log


 As CQL does not yet support range deletes every delete from CQL results in a 
 Semi-RangeTombstone which actually has the same start and end values - but 
 until today they are copies. Effectively doubling the required heap memory to 
 store the RangeTombstone.



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


[jira] [Updated] (CASSANDRA-8103) Secondary Indices for Static Columns

2015-05-20 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-8103:

Fix Version/s: (was: 3.0 beta 1)
   3.x

 Secondary Indices for Static Columns
 

 Key: CASSANDRA-8103
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8103
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Ron Cohen
Assignee: Sam Tunnicliffe
 Fix For: 3.x

 Attachments: in_progress.patch


 We should add secondary index support for static columns.  



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


[jira] [Created] (CASSANDRA-9441) Reject frozen types in UDF

2015-05-20 Thread Aleksey Yeschenko (JIRA)
Aleksey Yeschenko created CASSANDRA-9441:


 Summary: Reject frozen types in UDF
 Key: CASSANDRA-9441
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9441
 Project: Cassandra
  Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Robert Stupp
 Fix For: 2.2.0 rc1


Spin off from CASSANDRA-9186. Rationale in its comments section.



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


[2/3] cassandra git commit: Add ability to stop compaction by ID

2015-05-20 Thread yukim
Add ability to stop compaction by ID

patch by Lyuben Todorov; reviewed by yukim for CASSANDRA-7207


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

Branch: refs/heads/trunk
Commit: 52dc63b6c75ca3f68e4c90dc76f8e1cc65690fb5
Parents: f9b6d3d
Author: Lyuben Todorov lyu...@mail.com
Authored: Tue May 19 11:36:38 2015 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Wed May 20 10:30:16 2015 -0500

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java |  4 +++-
 .../compaction/AbstractCompactionIterable.java  |  8 ++--
 .../cassandra/db/compaction/CompactionInfo.java | 20 +--
 .../db/compaction/CompactionIterable.java   |  9 +++--
 .../db/compaction/CompactionManager.java| 21 +---
 .../db/compaction/CompactionManagerMBean.java   |  8 
 .../cassandra/db/compaction/CompactionTask.java |  2 +-
 .../cassandra/db/compaction/Scrubber.java   |  6 +-
 .../cassandra/db/compaction/Upgrader.java   |  3 ++-
 .../cassandra/db/compaction/Verifier.java   |  6 +-
 .../db/index/SecondaryIndexBuilder.java |  7 ++-
 .../org/apache/cassandra/tools/NodeProbe.java   |  5 +
 .../tools/nodetool/CompactionStats.java |  9 +
 .../apache/cassandra/tools/nodetool/Stop.java   | 17 ++--
 15 files changed, 101 insertions(+), 25 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/52dc63b6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a227f5e..44f9e4c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 2.2
  * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
  * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
+ * Add ability to stop compaction by ID (CASSANDRA-7207)
 Merged from 2.1:
  * Use configured gcgs in anticompaction (CASSANDRA-9397)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/52dc63b6/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--
diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java 
b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
index 7a9c3da..b381224 100644
--- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
+++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
@@ -42,6 +42,7 @@ import org.apache.cassandra.io.util.*;
 import org.apache.cassandra.service.CacheService;
 import org.apache.cassandra.utils.JVMStabilityInspector;
 import org.apache.cassandra.utils.Pair;
+import org.apache.cassandra.utils.UUIDGen;
 
 public class AutoSavingCacheK extends CacheKey, V extends 
InstrumentingCacheK, V
 {
@@ -210,7 +211,8 @@ public class AutoSavingCacheK extends CacheKey, V extends 
InstrumentingCacheK
   type,
   0,
   keysEstimate,
-  keys);
+  keys,
+  UUIDGen.getTimeUUID());
 }
 
 public CacheService.CacheType cacheType()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/52dc63b6/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java 
b/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
index 5ac2c8b..9fe8fd9 100644
--- 
a/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
@@ -18,6 +18,7 @@
 package org.apache.cassandra.db.compaction;
 
 import java.util.List;
+import java.util.UUID;
 import java.util.concurrent.atomic.AtomicLong;
 
 import org.apache.cassandra.io.sstable.ISSTableScanner;
@@ -30,6 +31,7 @@ public abstract class AbstractCompactionIterable extends 
CompactionInfo.Holder i
 protected final long totalBytes;
 protected volatile long bytesRead;
 protected final ListISSTableScanner scanners;
+protected final UUID compactionId;
 /*
  * counters for merged rows.
  * array index represents (number of merged rows - 1), so index 0 is 
counter for no merge (1 row),
@@ -37,12 +39,13 @@ public abstract class AbstractCompactionIterable extends 
CompactionInfo.Holder i
  */
 protected final AtomicLong[] mergeCounters;
 
-

[1/3] cassandra git commit: Add ability to stop compaction by ID

2015-05-20 Thread yukim
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 f9b6d3dac - 52dc63b6c
  refs/heads/trunk e194fe9d8 - 2e48b6af9


Add ability to stop compaction by ID

patch by Lyuben Todorov; reviewed by yukim for CASSANDRA-7207


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

Branch: refs/heads/cassandra-2.2
Commit: 52dc63b6c75ca3f68e4c90dc76f8e1cc65690fb5
Parents: f9b6d3d
Author: Lyuben Todorov lyu...@mail.com
Authored: Tue May 19 11:36:38 2015 -0500
Committer: Yuki Morishita yu...@apache.org
Committed: Wed May 20 10:30:16 2015 -0500

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cache/AutoSavingCache.java |  4 +++-
 .../compaction/AbstractCompactionIterable.java  |  8 ++--
 .../cassandra/db/compaction/CompactionInfo.java | 20 +--
 .../db/compaction/CompactionIterable.java   |  9 +++--
 .../db/compaction/CompactionManager.java| 21 +---
 .../db/compaction/CompactionManagerMBean.java   |  8 
 .../cassandra/db/compaction/CompactionTask.java |  2 +-
 .../cassandra/db/compaction/Scrubber.java   |  6 +-
 .../cassandra/db/compaction/Upgrader.java   |  3 ++-
 .../cassandra/db/compaction/Verifier.java   |  6 +-
 .../db/index/SecondaryIndexBuilder.java |  7 ++-
 .../org/apache/cassandra/tools/NodeProbe.java   |  5 +
 .../tools/nodetool/CompactionStats.java |  9 +
 .../apache/cassandra/tools/nodetool/Stop.java   | 17 ++--
 15 files changed, 101 insertions(+), 25 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/52dc63b6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a227f5e..44f9e4c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
 2.2
  * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
  * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
+ * Add ability to stop compaction by ID (CASSANDRA-7207)
 Merged from 2.1:
  * Use configured gcgs in anticompaction (CASSANDRA-9397)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/52dc63b6/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--
diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java 
b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
index 7a9c3da..b381224 100644
--- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
+++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
@@ -42,6 +42,7 @@ import org.apache.cassandra.io.util.*;
 import org.apache.cassandra.service.CacheService;
 import org.apache.cassandra.utils.JVMStabilityInspector;
 import org.apache.cassandra.utils.Pair;
+import org.apache.cassandra.utils.UUIDGen;
 
 public class AutoSavingCacheK extends CacheKey, V extends 
InstrumentingCacheK, V
 {
@@ -210,7 +211,8 @@ public class AutoSavingCacheK extends CacheKey, V extends 
InstrumentingCacheK
   type,
   0,
   keysEstimate,
-  keys);
+  keys,
+  UUIDGen.getTimeUUID());
 }
 
 public CacheService.CacheType cacheType()

http://git-wip-us.apache.org/repos/asf/cassandra/blob/52dc63b6/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
--
diff --git 
a/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java 
b/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
index 5ac2c8b..9fe8fd9 100644
--- 
a/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
+++ 
b/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java
@@ -18,6 +18,7 @@
 package org.apache.cassandra.db.compaction;
 
 import java.util.List;
+import java.util.UUID;
 import java.util.concurrent.atomic.AtomicLong;
 
 import org.apache.cassandra.io.sstable.ISSTableScanner;
@@ -30,6 +31,7 @@ public abstract class AbstractCompactionIterable extends 
CompactionInfo.Holder i
 protected final long totalBytes;
 protected volatile long bytesRead;
 protected final ListISSTableScanner scanners;
+protected final UUID compactionId;
 /*
  * counters for merged rows.
  * array index represents (number of merged rows - 1), so index 0 is 
counter for no merge (1 row),
@@ -37,12 +39,13 @@ public 

[jira] [Created] (CASSANDRA-9440) Bootstrap fails without any hint of prior stream failure

2015-05-20 Thread Omid Aladini (JIRA)
Omid Aladini created CASSANDRA-9440:
---

 Summary: Bootstrap fails without any hint of prior stream failure
 Key: CASSANDRA-9440
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9440
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.0.14
2 DCs on EC2
Reporter: Omid Aladini


I'm working on a cluster running Cassandra 2.0.14 and the bootstrap fails but 
there is no prior hint of failed streams:

{code}
 WARN [StreamReceiveTask:177] 2015-05-20 04:20:55,251 StreamResultFuture.java 
(line 215) [Stream #0b42c640-fe03-11e4-8a6f-dd5dc9b30af4] Stream failed
ERROR [main] 2015-05-20 04:20:55,252 CassandraDaemon.java (line 584) Exception 
encountered during startup
java.lang.RuntimeException: Error during boostrap: Stream failed
at org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:86)
at 
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1005)
at 
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:808)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:621)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:510)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:437)
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:656)
Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
at 
org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1160)
at 
com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at 
com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at 
com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
at 
com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
at 
org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:216)
at 
org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:191)
at 
org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:377)
at 
org.apache.cassandra.streaming.StreamSession.maybeCompleted(StreamSession.java:662)
at 
org.apache.cassandra.streaming.StreamSession.taskCompleted(StreamSession.java:613)
at 
org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:143)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)
 INFO [StorageServiceShutdownHook] 2015-05-20 04:20:55,286 Gossiper.java (line 
1330) Announcing shutdown

{code}

There are no WARN or ERROR prior to this in the log files of the bootstrapping 
node or other nodes in the cluster. Only relevant log lines are Session with 
11.22.33.44/11.22.33.44 is complete

Is it possible that individual stream sessions fail silently? 



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


cassandra git commit: Fix up CHANGES.txt

2015-05-20 Thread aleksey
Repository: cassandra
Updated Branches:
  refs/heads/trunk 418aefdd2 - 2fd755970


Fix up CHANGES.txt


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

Branch: refs/heads/trunk
Commit: 2fd7559703f64d66cdbb9ee7e3e39726ce2970c6
Parents: 418aefd
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed May 20 20:06:34 2015 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 20:06:34 2015 +0300

--
 CHANGES.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2fd75597/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4ee25ab..d480db7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,11 +1,12 @@
 3.0:
  * Decommissioned nodes will not rejoin the cluster (CASSANDRA-8801)
  * Change gossip stabilization to use endpoit size (CASSANDRA-9401)
- * Add ability to stop compaction by ID (CASSANDRA-7207)
+
 
 2.2
  * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
  * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
+ * Add ability to stop compaction by ID (CASSANDRA-7207)
 Merged from 2.1:
 2.1.6
  * Optimize range tombstone memory footprint (CASSANDRA-8603)



[Cassandra Wiki] Update of Committers by SamTunnicliffe

2015-05-20 Thread Apache Wiki
Dear Wiki user,

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

The Committers page has been changed by SamTunnicliffe:
https://wiki.apache.org/cassandra/Committers?action=diffrev1=51rev2=52

  ||Benedict Elliott Smith ||May 2014 ||Datastax || ||
  ||Josh Mckenzie ||July 2014 ||Datastax || ||
  ||Robert Stupp ||Jan 2015 ||contentteam || ||
+ ||Sam Tunnicliffe ||May 2015 ||Datastax || ||
  
  
  {{https://c.statcounter.com/9397521/0/fe557aad/1/|stats}}


[jira] [Commented] (CASSANDRA-9435) Documetation bug

2015-05-20 Thread Jack Krupansky (JIRA)

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

Jack Krupansky commented on CASSANDRA-9435:
---

All of the doc references have a capital C in EC2 in the snitch class names, 
which the source code for the classes have as Ec2, with an uncapitalized c. 
Damn case-sensitivity!

For example,
http://docs.datastax.com/en/cassandra/2.1/cassandra/architecture/architectureSnitchesAbout_c.html
http://docs.datastax.com/en/cassandra/1.2/cassandra/architecture/architectureSnitchEC2_t.html

The EC2 multi-region snitch has the same issue.

 Documetation bug
 

 Key: CASSANDRA-9435
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9435
 Project: Cassandra
  Issue Type: Bug
  Components: Documentation  website
 Environment: Debian 7
Reporter: jincer
Priority: Minor
 Fix For: 2.1.5


 Hello, you have some inaccuracy at docs on your website. 
 When i try to change snitch from default to EC2Snitch (endpoint_snitch: 
 EC2Snitch) i have message, that  Unable to find snitch class 
 'org.apache.cassandra.locator.EC2Snitch'  .
 Only when i change endpoint_snitch: EC2Snitch to endpoint_snitch: 
 Ec2Snitch it has been started. 
 Thank you.



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


[jira] [Resolved] (CASSANDRA-9435) Documetation bug

2015-05-20 Thread Philip Thompson (JIRA)

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

Philip Thompson resolved CASSANDRA-9435.

Resolution: Invalid

This Jira should only be used for problems with the docs on the apache 
cassandra wiki. I've forwarded the issue to DataStax, however.

 Documetation bug
 

 Key: CASSANDRA-9435
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9435
 Project: Cassandra
  Issue Type: Bug
  Components: Documentation  website
 Environment: Debian 7
Reporter: jincer
Priority: Minor
 Fix For: 2.1.5


 Hello, you have some inaccuracy at docs on your website. 
 When i try to change snitch from default to EC2Snitch (endpoint_snitch: 
 EC2Snitch) i have message, that  Unable to find snitch class 
 'org.apache.cassandra.locator.EC2Snitch'  .
 Only when i change endpoint_snitch: EC2Snitch to endpoint_snitch: 
 Ec2Snitch it has been started. 
 Thank you.



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


[jira] [Commented] (CASSANDRA-9107) More accurate row count estimates

2015-05-20 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko commented on CASSANDRA-9107:
--

Go ahead.

 More accurate row count estimates
 -

 Key: CASSANDRA-9107
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9107
 Project: Cassandra
  Issue Type: Improvement
Reporter: Chris Lohfink
Assignee: Chris Lohfink
 Fix For: 2.1.x

 Attachments: 9107-cassandra2-1.patch, 9107-v2.txt


 Currently the estimated row count from cfstats is the sum of the number of 
 rows in all the sstables. This becomes very inaccurate with wide rows or 
 heavily updated datasets since the same partition would exist in many 
 sstables.  In example:
 {code}
 create KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
 'replication_factor': 1};
 create TABLE wide (key text PRIMARY KEY , value text) WITH compaction = 
 {'class': 'SizeTieredCompactionStrategy', 'min_threshold': 30, 
 'max_threshold': 100} ;
 ---
 insert INTO wide (key, value) VALUES ('key', 'value');
 // flush
 // cfstats output: Number of keys (estimate): 1  (128 in older version from 
 index)
 insert INTO wide (key, value) VALUES ('key', 'value');
 // flush
 // cfstats output: Number of keys (estimate): 2  (256 in older version from 
 index)
 ... etc
 {code}
 previously it used the index but it still did it per sstable and summed them 
 up which became inaccurate as there are more sstables (just by much worse). 
 With new versions of sstables we can merge the cardinalities to resolve this 
 with a slight hit to accuracy in the case of every sstable having completely 
 unique partitions.
 Furthermore I think it would be pretty minimal effort to include the number 
 of rows in the memtables to this count. We wont have the cardinality merging 
 between memtables and sstables but I would consider that a relatively minor 
 negative.



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


[jira] [Commented] (CASSANDRA-8103) Secondary Indices for Static Columns

2015-05-20 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-8103:
-

bq. I believe this is going to be a blocker for 3.0.

Well, not really. It's true that thrift {{KEYS}} index will look a lot like 
static column indexes post-CASSANDRA-8099, but there is details pertaining to 
thrift support that make {{KEYS}} index their own special case. In practice, 
the branch for CASSANDRA-8099 already has the code for {{KEYS}} index so this 
is not strictly speaking a blocker. It's probable however that the patch for 
this will be fairly similar to (and might even reuse most parts of) the 
{{KEYS}} index code (which is not big in the first place).


 Secondary Indices for Static Columns
 

 Key: CASSANDRA-8103
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8103
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Ron Cohen
Assignee: Sam Tunnicliffe
Priority: Blocker
 Fix For: 3.0 beta 1

 Attachments: in_progress.patch


 We should add secondary index support for static columns.  



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


[jira] [Updated] (CASSANDRA-8103) Secondary Indices for Static Columns

2015-05-20 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne updated CASSANDRA-8103:

Priority: Major  (was: Blocker)

 Secondary Indices for Static Columns
 

 Key: CASSANDRA-8103
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8103
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Ron Cohen
Assignee: Sam Tunnicliffe
 Fix For: 3.0 beta 1

 Attachments: in_progress.patch


 We should add secondary index support for static columns.  



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


[jira] [Commented] (CASSANDRA-8103) Secondary Indices for Static Columns

2015-05-20 Thread Sylvain Lebresne (JIRA)

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

Sylvain Lebresne commented on CASSANDRA-8103:
-

For the reason above, because I'm still not convinced this is in practice the 
most pressing thing ever, I've moved the fix version for this to '3.x'. And by 
that I mean that it's fine if it's ready for 3.0, but we shouldn't block 3.0 on 
that either.

 Secondary Indices for Static Columns
 

 Key: CASSANDRA-8103
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8103
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Ron Cohen
Assignee: Sam Tunnicliffe
 Fix For: 3.x

 Attachments: in_progress.patch


 We should add secondary index support for static columns.  



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


[3/3] cassandra git commit: Merge branch 'cassandra-2.2' into trunk

2015-05-20 Thread aleksey
Merge branch 'cassandra-2.2' into trunk


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

Branch: refs/heads/trunk
Commit: 418aefdd292242277635aed818a9097a7576abe0
Parents: 2e48b6a 76b5f30
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed May 20 20:03:32 2015 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 20:03:32 2015 +0300

--
 CHANGES.txt  | 2 ++
 src/java/org/apache/cassandra/db/RangeTombstone.java | 4 
 2 files changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/418aefdd/CHANGES.txt
--
diff --cc CHANGES.txt
index 1912372,281d10b..4ee25ab
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -6,7 -1,10 +6,9 @@@
  2.2
   * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
   * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
 - * Add ability to stop compaction by ID (CASSANDRA-7207)
  Merged from 2.1:
+ 2.1.6
+  * Optimize range tombstone memory footprint (CASSANDRA-8603)
   * Use configured gcgs in anticompaction (CASSANDRA-9397)
  
  



[1/3] cassandra git commit: Optimize range tombstone memory footprint

2015-05-20 Thread aleksey
Repository: cassandra
Updated Branches:
  refs/heads/trunk 2e48b6af9 - 418aefdd2


Optimize range tombstone memory footprint

patch by Benjamin Lerer; reviewed by Aleksey Yeschenko for
CASSANDRA-8603


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

Branch: refs/heads/trunk
Commit: 2248780eae46d98be8a9414d3e833fb6c16c7137
Parents: 7af9c6a
Author: blerer benjamin.le...@datastax.com
Authored: Tue May 19 16:12:53 2015 +0200
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 19:57:35 2015 +0300

--
 CHANGES.txt  | 1 +
 src/java/org/apache/cassandra/db/RangeTombstone.java | 4 
 2 files changed, 5 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2248780e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6fc1c9c..92d4d54 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.6
+ * Optimize range tombstone memory footprint (CASSANDRA-8603)
  * Use configured gcgs in anticompaction (CASSANDRA-9397)
  * Warn on misuse of unlogged batches (CASSANDRA-9282)
  * Failure detector detects and ignores local pauses (CASSANDRA-9183)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2248780e/src/java/org/apache/cassandra/db/RangeTombstone.java
--
diff --git a/src/java/org/apache/cassandra/db/RangeTombstone.java 
b/src/java/org/apache/cassandra/db/RangeTombstone.java
index 3f3d675..feeadbb 100644
--- a/src/java/org/apache/cassandra/db/RangeTombstone.java
+++ b/src/java/org/apache/cassandra/db/RangeTombstone.java
@@ -273,6 +273,10 @@ public class RangeTombstone extends IntervalComposite, 
DeletionTime implements
 {
 Composite max = type.serializer().deserialize(in);
 DeletionTime dt = DeletionTime.serializer.deserialize(in);
+// If the max equals the min.end(), we can avoid keeping an extra 
ByteBuffer in memory by using
+// min.end() instead of max
+Composite minEnd = min.end();
+max = minEnd.equals(max) ? minEnd : max;
 return new RangeTombstone(min, max, dt);
 }
 



[Cassandra Wiki] Update of ContributorsGroup by BrandonWilliams

2015-05-20 Thread Apache Wiki
Dear Wiki user,

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

The ContributorsGroup page has been changed by BrandonWilliams:
https://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=45rev2=46

   * KarlLehenbauer
   * wombat
   * AlicePorfirio
+  * SamTunnicliffe
  


[jira] [Updated] (CASSANDRA-9431) Static Analysis to warn on unsafe use of Autocloseable instances

2015-05-20 Thread T Jake Luciani (JIRA)

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

T Jake Luciani updated CASSANDRA-9431:
--
Fix Version/s: (was: 3.0 beta 1)
   2.2.0 rc1

 Static Analysis to warn on unsafe use of Autocloseable instances
 

 Key: CASSANDRA-9431
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9431
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Benedict
Assignee: T Jake Luciani
 Fix For: 2.2.0 rc1


 The ideal goal would be to fail the build under any unsafe (and not annotated 
 as considered safe independently) uses of Autocloseable. It looks as though 
 eclipse (and hence, hopefully ecj) has support for this feature, so we should 
 investigate if it meets our requirements and we can get it integrated



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


[2/3] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2015-05-20 Thread aleksey
Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/trunk
Commit: 76b5f30e73ec8bcef03e81a51181d2ee89c85360
Parents: 52dc63b 2248780
Author: Aleksey Yeschenko alek...@apache.org
Authored: Wed May 20 20:02:56 2015 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Wed May 20 20:02:56 2015 +0300

--
 CHANGES.txt  | 2 ++
 src/java/org/apache/cassandra/db/RangeTombstone.java | 4 
 2 files changed, 6 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/76b5f30e/CHANGES.txt
--
diff --cc CHANGES.txt
index 44f9e4c,92d4d54..281d10b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,127 -1,6 +1,129 @@@
 +2.2
 + * Ensure that UDF and UDAs are keyspace-isolated (CASSANDRA-9409)
 + * Revert CASSANDRA-7807 (tracing completion client notifications) 
(CASSANDRA-9429)
 + * Add ability to stop compaction by ID (CASSANDRA-7207)
 +Merged from 2.1:
+ 2.1.6
+  * Optimize range tombstone memory footprint (CASSANDRA-8603)
   * Use configured gcgs in anticompaction (CASSANDRA-9397)
 +
 +
 +2.2.0-beta1
 + * Introduce Transactional API for internal state changes (CASSANDRA-8984)
 + * Add a flag in cassandra.yaml to enable UDFs (CASSANDRA-9404)
 + * Better support of null for UDF (CASSANDRA-8374)
 + * Use ecj instead of javassist for UDFs (CASSANDRA-8241)
 + * faster async logback configuration for tests (CASSANDRA-9376)
 + * Add `smallint` and `tinyint` data types (CASSANDRA-8951)
 + * Avoid thrift schema creation when native driver is used in stress tool 
(CASSANDRA-9374)
 + * Populate TokenMetadata early during startup (CASSANDRA-9317)
 + * Make Functions.declared thread-safe
 + * Add client warnings to native protocol v4 (CASSANDRA-8930)
 + * Allow roles cache to be invalidated (CASSANDRA-8967)
 + * Upgrade Snappy (CASSANDRA-9063)
 + * Don't start Thrift rpc by default (CASSANDRA-9319)
 + * Only stream from unrepaired sstables with incremental repair 
(CASSANDRA-8267)
 + * Aggregate UDFs allow SFUNC return type to differ from STYPE if FFUNC 
specified (CASSANDRA-9321)
 + * Remove Thrift dependencies in bundled tools (CASSANDRA-8358)
 + * Disable memory mapping of hsperfdata file for JVM statistics 
(CASSANDRA-9242)
 + * Add pre-startup checks to detect potential incompatibilities 
(CASSANDRA-8049)
 + * Distinguish between null and unset in protocol v4 (CASSANDRA-7304)
 + * Add user/role permissions for user-defined functions (CASSANDRA-7557)
 + * Allow cassandra config to be updated to restart daemon without unloading 
classes (CASSANDRA-9046)
 + * Don't initialize compaction writer before checking if iter is empty 
(CASSANDRA-9117)
 + * Don't execute any functions at prepare-time (CASSANDRA-9037)
 + * Share file handles between all instances of a SegmentedFile 
(CASSANDRA-8893)
 + * Make it possible to major compact LCS (CASSANDRA-7272)
 + * Make FunctionExecutionException extend RequestExecutionException
 +   (CASSANDRA-9055)
 + * Add support for SELECT JSON, INSERT JSON syntax and new toJson(), 
fromJson()
 +   functions (CASSANDRA-7970)
 + * Optimise max purgeable timestamp calculation in compaction (CASSANDRA-8920)
 + * Constrain internode message buffer sizes, and improve IO class hierarchy 
(CASSANDRA-8670) 
 + * New tool added to validate all sstables in a node (CASSANDRA-5791)
 + * Push notification when tracing completes for an operation (CASSANDRA-7807)
 + * Delay node up and node added notifications until native protocol 
server is started (CASSANDRA-8236)
 + * Compressed Commit Log (CASSANDRA-6809)
 + * Optimise IntervalTree (CASSANDRA-8988)
 + * Add a key-value payload for third party usage (CASSANDRA-8553, 9212)
 + * Bump metrics-reporter-config dependency for metrics 3.0 (CASSANDRA-8149)
 + * Partition intra-cluster message streams by size, not type (CASSANDRA-8789)
 + * Add WriteFailureException to native protocol, notify coordinator of
 +   write failures (CASSANDRA-8592)
 + * Convert SequentialWriter to nio (CASSANDRA-8709)
 + * Add role based access control (CASSANDRA-7653, 8650, 7216, 8760, 8849, 
8761, 8850)
 + * Record client ip address in tracing sessions (CASSANDRA-8162)
 + * Indicate partition key columns in response metadata for prepared
 +   statements (CASSANDRA-7660)
 + * Merge UUIDType and TimeUUIDType parse logic (CASSANDRA-8759)
 + * Avoid memory allocation when searching index summary (CASSANDRA-8793)
 + * Optimise (Time)?UUIDType Comparisons (CASSANDRA-8730)
 + * Make CRC32Ex into a separate maven dependency (CASSANDRA-8836)
 + * Use 

[jira] [Updated] (CASSANDRA-7558) Document users and permissions in CQL docs

2015-05-20 Thread Jonathan Ellis (JIRA)

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

Jonathan Ellis updated CASSANDRA-7558:
--
Reviewer: Tyler Hobbs

 Document users and permissions in CQL docs
 --

 Key: CASSANDRA-7558
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7558
 Project: Cassandra
  Issue Type: Task
  Components: Documentation  website
Reporter: Tyler Hobbs
Assignee: Sam Tunnicliffe
Priority: Minor
 Fix For: 2.1.x, 2.0.x, 2.2.x

 Attachments: 7558-2.0.txt, 7558-2.2.txt


 The CQL3 docs don't cover {{CREATE USER}}, {{ALTER USER}}, {{DROP USER}}, 
 {{LIST USERS}}, {{GRANT}}, or {{REVOKE}}.



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


[jira] [Commented] (CASSANDRA-9443) UFTest UFIdentificationTest are failing in the CI environment

2015-05-20 Thread Ariel Weisberg (JIRA)

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

Ariel Weisberg commented on CASSANDRA-9443:
---

Is it consistent? Seems like they just fail periodically? In the last three 
builds they didn't fail.

 UFTest  UFIdentificationTest are failing in the CI environment
 ---

 Key: CASSANDRA-9443
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9443
 Project: Cassandra
  Issue Type: Test
  Components: Tests
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
 Fix For: 2.2.0 rc1


 These 2 tests are consistently timing out, but I'm so far unable to repro 
 locally.



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


[jira] [Commented] (CASSANDRA-8609) Remove depency of hadoop to internals (Cell/CellName)

2015-05-20 Thread Philip Thompson (JIRA)

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

Philip Thompson commented on CASSANDRA-8609:


Here are the CI results including the fix from CASSANDRA-9442. Once that is 
committed, you can review.

http://cassci.datastax.com/view/Dev/view/ptnapoleon/job/ptnapoleon-cassandra-8609-testall/lastCompletedBuild/testReport/

 Remove depency of hadoop to internals (Cell/CellName)
 -

 Key: CASSANDRA-8609
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8609
 Project: Cassandra
  Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Philip Thompson
 Fix For: 2.2.0 rc1

 Attachments: 8609-2.2.txt, CASSANDRA-8609-3.0-branch.txt


 For some reason most of the Hadoop code (ColumnFamilyRecordReader, 
 CqlStorage, ...) uses the {{Cell}} and {{CellName}} classes. That dependency 
 is entirely artificial: all this code is really client code that communicate 
 with Cassandra over thrift/native protocol and there is thus no reason for it 
 to use internal classes. And in fact, thoses classes are used in a very crude 
 way, as a {{PairByteBuffer, ByteBuffer}} really.
 But this dependency is really painful when we make changes to the internals. 
 Further, every time we do so, I believe we break some of those the APIs due 
 to the change. This has been painful for CASSANDRA-5417 and this is now 
 painful for CASSANDRA-8099. But while I somewhat hack over it in 
 CASSANDRA-5417, this was a mistake and we should have removed the depency 
 back then. So let do that now.



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


[jira] [Reopened] (CASSANDRA-9183) Failure detector should detect and ignore local pauses

2015-05-20 Thread sankalp kohli (JIRA)

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

sankalp kohli reopened CASSANDRA-9183:
--

 Failure detector should detect and ignore local pauses
 --

 Key: CASSANDRA-9183
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9183
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 2.2.0 beta 1, 2.1.6

 Attachments: 9183-v2.txt, 9183.txt


 A local node can be paused for many reasons such as GC, and if the pause is 
 long enough when it recovers it will think all the other nodes are dead until 
 it gossips, causing UAE to be thrown to clients trying to use it as a 
 coordinator.  Instead, the FD can track the current time, and if the gap 
 there becomes too large, skip marking the nodes down (reset the FD data 
 perhaps)



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


[jira] [Commented] (CASSANDRA-9183) Failure detector should detect and ignore local pauses

2015-05-20 Thread Brandon Williams (JIRA)

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

Brandon Williams commented on CASSANDRA-9183:
-

wasPaused was added simply to survive two rounds of interpret() on the same 
endpoint, but wasn't intended to cross endpoints at all.  That said, I think 
you're right and instead we'd have to do something like track it per-endpoint.  
Can you make a new ticket for this?

 Failure detector should detect and ignore local pauses
 --

 Key: CASSANDRA-9183
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9183
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Brandon Williams
Assignee: Brandon Williams
 Fix For: 2.2.0 beta 1, 2.1.6

 Attachments: 9183-v2.txt, 9183.txt


 A local node can be paused for many reasons such as GC, and if the pause is 
 long enough when it recovers it will think all the other nodes are dead until 
 it gossips, causing UAE to be thrown to clients trying to use it as a 
 coordinator.  Instead, the FD can track the current time, and if the gap 
 there becomes too large, skip marking the nodes down (reset the FD data 
 perhaps)



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


[jira] [Commented] (CASSANDRA-6477) Materialized Views (was: Global Indexes)

2015-05-20 Thread Carl Yeksigian (JIRA)

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

Carl Yeksigian commented on CASSANDRA-6477:
---

Pushed a [new branch|https://github.com/carlyeks/cassandra/tree/ticket/6477-3] 
which includes the materialized view syntax [~jbellis] proposed:

{code}
CREATE MATERIALIZED VIEW users_by_age AS
SELECT age, user_id, x, y, z FROM users
PRIMARY KEY (age, user_id)
{code}

The branch also includes the consistency updates proposed earlier in this 
ticket, as well as initial support for collection.

Main outstanding issues:
- When overloaded with inserts to a single partition key in the base, 
tombstones aren't always properly generated for the view; this inconsistency 
doesn't get corrected with more time since repair doesn't check view versus base
- An insert to a collection produces a range tombstone which isn't translated 
properly against the view; only range tombstones covering the whole row are 
handled

 Materialized Views (was: Global Indexes)
 

 Key: CASSANDRA-6477
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6477
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Jonathan Ellis
Assignee: Carl Yeksigian
  Labels: cql
 Fix For: 3.0 beta 1


 Local indexes are suitable for low-cardinality data, where spreading the 
 index across the cluster is a Good Thing.  However, for high-cardinality 
 data, local indexes require querying most nodes in the cluster even if only a 
 handful of rows is returned.



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


[jira] [Commented] (CASSANDRA-7486) Compare CMS and G1 pause times

2015-05-20 Thread Albert P Tobey (JIRA)

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

Albert P Tobey commented on CASSANDRA-7486:
---

I'll attach a patch ASAP.

 Compare CMS and G1 pause times
 --

 Key: CASSANDRA-7486
 URL: https://issues.apache.org/jira/browse/CASSANDRA-7486
 Project: Cassandra
  Issue Type: Test
  Components: Config
Reporter: Jonathan Ellis
Assignee: Albert P Tobey
 Fix For: 3.0 beta 1


 See 
 http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-7486gc-migration-to-expectations-and-advanced-tuning
  and https://twitter.com/rbranson/status/482113561431265281
 May want to default 2.1 to G1.
 2.1 is a different animal from 2.0 after moving most of memtables off heap.  
 Suspect this will help G1 even more than CMS.  (NB this is off by default but 
 needs to be part of the test.)



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


[jira] [Updated] (CASSANDRA-9409) Ensure that UDF and UDAs are keyspace-isolated

2015-05-20 Thread Alan Boudreault (JIRA)

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

Alan Boudreault updated CASSANDRA-9409:
---
Flags:   (was: Patch)

 Ensure that UDF and UDAs are keyspace-isolated
 --

 Key: CASSANDRA-9409
 URL: https://issues.apache.org/jira/browse/CASSANDRA-9409
 Project: Cassandra
  Issue Type: Bug
Reporter: Aleksey Yeschenko
Assignee: Alan Boudreault
  Labels: qa-resolved
 Fix For: 2.2.0 rc1

 Attachments: 9409-with-system.txt, 9409.txt


 In table columns we don't allow to use UDTs from other keyspaces.
 We should also make sure that the following is *not* allowed:
 - UDFs taking UDTs from other keyspaces as arguments or return types
 - UDAs using UDFs from other keyspaces as its subfunctions
 The only exception should be made for {{system}} keyspace. UDAs and UDFs from 
 any keyspace should be able to reference and reuse those.
 Having no dependencies between keyspaces makes this consistent with the way 
 we treat UDTs, which is important, but also simplifies auth in multi-tenant 
 environments, and is also crucial to upcoming 3.X strongly consistent schema 
 work (the ability to treat keyspace as a unit of change and not having to 
 worry about cross-keyspace dependencies).
 P.S. Should *probably* still allow using other keyspaces UDFs and UDAs in 
 {{SELECT}} statements. Strict isolation in schema dependencies is what 
 matters to me here.



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


  1   2   >