[jira] [Commented] (CASSANDRA-4096) mlockall() returned code is ignored w/o assertions

[Peter Schuller (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242017#comment-13242017
 ] 

Peter Schuller commented on CASSANDRA-4096:
---

Good point. If that's the behavior of JNA, then definitely +1.

> mlockall() returned code is ignored w/o assertions
> --
>
> Key: CASSANDRA-4096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4096
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Peter Schuller
>Assignee: Jonathan Ellis
>Priority: Minor
>  Labels: jna
> Attachments: 4096.txt
>
>
> We log that mlockall() was successful only based on the lack of an assertion 
> failure, so for anyone running w/o {{-ea}} we are lying about mlockall() 
> succeeding.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Vijay (Updated) (JIRA)]

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

Vijay updated CASSANDRA-4099:
-

Attachment: (was: 0001-CASSANDRA-4099-v4.patch)

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Fix For: 1.0.9, 1.1.0
>
> Attachments: 0001-CASSANDRA-4099-v2.patch, 
> 0001-CASSANDRA-4099-v3.patch, 0001-CASSANDRA-4099-v4.patch, 
> 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Vijay (Updated) (JIRA)]

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

Vijay updated CASSANDRA-4099:
-

Attachment: 0001-CASSANDRA-4099-v4.patch

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Fix For: 1.0.9, 1.1.0
>
> Attachments: 0001-CASSANDRA-4099-v2.patch, 
> 0001-CASSANDRA-4099-v3.patch, 0001-CASSANDRA-4099-v4.patch, 
> 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Vijay (Updated) (JIRA)]

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

Vijay updated CASSANDRA-4099:
-

Attachment: 0001-CASSANDRA-4099-v4.patch

v4 is on top of the v3 and it fixes the NPE

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Fix For: 1.0.9, 1.1.0
>
> Attachments: 0001-CASSANDRA-4099-v2.patch, 
> 0001-CASSANDRA-4099-v3.patch, 0001-CASSANDRA-4099-v4.patch, 
> 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Vijay (Reopened) (JIRA)]

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

Vijay reopened CASSANDRA-4099:
--


Looks like there is a case we will run into NPE when the other node which is 
sending a higher version we ignore it but the problem the msg object is not 
available.

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Fix For: 1.0.9, 1.1.0
>
> Attachments: 0001-CASSANDRA-4099-v2.patch, 
> 0001-CASSANDRA-4099-v3.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241943#comment-13241943
 ] 

paul cannon commented on CASSANDRA-4078:


Wenjun, are you able to tell from the UUID keys shown which ColumnFamily is 
having these troubles? I can't quite tell for sure from the logs. If necessary, 
we can add more asserts to identify the right place, but we can skip that step 
if you already know which one it is.

> StackOverflowError when upgrading to 1.0.8 from 0.8.10
> --
>
> Key: CASSANDRA-4078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.8.10
> Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
> May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
> Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
>Reporter: Wenjun
>Assignee: paul cannon
>Priority: Critical
> Fix For: 0.8.10
>
> Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
> cassandra.yaml.8.10, system.log, system.log.0326, system.log.0326-02
>
>
> Hello
> I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
> following exception when starting up 1.0.8.  We have been running 0.8.10 
> without any issues.
>  
> Attached is the entire log file during startup of 1.0.8.  There are 2 
> exceptions:
> 1. StackOverflowError (line 2599)
> 2. InstanceAlreadyExistsException (line 3632)
> I tried "run scrub" under 0.8.10 first, it did not help.  Also, I tried 
> dropping the column family which caused the exception, it just got the same 
> exceptions from another column family.
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: make ITC to handle versioning using BCA patch by Vijay; reviewed by Brandon Williams for CASSANDRA-4098

[vijay]

Updated Branches:
  refs/heads/trunk f0ea699e6 -> 3f7c7323b


make ITC to handle versioning using BCA
patch by Vijay; reviewed by Brandon Williams for CASSANDRA-4098

Conflicts:

src/java/org/apache/cassandra/net/IncomingTcpConnection.java


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

Branch: refs/heads/trunk
Commit: 3f7c7323b40e69fd6112735e922a298ed516df0e
Parents: f0ea699
Author: Vijay Parthasarathy 
Authored: Thu Mar 29 16:48:35 2012 -0700
Committer: Vijay Parthasarathy 
Committed: Thu Mar 29 16:48:35 2012 -0700

--
 .../cassandra/net/IncomingTcpConnection.java   |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f7c7323/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java 
b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
index dc8a698..d7a3de4 100644
--- a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
@@ -36,13 +36,12 @@ public class IncomingTcpConnection extends Thread
 private static final int CHUNK_SIZE = 1024 * 1024;
 
 private final Socket socket;
-public final InetAddress from;
+public InetAddress from;
 
 public IncomingTcpConnection(Socket socket)
 {
 assert socket != null;
 this.socket = socket;
-this.from = socket.getInetAddress(); // maximize chance of this not 
being nulled by disconnect
 }
 
 /**
@@ -88,6 +87,7 @@ public class IncomingTcpConnection extends Thread
 input = new DataInputStream(new 
BufferedInputStream(socket.getInputStream(), 4096));
 // Receive the first message to set the version.
 Message msg = receiveMessage(input, version);
+from = msg.getFrom(); // why? see => CASSANDRA-4099
 if (version > MessagingService.current_version)
 {
 // save the endpoint so gossip will reconnect to it
@@ -96,7 +96,7 @@ public class IncomingTcpConnection extends Thread
 }
 else if (msg != null)
 {
-Gossiper.instance.setVersion(msg.getFrom(), version);
+Gossiper.instance.setVersion(from, version);
 logger.debug("set version for {} to {}", from, version);
 }
 

git commit: make ITC to handle versioning using BCA patch by Vijay; reviewed by Brandon Williams for CASSANDRA-4098

[vijay]

Updated Branches:
  refs/heads/cassandra-1.0 b0dfb4cdc -> b85d44a25


make ITC to handle versioning using BCA
patch by Vijay; reviewed by Brandon Williams for CASSANDRA-4098


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

Branch: refs/heads/cassandra-1.0
Commit: b85d44a25bec8355a86288376eca17021b9793f2
Parents: b0dfb4c
Author: Vijay Parthasarathy 
Authored: Thu Mar 29 16:29:07 2012 -0700
Committer: Vijay Parthasarathy 
Committed: Thu Mar 29 16:29:07 2012 -0700

--
 .../cassandra/net/IncomingTcpConnection.java   |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b85d44a2/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java 
b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
index ee44a1c..47ab39a 100644
--- a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
@@ -48,7 +48,6 @@ public class IncomingTcpConnection extends Thread
 {
 assert socket != null;
 this.socket = socket;
-from = socket.getInetAddress(); // maximize chance of this not being 
nulled by disconnect
 }
 
 /**
@@ -94,6 +93,7 @@ public class IncomingTcpConnection extends Thread
 input = new DataInputStream(new 
BufferedInputStream(socket.getInputStream(), 4096));
 // Receive the first message to set the version.
 Message msg = receiveMessage(input, version);
+from = msg.getFrom(); // why? see => CASSANDRA-4099
 if (version > MessagingService.version_)
 {
 // save the endpoint so gossip will reconnect to it
@@ -102,7 +102,7 @@ public class IncomingTcpConnection extends Thread
 }
 else if (msg != null)
 {
-Gossiper.instance.setVersion(msg.getFrom(), version);
+Gossiper.instance.setVersion(from, version);
 logger.debug("set version for {} to {}", from, version);
 }
 

[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Pavel Yaskevich (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241913#comment-13241913
 ] 

Pavel Yaskevich commented on CASSANDRA-4093:


I like that more than adding "component_index" option which would be easily 
misconfigured and create a confusion. Right now we should change comparators of 
the schema_* CFs for that to work and add a check to the ThriftValidation and 
CQL validations to prevent users from setting CompositeType comparators to the 
new CFs along side with check when schema is converted to 1.1...

> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[paul cannon (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241872#comment-13241872
 ] 

paul cannon commented on CASSANDRA-4078:


Yeah, the problem is almost certainly either (a) some important difference in 
the way it's being used now versus the way it was used before, or (b) some sort 
of bug in 0.8.10. I don't think 1.0.8 or 1.1.0 are acting improperly given the 
data and configuration here; I'm just hoping I can help you sort out whatever 
datatype expectation mismatch or invalid sstables you have.

> StackOverflowError when upgrading to 1.0.8 from 0.8.10
> --
>
> Key: CASSANDRA-4078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.8.10
> Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
> May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
> Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
>Reporter: Wenjun
>Assignee: paul cannon
>Priority: Critical
> Fix For: 0.8.10
>
> Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
> cassandra.yaml.8.10, system.log, system.log.0326, system.log.0326-02
>
>
> Hello
> I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
> following exception when starting up 1.0.8.  We have been running 0.8.10 
> without any issues.
>  
> Attached is the entire log file during startup of 1.0.8.  There are 2 
> exceptions:
> 1. StackOverflowError (line 2599)
> 2. InstanceAlreadyExistsException (line 3632)
> I tried "run scrub" under 0.8.10 first, it did not help.  Also, I tried 
> dropping the column family which caused the exception, it just got the same 
> exceptions from another column family.
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize > free memory

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241821#comment-13241821
 ] 

Jonathan Ellis commented on CASSANDRA-4104:
---

Also note that stdout + stderr get logged to /var/log/cassandra/output.log when 
run normally by the debian packaging.  Not sure about the RH packages.

> Cassandra appears to hang when JNA enabled and heapsize > free memory
> -
>
> Key: CASSANDRA-4104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.0.8
>Reporter: Joaquin Casares
>Priority: Minor
>  Labels: datastax_qa
>
> When JNA is enabled heapsize is larger than free memory, all that is printed 
> out is the classpath, then the printouts stop.
> If you hit enter again, you get the commandline, but no Cassandra process is 
> running.
> Tested on both OpenJDK and Oracle Java.
> {noformat}
> datastax@datastax-image:~/repos/cassandra$ free -m
>  total   used   free sharedbuffers cached
> Mem:  2008740   1267  0  3 54
> -/+ buffers/cache:682   1326
> Swap:0  0  0
> datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
> datastax@datastax-image:~/repos/cassandra$  INFO 14:31:32,520 Logging 
> initialized
>  INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server 
> VM/1.6.0_31
>  INFO 14:31:32,534 Heap size: 1247805440/1247805440
>  INFO 14:31:32,534 Classpath: 
> bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
> datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
> datastax 18374  1.0  0.0  13448   904 pts/2S+   14:32   0:00 grep 
> --color=auto cass
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize > free memory

[Joaquin Casares (Resolved) (JIRA)]

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

Joaquin Casares resolved CASSANDRA-4104.


Resolution: Not A Problem

With cassandra -f printing out the error, this is acceptable behavior.

> Cassandra appears to hang when JNA enabled and heapsize > free memory
> -
>
> Key: CASSANDRA-4104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.0.8
>Reporter: Joaquin Casares
>Priority: Minor
>  Labels: datastax_qa
>
> When JNA is enabled heapsize is larger than free memory, all that is printed 
> out is the classpath, then the printouts stop.
> If you hit enter again, you get the commandline, but no Cassandra process is 
> running.
> Tested on both OpenJDK and Oracle Java.
> {noformat}
> datastax@datastax-image:~/repos/cassandra$ free -m
>  total   used   free sharedbuffers cached
> Mem:  2008740   1267  0  3 54
> -/+ buffers/cache:682   1326
> Swap:0  0  0
> datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
> datastax@datastax-image:~/repos/cassandra$  INFO 14:31:32,520 Logging 
> initialized
>  INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server 
> VM/1.6.0_31
>  INFO 14:31:32,534 Heap size: 1247805440/1247805440
>  INFO 14:31:32,534 Classpath: 
> bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
> datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
> datastax 18374  1.0  0.0  13448   904 pts/2S+   14:32   0:00 grep 
> --color=auto cass
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241786#comment-13241786
 ] 

Jonathan Ellis commented on CASSANDRA-4093:
---

I think we'll regret the precedent in trying to preserve all the arbitrarily 
complex things you could do with the old CFMetadata.  It really doesn't make 
sense to have a CompositeType as a column name.  Given that, and given that 
CFMetadata names under <= 1.0 were only useful for validation (and indexes, but 
we don't index CTs yet either), I'd rather say "we don't support that in 1.1+, 
and if you were doing that, drop the column definition before you upgrade."

Optionally, we could auto-drop it for them and log a warning.

> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10

[Wenjun (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241613#comment-13241613
 ] 

Wenjun commented on CASSANDRA-4078:
---

Paul, 

so you know: I just tried 1.1.0-beta2 and seeing the same error.

> StackOverflowError when upgrading to 1.0.8 from 0.8.10
> --
>
> Key: CASSANDRA-4078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4078
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 0.8.10
> Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue 
> May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux
> Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31
>Reporter: Wenjun
>Assignee: paul cannon
>Priority: Critical
> Fix For: 0.8.10
>
> Attachments: 4078.add-asserts.txt, cassandra.yaml.1.0.8, 
> cassandra.yaml.8.10, system.log, system.log.0326, system.log.0326-02
>
>
> Hello
> I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the 
> following exception when starting up 1.0.8.  We have been running 0.8.10 
> without any issues.
>  
> Attached is the entire log file during startup of 1.0.8.  There are 2 
> exceptions:
> 1. StackOverflowError (line 2599)
> 2. InstanceAlreadyExistsException (line 3632)
> I tried "run scrub" under 0.8.10 first, it did not help.  Also, I tried 
> dropping the column family which caused the exception, it just got the same 
> exceptions from another column family.
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize > free memory

[Brandon Williams (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241598#comment-13241598
 ] 

Brandon Williams commented on CASSANDRA-4104:
-

Also, it's not hanging nor exiting without telling you what's wrong, you just 
aren't running it in foreground mode:

{noformat}
# bin/cassandra -f
Error occurred during initialization of VM
Could not reserve enough space for object heap
{noformat}

> Cassandra appears to hang when JNA enabled and heapsize > free memory
> -
>
> Key: CASSANDRA-4104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.0.8
>Reporter: Joaquin Casares
>Priority: Minor
>  Labels: datastax_qa
>
> When JNA is enabled heapsize is larger than free memory, all that is printed 
> out is the classpath, then the printouts stop.
> If you hit enter again, you get the commandline, but no Cassandra process is 
> running.
> Tested on both OpenJDK and Oracle Java.
> {noformat}
> datastax@datastax-image:~/repos/cassandra$ free -m
>  total   used   free sharedbuffers cached
> Mem:  2008740   1267  0  3 54
> -/+ buffers/cache:682   1326
> Swap:0  0  0
> datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
> datastax@datastax-image:~/repos/cassandra$  INFO 14:31:32,520 Logging 
> initialized
>  INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server 
> VM/1.6.0_31
>  INFO 14:31:32,534 Heap size: 1247805440/1247805440
>  INFO 14:31:32,534 Classpath: 
> bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
> datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
> datastax 18374  1.0  0.0  13448   904 pts/2S+   14:32   0:00 grep 
> --color=auto cass
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Pavel Yaskevich (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241587#comment-13241587
 ] 

Pavel Yaskevich commented on CASSANDRA-4093:


I confirm that CLI works as expected with the patch but I'm not sure that 
adding new option to the ColumnDef especially because users can simply ignore 
it without even given it a thought. Feels like we are adding complexity from 
pure air...

> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3647) Support arbitrarily nested "documents" in CQL

[Jeremiah Jordan (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241562#comment-13241562
 ] 

Jeremiah Jordan commented on CASSANDRA-3647:


For the maps/lists/sets, are you talking about a standard way of using 
composite columns to implement them, or, a new column type that has a 
map/list/set inside one column, and new operations to work with them?  Similar 
to counters?

I think this Issue started about having a standard way for CQL to store 
document attributes in multiple columns using multiple columns and composites 
with slices to get/set them.

So if you want to make a standard way of setting up composite columns for 
maps/lists/sets, I think this issue can be hi-jacked for that.  If you want to 
add a new type of column that supports redis like map/set/list operations, I 
would make a new issue.

> Support arbitrarily nested "documents" in CQL
> -
>
> Key: CASSANDRA-3647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
> Project: Cassandra
>  Issue Type: New Feature
>  Components: API, Core
>Reporter: Jonathan Ellis
>  Labels: cql
>
> Composite columns introduce the ability to have arbitrarily nested data in a 
> Cassandra row.  We should expose this through CQL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize > free memory

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241558#comment-13241558
 ] 

Jonathan Ellis commented on CASSANDRA-4104:
---

Well, that's what you'd expect right?  mlockall says "Thou shalt pin the heap 
in memory and not swap it out."

I suppose it would be better if mlockall errored out with "I can't let you do 
that, Dave," but fixing that isn't in-scope for us.

> Cassandra appears to hang when JNA enabled and heapsize > free memory
> -
>
> Key: CASSANDRA-4104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.0.8
>Reporter: Joaquin Casares
>Priority: Minor
>  Labels: datastax_qa
>
> When JNA is enabled heapsize is larger than free memory, all that is printed 
> out is the classpath, then the printouts stop.
> If you hit enter again, you get the commandline, but no Cassandra process is 
> running.
> Tested on both OpenJDK and Oracle Java.
> {noformat}
> datastax@datastax-image:~/repos/cassandra$ free -m
>  total   used   free sharedbuffers cached
> Mem:  2008740   1267  0  3 54
> -/+ buffers/cache:682   1326
> Swap:0  0  0
> datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
> datastax@datastax-image:~/repos/cassandra$  INFO 14:31:32,520 Logging 
> initialized
>  INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server 
> VM/1.6.0_31
>  INFO 14:31:32,534 Heap size: 1247805440/1247805440
>  INFO 14:31:32,534 Classpath: 
> bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
> datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
> datastax 18374  1.0  0.0  13448   904 pts/2S+   14:32   0:00 grep 
> --color=auto cass
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Sylvain Lebresne (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241559#comment-13241559
 ] 

Sylvain Lebresne commented on CASSANDRA-4093:
-

bq. given that you can't do that with the cli

Yes you can. What the cli doesn't support is the new-in-1.1 way of interpreting 
ColumnDefinition for CF having a composite comparator as refering to the last 
component. It is perfectly possible in pre-1.1 to have a composite comparator 
and declare a ColumnDefinition. What I'm saying is that currently (i.e without 
the attached patch), 1.1 breaks compatibility with pre-1.1 for that use case, 
which is a bad thing.

> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize > free memory

[Joaquin Casares (Created) (JIRA)]

Cassandra appears to hang when JNA enabled and heapsize > free memory
-

 Key: CASSANDRA-4104
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.0.8
Reporter: Joaquin Casares
Priority: Minor


When JNA is enabled heapsize is larger than free memory, all that is printed 
out is the classpath, then the printouts stop.

If you hit enter again, you get the commandline, but no Cassandra process is 
running.

Tested on both OpenJDK and Oracle Java.

{noformat}
datastax@datastax-image:~/repos/cassandra$ free -m
 total   used   free sharedbuffers cached
Mem:  2008740   1267  0  3 54
-/+ buffers/cache:682   1326
Swap:0  0  0
datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
datastax@datastax-image:~/repos/cassandra$  INFO 14:31:32,520 Logging 
initialized
 INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server 
VM/1.6.0_31
 INFO 14:31:32,534 Heap size: 1247805440/1247805440
 INFO 14:31:32,534 Classpath: 
bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar

datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
datastax 18374  1.0  0.0  13448   904 pts/2S+   14:32   0:00 grep 
--color=auto cass

{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3911) Basic QoS support for helping reduce OOMing cluster

[Harish Doddi (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241543#comment-13241543
 ] 

Harish Doddi commented on CASSANDRA-3911:
-

Comments from brandon through IRC 
==

1. Move all the qos validations to Thrift validator class possibly.

2. Have validation on cql side (QP validation)

3. Possible renaming of "QoS" to something else.

> Basic QoS support for helping reduce OOMing cluster
> ---
>
> Key: CASSANDRA-3911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3911
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Chris Goffinet
>Assignee: Harish Doddi
>Priority: Minor
> Fix For: 1.2
>
> Attachments: CASSANDRA-3911-trunk.txt
>
>
> We'd like to propose adding some basic QoS features to Cassandra. There can 
> be a lot to be done here but for v1 to keep things less invasive, and still 
> provide basics we would like to contribute the following features and see if 
> the community thinks this is OK.
> We would set these on server (cassandra.yaml). If threshold is crossed, we 
> throw an exception up to the client.
> 1) Limit how many rows a client can fetch over RPC through multi-get.
> 2) Limit how many columns may be returned (if count > N) throw exception 
> before processing.
> 3) Limit how many rows and columns a client can try to batch mutate.
> This can be added in our Thrift logic, before any processing can be done. The 
> big reason why we want to do this, is so that customers don't shoot 
> themselves in the foot, by making mistakes or not knowing how many columns 
> they might have returned.
> We can build logic like this into a basic client, but I propose one of the 
> features we might want in Cassandra is support for not being able to OOM a 
> node. We've done lots of work around memtable flushing, dropping messages, 
> etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241527#comment-13241527
 ] 

Jonathan Ellis commented on CASSANDRA-4093:
---

bq. I'm not sure how many people use composite comparators and have 
ColumnDefinition on them, but we probably shouldn't assume nobody does that

given that you can't do that with the cli (as shown here) I think that's 
actually a pretty safe assumption.

> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Sylvain Lebresne (Updated) (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-4093:


Attachment: 4093.txt

So the problem is the following: for CQL3, we've introduced the fact that when 
we have a composite comparator, the 'name' of a ColumnDefinition refers to the 
last component of the composite comparator. In other words, one should use the 
last comparator of the composite comparator to parse the ColumnDefinition name, 
but the CLI doesn't know that. So we do need to fix the CLI.

However, now that I think about this, I realize we may have been a little bit 
careless when doing that, because the current code basically *assumes* that if 
you have a composite comparator, then ColumnDefinition refers to the last 
component of those. That may break compatibility for user using composite type 
today. I'm not sure how many people use composite comparators *and* have 
ColumnDefinition on them, but we probably shouldn't assume nobody does that.

So I think to fix that we need to add a new information to ColumnDefinition, 
which if the comparator of the CF is a composite type, to which component the 
definition apply (or if it apply to the column name as a whole). Attached a 
patch that does just that. I'll note that while we could probably do with a 
boolean in that case (since currently we only have 2 cases: either the 
definition apply to the full column name or it applies to the last component), 
but the full generality of specifying which component exactly the definition 
apply to will likely be useful if we allow defining secondary index of other 
parts of the composite (CASSANDRA-3680). Note that the patch does fix the CLI 
following that change.


> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4095) Internal error processing get_slice (NullPointerException)

[Vijay (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241510#comment-13241510
 ] 

Vijay commented on CASSANDRA-4095:
--

+1

> Internal error processing get_slice (NullPointerException)
> --
>
> Key: CASSANDRA-4095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4095
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.2
> Environment: Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
>Reporter: John Laban
>Assignee: Jonathan Ellis
>Priority: Minor
> Fix For: 1.0.9, 1.1.0
>
> Attachments: 4095.txt
>
>
> I get this pretty regularly.  It seems to happen transiently on multiple 
> nodes in my cluster, every so often, and goes away.
> ERROR [Thrift:45] 2012-03-26 19:59:12,024 Cassandra.java (line 3041) Internal 
> error processing get_slice
> java.lang.NullPointerException
> at 
> org.apache.cassandra.db.SliceFromReadCommand.maybeGenerateRetryCommand(SliceFromReadCommand.java:76)
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:724)
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:564)
> at 
> org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:128)
> at 
> org.apache.cassandra.thrift.CassandraServer.getSlice(CassandraServer.java:283)
> at 
> org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:365)
> at 
> org.apache.cassandra.thrift.CassandraServer.get_slice(CassandraServer.java:326)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$get_slice.process(Cassandra.java:3033)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
> at 
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> The line in question is (I think) the one below, so it looks like the column 
> family reference for a row can sometimes be null?
> int liveColumnsInRow = row != null ? row.cf.getLiveColumnCount() : 0;
> Here is my column family (on 1.0.8):
> ColumnFamily: WorkQueue (Super)
>   Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>   Default column value validator: org.apache.cassandra.db.marshal.UTF8Type
>   Columns sorted by: 
> org.apache.cassandra.db.marshal.UTF8Type/org.apache.cassandra.db.marshal.UTF8Type
>   Row cache size / save period in seconds / keys to save : 0.0/0/all
>   Row Cache Provider: 
> org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider
>   Key cache size / save period in seconds: 0.0/0
>   GC grace seconds: 0
>   Compaction min/max thresholds: 4/32
>   Read repair chance: 0.0
>   Replicate on write: false
>   Bloom Filter FP chance: default
>   Built indexes: []
>   Compaction Strategy: 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241509#comment-13241509
 ] 

Jonathan Ellis commented on CASSANDRA-4093:
---

No, because when you have column aliases the name in the metadata is a "leaf" 
name, it's not supposed to be a full composite name. In other words,

composite name = (alias name, metadata name)

> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3911) Basic QoS support for helping reduce OOMing cluster

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241507#comment-13241507
 ] 

Jonathan Ellis commented on CASSANDRA-3911:
---

I'm not a huge fan of this approach in general, but we're already doing 
something similar with thrift frame size.  So I guess I'm okay with it.

We should probably stick to just the read side though, since the write side 
*is* already covered by said frame size.  (I suppose you could make that a 
double, if MB is not granular enough.)

Finally, would prefer to just see settings for read_rows and read_columns 
(read_columns_per_row?), rather than a two-tier system of Master Switch *and* 
individual settings.

> Basic QoS support for helping reduce OOMing cluster
> ---
>
> Key: CASSANDRA-3911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3911
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Chris Goffinet
>Assignee: Harish Doddi
>Priority: Minor
> Fix For: 1.2
>
> Attachments: CASSANDRA-3911-trunk.txt
>
>
> We'd like to propose adding some basic QoS features to Cassandra. There can 
> be a lot to be done here but for v1 to keep things less invasive, and still 
> provide basics we would like to contribute the following features and see if 
> the community thinks this is OK.
> We would set these on server (cassandra.yaml). If threshold is crossed, we 
> throw an exception up to the client.
> 1) Limit how many rows a client can fetch over RPC through multi-get.
> 2) Limit how many columns may be returned (if count > N) throw exception 
> before processing.
> 3) Limit how many rows and columns a client can try to batch mutate.
> This can be added in our Thrift logic, before any processing can be done. The 
> big reason why we want to do this, is so that customers don't shoot 
> themselves in the foot, by making mistakes or not knowing how many columns 
> they might have returned.
> We can build logic like this into a basic client, but I propose one of the 
> features we might want in Cassandra is support for not being able to OOM a 
> node. We've done lots of work around memtable flushing, dropping messages, 
> etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241505#comment-13241505
 ] 

Jonathan Ellis commented on CASSANDRA-4099:
---

+1 on v3 for 1.0+

I'm fine w/ continuing to ignore version on streaming for now

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 
> 0001-CASSANDRA-4099-v3.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4095) Internal error processing get_slice (NullPointerException)

[Jonathan Ellis (Updated) (JIRA)]

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

Jonathan Ellis updated CASSANDRA-4095:
--

Affects Version/s: (was: 1.0.8)
   1.0.2
Fix Version/s: 1.1.0
   1.0.9

> Internal error processing get_slice (NullPointerException)
> --
>
> Key: CASSANDRA-4095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4095
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.2
> Environment: Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
>Reporter: John Laban
>Assignee: Jonathan Ellis
>Priority: Minor
> Fix For: 1.0.9, 1.1.0
>
> Attachments: 4095.txt
>
>
> I get this pretty regularly.  It seems to happen transiently on multiple 
> nodes in my cluster, every so often, and goes away.
> ERROR [Thrift:45] 2012-03-26 19:59:12,024 Cassandra.java (line 3041) Internal 
> error processing get_slice
> java.lang.NullPointerException
> at 
> org.apache.cassandra.db.SliceFromReadCommand.maybeGenerateRetryCommand(SliceFromReadCommand.java:76)
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:724)
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:564)
> at 
> org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:128)
> at 
> org.apache.cassandra.thrift.CassandraServer.getSlice(CassandraServer.java:283)
> at 
> org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:365)
> at 
> org.apache.cassandra.thrift.CassandraServer.get_slice(CassandraServer.java:326)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$get_slice.process(Cassandra.java:3033)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
> at 
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> The line in question is (I think) the one below, so it looks like the column 
> family reference for a row can sometimes be null?
> int liveColumnsInRow = row != null ? row.cf.getLiveColumnCount() : 0;
> Here is my column family (on 1.0.8):
> ColumnFamily: WorkQueue (Super)
>   Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>   Default column value validator: org.apache.cassandra.db.marshal.UTF8Type
>   Columns sorted by: 
> org.apache.cassandra.db.marshal.UTF8Type/org.apache.cassandra.db.marshal.UTF8Type
>   Row cache size / save period in seconds / keys to save : 0.0/0/all
>   Row Cache Provider: 
> org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider
>   Key cache size / save period in seconds: 0.0/0
>   GC grace seconds: 0
>   Compaction min/max thresholds: 4/32
>   Read repair chance: 0.0
>   Replicate on write: false
>   Bloom Filter FP chance: default
>   Built indexes: []
>   Compaction Strategy: 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4095) Internal error processing get_slice (NullPointerException)

[Jonathan Ellis (Updated) (JIRA)]

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

Jonathan Ellis updated CASSANDRA-4095:
--

Attachment: 4095.txt

Thanks for the report, John.  I think your analysis is spot on.  Patch attached 
that does not assume row.cf is non-null.

> Internal error processing get_slice (NullPointerException)
> --
>
> Key: CASSANDRA-4095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4095
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.8
> Environment: Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
>Reporter: John Laban
>Priority: Minor
> Attachments: 4095.txt
>
>
> I get this pretty regularly.  It seems to happen transiently on multiple 
> nodes in my cluster, every so often, and goes away.
> ERROR [Thrift:45] 2012-03-26 19:59:12,024 Cassandra.java (line 3041) Internal 
> error processing get_slice
> java.lang.NullPointerException
> at 
> org.apache.cassandra.db.SliceFromReadCommand.maybeGenerateRetryCommand(SliceFromReadCommand.java:76)
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:724)
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:564)
> at 
> org.apache.cassandra.thrift.CassandraServer.readColumnFamily(CassandraServer.java:128)
> at 
> org.apache.cassandra.thrift.CassandraServer.getSlice(CassandraServer.java:283)
> at 
> org.apache.cassandra.thrift.CassandraServer.multigetSliceInternal(CassandraServer.java:365)
> at 
> org.apache.cassandra.thrift.CassandraServer.get_slice(CassandraServer.java:326)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$get_slice.process(Cassandra.java:3033)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
> at 
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> The line in question is (I think) the one below, so it looks like the column 
> family reference for a row can sometimes be null?
> int liveColumnsInRow = row != null ? row.cf.getLiveColumnCount() : 0;
> Here is my column family (on 1.0.8):
> ColumnFamily: WorkQueue (Super)
>   Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
>   Default column value validator: org.apache.cassandra.db.marshal.UTF8Type
>   Columns sorted by: 
> org.apache.cassandra.db.marshal.UTF8Type/org.apache.cassandra.db.marshal.UTF8Type
>   Row cache size / save period in seconds / keys to save : 0.0/0/all
>   Row Cache Provider: 
> org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider
>   Key cache size / save period in seconds: 0.0/0
>   GC grace seconds: 0
>   Compaction min/max thresholds: 4/32
>   Read repair chance: 0.0
>   Replicate on write: false
>   Bloom Filter FP chance: default
>   Built indexes: []
>   Compaction Strategy: 
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Pavel Yaskevich (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241503#comment-13241503
 ] 

Pavel Yaskevich commented on CASSANDRA-4093:


I don't get it, if the column names in column_metadata were not serialized 
using given CF comparator shouldn't we fix that instead of changing CLI?

> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3911) Basic QoS support for helping reduce OOMing cluster

[Brandon Williams (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241502#comment-13241502
 ] 

Brandon Williams commented on CASSANDRA-3911:
-

First off, this is setting result limits, more than quality of service, since 
we aren't [de]prioritizing anything, so I don't think QoS is the right term to 
be using here.

Secondly, I don't think this patch satisfies the goal of "Limit how many 
columns may be returned (if count > N) throw exception before processing" since 
the server actually does the processing, then limits what it will return, which 
only saves a copy in thrift.  You can still request all 2B columns in a row and 
OOM the server.

> Basic QoS support for helping reduce OOMing cluster
> ---
>
> Key: CASSANDRA-3911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3911
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Chris Goffinet
>Assignee: Harish Doddi
>Priority: Minor
> Fix For: 1.2
>
> Attachments: CASSANDRA-3911-trunk.txt
>
>
> We'd like to propose adding some basic QoS features to Cassandra. There can 
> be a lot to be done here but for v1 to keep things less invasive, and still 
> provide basics we would like to contribute the following features and see if 
> the community thinks this is OK.
> We would set these on server (cassandra.yaml). If threshold is crossed, we 
> throw an exception up to the client.
> 1) Limit how many rows a client can fetch over RPC through multi-get.
> 2) Limit how many columns may be returned (if count > N) throw exception 
> before processing.
> 3) Limit how many rows and columns a client can try to batch mutate.
> This can be added in our Thrift logic, before any processing can be done. The 
> big reason why we want to do this, is so that customers don't shoot 
> themselves in the foot, by making mistakes or not knowing how many columns 
> they might have returned.
> We can build logic like this into a basic client, but I propose one of the 
> features we might want in Cassandra is support for not being able to OOM a 
> node. We've done lots of work around memtable flushing, dropping messages, 
> etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Vijay (Updated) (JIRA)]

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

Vijay updated CASSANDRA-4099:
-

Attachment: 0001-CASSANDRA-4099-v3.patch

Attached version incorporate's the comments... Note that the streaming a file 
will not remove or add the version, which i think is a better option IMHO. Plz 
let me know if you think otherwise. Thanks!

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 
> 0001-CASSANDRA-4099-v3.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241495#comment-13241495
 ] 

Jonathan Ellis commented on CASSANDRA-4093:
---

Hmm, I'm pretty sure that giving CFMetdata column names a composite type header 
is the wrong solution. I think instead we need to teach cliclient that when you 
have a composite type comparator, you need to look at column aliases as well as 
column names to form the composite in question.

> schema_* CFs do not respect column comparator which leads to CLI commands 
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize 
> schema_* CFs column_metadata do not respect CF comparator and use 
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and 
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
>   at java.nio.Buffer.limit(Buffer.java:247)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
>   at 
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
>   at 
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
>   at 
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
>   at 
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Brandon Williams (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241484#comment-13241484
 ] 

Brandon Williams commented on CASSANDRA-4099:
-

I agree, we should get out of the habit of examining sockets directly due to 
broadcast_address.

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241480#comment-13241480
 ] 

Jonathan Ellis commented on CASSANDRA-4099:
---

I see.

Looking at the usages of ITC.from, it looks like we can drop that constructor 
initialization entirely...

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Brandon Williams (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241474#comment-13241474
 ] 

Brandon Williams commented on CASSANDRA-4099:
-

It overrides where from is set in the constructor:

{code}
this.from = socket.getInetAddress();
{code}

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: Fix underscores

[brandonwilliams]

Updated Branches:
  refs/heads/cassandra-1.1 190e27bb5 -> 33f66e4fb


Fix underscores


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

Branch: refs/heads/cassandra-1.1
Commit: 33f66e4fb13b17be08c368424aac07f532bdbab8
Parents: 190e27b
Author: Brandon Williams 
Authored: Thu Mar 29 13:16:21 2012 -0500
Committer: Brandon Williams 
Committed: Thu Mar 29 13:16:21 2012 -0500

--
 .../org/apache/cassandra/gms/FailureDetector.java  |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/33f66e4f/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java 
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index 0a66cb6..2f03e8c 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -197,10 +197,10 @@ public class FailureDetector implements IFailureDetector, 
FailureDetectorMBean
 
 public void forceConviction(InetAddress ep)
 {
-logger.debug("Forcing conviction of {}", ep);
-for ( IFailureDetectionEventListener listener : fdEvntListeners )
+logger_.debug("Forcing conviction of {}", ep);
+for ( IFailureDetectionEventListener listener : fdEvntListeners_ )
 {
-listener.convict(ep, phiConvictThreshold);
+listener.convict(ep, phiConvictThreshold_);
 }
 }
 

[jira] [Commented] (CASSANDRA-4101) Gossip should propagate MessagingService.version

[Brandon Williams (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241462#comment-13241462
 ] 

Brandon Williams commented on CASSANDRA-4101:
-

For people using broadcast address, there is no BCA->local address mapping kept 
by nodes, so changing the version stored in Gossiper's map is difficult, since 
you have the version stored as one and not the other.

> Gossip should propagate MessagingService.version
> 
>
> Key: CASSANDRA-4101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4101
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: 4101.txt
>
>
> In CASSANDRA-4099 it's becoming apparent that it's time to fix our hacky 
> versioning tricks we've used to remain backward-compatible.  As a first step, 
> let's communicate the version via gossip so we can eventually reason based on 
> that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4096) mlockall() returned code is ignored w/o assertions

[Jonathan Ellis (Updated) (JIRA)]

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

Jonathan Ellis updated CASSANDRA-4096:
--

Reviewer: scode
Priority: Minor  (was: Major)
Assignee: Jonathan Ellis
  Labels: jna  (was: )

> mlockall() returned code is ignored w/o assertions
> --
>
> Key: CASSANDRA-4096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4096
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Peter Schuller
>Assignee: Jonathan Ellis
>Priority: Minor
>  Labels: jna
> Attachments: 4096.txt
>
>
> We log that mlockall() was successful only based on the lack of an assertion 
> failure, so for anyone running w/o {{-ea}} we are lying about mlockall() 
> succeeding.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4096) mlockall() returned code is ignored w/o assertions

[Jonathan Ellis (Updated) (JIRA)]

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

Jonathan Ellis updated CASSANDRA-4096:
--

Attachment: 4096.txt

The assert is redundant anyway since JNA will check return value and errno for 
us. Patch attached.

> mlockall() returned code is ignored w/o assertions
> --
>
> Key: CASSANDRA-4096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4096
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Peter Schuller
>  Labels: jna
> Attachments: 4096.txt
>
>
> We log that mlockall() was successful only based on the lack of an assertion 
> failure, so for anyone running w/o {{-ea}} we are lying about mlockall() 
> succeeding.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[brandonwilliams]

Updated Branches:
  refs/heads/cassandra-1.1 27c999a11 -> 190e27bb5
  refs/heads/trunk 27e322b63 -> f0ea699e6


Merge branch 'cassandra-1.1' into trunk


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

Branch: refs/heads/trunk
Commit: f0ea699e62d498c1d5c647cf78f016e360a236d4
Parents: 27e322b 190e27b
Author: Brandon Williams 
Authored: Thu Mar 29 13:07:39 2012 -0500
Committer: Brandon Williams 
Committed: Thu Mar 29 13:07:39 2012 -0500

--
 .../org/apache/cassandra/gms/FailureDetector.java  |9 ++
 .../cassandra/gms/GossipShutdownMessage.java   |   63 +++
 .../cassandra/gms/GossipShutdownVerbHandler.java   |   42 ++
 src/java/org/apache/cassandra/gms/Gossiper.java|   50 +++-
 .../org/apache/cassandra/gms/IFailureDetector.java |5 +
 .../apache/cassandra/service/StorageService.java   |3 +
 .../org/apache/cassandra/dht/BootStrapperTest.java |1 +
 7 files changed, 171 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0ea699e/src/java/org/apache/cassandra/gms/FailureDetector.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0ea699e/src/java/org/apache/cassandra/gms/Gossiper.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0ea699e/src/java/org/apache/cassandra/gms/IFailureDetector.java
--

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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0ea699e/test/unit/org/apache/cassandra/dht/BootStrapperTest.java
--

[2/3] git commit: Broadcast shutdown message when cleanly stopping gossip. Patch by brandonwilliams, reviewed by vijay for CASSANDRA-3936

[brandonwilliams]

Broadcast shutdown message when cleanly stopping gossip.
Patch by brandonwilliams, reviewed by vijay for CASSANDRA-3936


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

Branch: refs/heads/trunk
Commit: 190e27bb5cc910d020b3828c1fbe83f009534b89
Parents: 27c999a
Author: Brandon Williams 
Authored: Thu Mar 29 13:03:41 2012 -0500
Committer: Brandon Williams 
Committed: Thu Mar 29 13:03:41 2012 -0500

--
 .../org/apache/cassandra/gms/FailureDetector.java  |9 ++
 .../cassandra/gms/GossipShutdownMessage.java   |   63 +++
 .../cassandra/gms/GossipShutdownVerbHandler.java   |   42 ++
 src/java/org/apache/cassandra/gms/Gossiper.java|   50 +++-
 .../org/apache/cassandra/gms/IFailureDetector.java |5 +
 .../apache/cassandra/service/StorageService.java   |3 +
 .../org/apache/cassandra/dht/BootStrapperTest.java |1 +
 7 files changed, 171 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/190e27bb/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java 
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index c8ba43a..0a66cb6 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -195,6 +195,15 @@ public class FailureDetector implements IFailureDetector, 
FailureDetectorMBean
 }
 }
 
+public void forceConviction(InetAddress ep)
+{
+logger.debug("Forcing conviction of {}", ep);
+for ( IFailureDetectionEventListener listener : fdEvntListeners )
+{
+listener.convict(ep, phiConvictThreshold);
+}
+}
+
 public void remove(InetAddress ep)
 {
 arrivalSamples_.remove(ep);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/190e27bb/src/java/org/apache/cassandra/gms/GossipShutdownMessage.java
--
diff --git a/src/java/org/apache/cassandra/gms/GossipShutdownMessage.java 
b/src/java/org/apache/cassandra/gms/GossipShutdownMessage.java
new file mode 100644
index 000..3122986
--- /dev/null
+++ b/src/java/org/apache/cassandra/gms/GossipShutdownMessage.java
@@ -0,0 +1,63 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.gms;
+
+import org.apache.cassandra.io.IVersionedSerializer;
+
+import java.io.DataInput;
+import java.io.DataOutput;
+import java.io.IOException;
+
+/**
+ * This message indicates the gossiper is shutting down
+ */
+
+class GossipShutdownMessage
+{
+private static final IVersionedSerializer 
serializer;
+static
+{
+serializer = new GossipShutdownMessageSerializer();
+}
+
+static IVersionedSerializer serializer()
+{
+return serializer;
+}
+
+GossipShutdownMessage()
+{
+}
+}
+
+class GossipShutdownMessageSerializer implements 
IVersionedSerializer
+{
+public void serialize(GossipShutdownMessage gShutdownMessage, DataOutput 
dos, int version) throws IOException
+{
+}
+
+public GossipShutdownMessage deserialize(DataInput dis, int version) 
throws IOException
+{
+return new GossipShutdownMessage();
+}
+
+public long serializedSize(GossipShutdownMessage gossipShutdownMessage, 
int version)
+{
+throw new UnsupportedOperationException();
+}
+}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/cassandra/blob/190e27bb/src/java/org/apache/cassandra/gms/GossipShutdownVerbHandler.java
--
diff --git a/src/java/org/apache/cassandra/gms/GossipShutdownVerbHandler.java 
b/src/java/org/apache/cassandra/gms/GossipShutdownVerbHandler.java
new fil

[3/3] git commit: Broadcast shutdown message when cleanly stopping gossip. Patch by brandonwilliams, reviewed by vijay for CASSANDRA-3936

[brandonwilliams]

Broadcast shutdown message when cleanly stopping gossip.
Patch by brandonwilliams, reviewed by vijay for CASSANDRA-3936


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

Branch: refs/heads/cassandra-1.1
Commit: 190e27bb5cc910d020b3828c1fbe83f009534b89
Parents: 27c999a
Author: Brandon Williams 
Authored: Thu Mar 29 13:03:41 2012 -0500
Committer: Brandon Williams 
Committed: Thu Mar 29 13:03:41 2012 -0500

--
 .../org/apache/cassandra/gms/FailureDetector.java  |9 ++
 .../cassandra/gms/GossipShutdownMessage.java   |   63 +++
 .../cassandra/gms/GossipShutdownVerbHandler.java   |   42 ++
 src/java/org/apache/cassandra/gms/Gossiper.java|   50 +++-
 .../org/apache/cassandra/gms/IFailureDetector.java |5 +
 .../apache/cassandra/service/StorageService.java   |3 +
 .../org/apache/cassandra/dht/BootStrapperTest.java |1 +
 7 files changed, 171 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/190e27bb/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java 
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index c8ba43a..0a66cb6 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -195,6 +195,15 @@ public class FailureDetector implements IFailureDetector, 
FailureDetectorMBean
 }
 }
 
+public void forceConviction(InetAddress ep)
+{
+logger.debug("Forcing conviction of {}", ep);
+for ( IFailureDetectionEventListener listener : fdEvntListeners )
+{
+listener.convict(ep, phiConvictThreshold);
+}
+}
+
 public void remove(InetAddress ep)
 {
 arrivalSamples_.remove(ep);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/190e27bb/src/java/org/apache/cassandra/gms/GossipShutdownMessage.java
--
diff --git a/src/java/org/apache/cassandra/gms/GossipShutdownMessage.java 
b/src/java/org/apache/cassandra/gms/GossipShutdownMessage.java
new file mode 100644
index 000..3122986
--- /dev/null
+++ b/src/java/org/apache/cassandra/gms/GossipShutdownMessage.java
@@ -0,0 +1,63 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.gms;
+
+import org.apache.cassandra.io.IVersionedSerializer;
+
+import java.io.DataInput;
+import java.io.DataOutput;
+import java.io.IOException;
+
+/**
+ * This message indicates the gossiper is shutting down
+ */
+
+class GossipShutdownMessage
+{
+private static final IVersionedSerializer 
serializer;
+static
+{
+serializer = new GossipShutdownMessageSerializer();
+}
+
+static IVersionedSerializer serializer()
+{
+return serializer;
+}
+
+GossipShutdownMessage()
+{
+}
+}
+
+class GossipShutdownMessageSerializer implements 
IVersionedSerializer
+{
+public void serialize(GossipShutdownMessage gShutdownMessage, DataOutput 
dos, int version) throws IOException
+{
+}
+
+public GossipShutdownMessage deserialize(DataInput dis, int version) 
throws IOException
+{
+return new GossipShutdownMessage();
+}
+
+public long serializedSize(GossipShutdownMessage gossipShutdownMessage, 
int version)
+{
+throw new UnsupportedOperationException();
+}
+}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/cassandra/blob/190e27bb/src/java/org/apache/cassandra/gms/GossipShutdownVerbHandler.java
--
diff --git a/src/java/org/apache/cassandra/gms/GossipShutdownVerbHandler.java 
b/src/java/org/apache/cassandra/gms/GossipShutdownVerbHandler.java

[jira] [Updated] (CASSANDRA-4098) Listing wide-rows from CLI crashes Cassandra

[Jonathan Ellis (Updated) (JIRA)]

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

Jonathan Ellis updated CASSANDRA-4098:
--

Component/s: Tools
Description: 
If a user attempts to list a column family from the CLI that contains a 
wide-row (e.g. 10 million columns).  It crashes hangs the CLI and then 
Cassandra eventually crashes with an OoM.  We should introduce a default limit 
on columns when listing a column family.

(patch on its way)

  was:

If a user attempts to list a column family from the CLI that contains a 
wide-row (e.g. 10 million columns).  It crashes hangs the CLI and then 
Cassandra eventually crashes with an OoM.  We should introduce a default limit 
on columns when listing a column family.

(patch on its way)

   Priority: Minor  (was: Major)
   Assignee: Brian ONeill

What version did we add the column limit code in?

> Listing wide-rows from CLI crashes Cassandra 
> -
>
> Key: CASSANDRA-4098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4098
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Brian ONeill
>Assignee: Brian ONeill
>Priority: Minor
> Attachments: test_data.cl, trunk-4098.txt
>
>
> If a user attempts to list a column family from the CLI that contains a 
> wide-row (e.g. 10 million columns).  It crashes hangs the CLI and then 
> Cassandra eventually crashes with an OoM.  We should introduce a default 
> limit on columns when listing a column family.
> (patch on its way)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241440#comment-13241440
 ] 

Jonathan Ellis commented on CASSANDRA-4099:
---

I still don't get it.

{noformat}
+from = msg.getFrom(); // why? see => CASSANDRA-4099
-Gossiper.instance.setVersion(msg.getFrom(), version);
+Gossiper.instance.setVersion(from, version);
{noformat}

How is the first getFrom, not the same as the one we've de-inlined?

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4103) Add stress tool to binaries

[Vijay (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241433#comment-13241433
 ] 

Vijay commented on CASSANDRA-4103:
--

Sure will do, I will integrate the builds files.

> Add stress tool to binaries
> ---
>
> Key: CASSANDRA-4103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4103
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Rick Branson
>Assignee: Vijay
>Priority: Minor
>
> It would be great to also get the stress tool packaged along with the 
> binaries. Many people don't even know it exists because it's not distributed 
> with them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

[paul cannon (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241430#comment-13241430
 ] 

paul cannon commented on CASSANDRA-3990:


Cool. Do you think it's worth having an extra shortcut-y parameter like {{\-3}} 
or {{\-\-cql3}} instead of {{--cqlversion=3.0.0}}?

> cqlsh support for CQL 3
> ---
>
> Key: CASSANDRA-3990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: API
>Reporter: Sylvain Lebresne
>Assignee: Eric Evans
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt
>
>
> Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
> choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3281) Add an AbstractType anytype which stores meta data on a per column basis

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241431#comment-13241431
 ] 

Jonathan Ellis commented on CASSANDRA-3281:
---

I really think we should have client libraries break blobs up into native C* 
fields, rather than creating a pseudo-supercolumn construct (with even more 
disadvantages).  Having admitted our mistake with supercolumns (see 
CASSANDRA-3237) I'm not thrilled with the idea of adding something similar back.

> Add an AbstractType anytype which stores meta data on a per column basis
> 
>
> Key: CASSANDRA-3281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3281
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Edward Capriolo
>Priority: Minor
>
> A pet project of mine is an AbstractType for Cassandra that stores metadata 
> of the type in the column. https://github.com/edwardcapriolo/Cassandra-AnyType
> I described my use case any my design decisions here. 
> https://github.com/edwardcapriolo/Cassandra-AnyType/blob/master/README . The 
> biggest cases were needing to support null and '' as keys, column names, and 
> column values, however I also think the technique used to serialize Java 
> Objects as JSON but compare as a Java object is novel. 
> Side node: (The AbstractType interface has changed multiple times between 
> 0.6.X, 0.7.X, and 1.0.0-beta. I hope it stabilizes! ) 
> If people would like AnyType (or parts of it ) incorporated into Cassandra 
> that would be great. I am willing to tweak change it based on other peoples 
> ideas.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4101) Gossip should propagate MessagingService.version

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241426#comment-13241426
 ] 

Jonathan Ellis commented on CASSANDRA-4101:
---

How is getting it over gossip an improvement over getting it over every 
connection?

> Gossip should propagate MessagingService.version
> 
>
> Key: CASSANDRA-4101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4101
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: 4101.txt
>
>
> In CASSANDRA-4099 it's becoming apparent that it's time to fix our hacky 
> versioning tricks we've used to remain backward-compatible.  As a first step, 
> let's communicate the version via gossip so we can eventually reason based on 
> that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-4103) Add stress tool to binaries

[Jonathan Ellis (Assigned) (JIRA)]

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

Jonathan Ellis reassigned CASSANDRA-4103:
-

Assignee: Vijay

Vijay, is this something you could punch out?

> Add stress tool to binaries
> ---
>
> Key: CASSANDRA-4103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4103
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Rick Branson
>Assignee: Vijay
>Priority: Minor
>
> It would be great to also get the stress tool packaged along with the 
> binaries. Many people don't even know it exists because it's not distributed 
> with them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3647) Support arbitrarily nested "documents" in CQL

[Jonathan Ellis (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241424#comment-13241424
 ] 

Jonathan Ellis commented on CASSANDRA-3647:
---

If by "this feature" you mean the full document support in the title, you could 
be right.

If you mean the list and map types I propopsed, I disagree on both counts.  
It's very useful for us to be able to denormalize maps or lists into a field, 
instead of doing a client-side join.  The reason I want this fully supported 
instead of just a glorified blob is to do efficient updates (appends/pops for 
lists, insert/deletes for maps).

My quick googling suggests that postgresql gives you array_to_json and 
row_to_json, which is fine as far as it goes but doesn't accomplish the above.  
(Note that with their array type, pg comes close to what I have in mind for the 
list type here.)

If it would be less confusing to move "add map and list types" to a separate 
ticket, that's fine.

> Support arbitrarily nested "documents" in CQL
> -
>
> Key: CASSANDRA-3647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
> Project: Cassandra
>  Issue Type: New Feature
>  Components: API, Core
>Reporter: Jonathan Ellis
>  Labels: cql
>
> Composite columns introduce the ability to have arbitrarily nested data in a 
> Cassandra row.  We should expose this through CQL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-3776) Streaming task hangs forever during repair after unexpected connection reset by peer

[Jonathan Ellis (Resolved) (JIRA)]

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

Jonathan Ellis resolved CASSANDRA-3776.
---

   Resolution: Duplicate
Fix Version/s: (was: 1.0.9)
 Assignee: (was: Yuki Morishita)

WFM, marking duplicate.

> Streaming task hangs forever during repair after unexpected connection reset 
> by peer
> 
>
> Key: CASSANDRA-3776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3776
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.7
> Environment: Windows Server 2008 R2
> Sun Java 7u2 64bit
>Reporter: Viktor Jevdokimov
>Priority: Minor
>
> During streaming (repair) a stream receiving node thrown an exceptions:
> ERROR [Streaming:1] 2012-01-24 10:17:03,828 AbstractCassandraDaemon.java 
> (line 139) Fatal exception in thread Thread[Streaming:1,1,main]
> java.lang.RuntimeException: java.net.SocketException: Connection reset by 
> peer: socket write error
>   at 
> org.apache.cassandra.utils.FBUtilities.unchecked(FBUtilities.java:689)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.net.SocketException: Connection reset by peer: socket write 
> error
>   at java.net.SocketOutputStream.socketWrite0(Native Method)
>   at java.net.SocketOutputStream.socketWrite(Unknown Source)
>   at java.net.SocketOutputStream.write(Unknown Source)
>   at 
> com.ning.compress.lzf.LZFChunk.writeCompressedHeader(LZFChunk.java:77)
>   at 
> com.ning.compress.lzf.ChunkEncoder.encodeAndWriteChunk(ChunkEncoder.java:132)
>   at 
> com.ning.compress.lzf.LZFOutputStream.writeCompressedBlock(LZFOutputStream.java:203)
>   at com.ning.compress.lzf.LZFOutputStream.write(LZFOutputStream.java:97)
>   at 
> org.apache.cassandra.streaming.FileStreamTask.write(FileStreamTask.java:181)
>   at 
> org.apache.cassandra.streaming.FileStreamTask.stream(FileStreamTask.java:145)
>   at 
> org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   ... 3 more
> ERROR [Streaming:1] 2012-01-24 10:17:03,891 AbstractCassandraDaemon.java 
> (line 139) Fatal exception in thread Thread[Streaming:1,1,main]
> java.lang.RuntimeException: java.net.SocketException: Connection reset by 
> peer: socket write error
>   at 
> org.apache.cassandra.utils.FBUtilities.unchecked(FBUtilities.java:689)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.net.SocketException: Connection reset by peer: socket write 
> error
>   at java.net.SocketOutputStream.socketWrite0(Native Method)
>   at java.net.SocketOutputStream.socketWrite(Unknown Source)
>   at java.net.SocketOutputStream.write(Unknown Source)
>   at 
> com.ning.compress.lzf.LZFChunk.writeCompressedHeader(LZFChunk.java:77)
>   at 
> com.ning.compress.lzf.ChunkEncoder.encodeAndWriteChunk(ChunkEncoder.java:132)
>   at 
> com.ning.compress.lzf.LZFOutputStream.writeCompressedBlock(LZFOutputStream.java:203)
>   at com.ning.compress.lzf.LZFOutputStream.write(LZFOutputStream.java:97)
>   at 
> org.apache.cassandra.streaming.FileStreamTask.write(FileStreamTask.java:181)
>   at 
> org.apache.cassandra.streaming.FileStreamTask.stream(FileStreamTask.java:145)
>   at 
> org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>   ... 3 more
> After which streaming hanged forever.
> A few seconds later the sending node had an exception (may not be related):
> ERROR [Thread-17224] 2012-01-24 10:17:07,817 AbstractCassandraDaemon.java 
> (line 139) Fatal exception in thread Thread[Thread-17224,5,main]
> java.lang.ArrayIndexOutOfBoundsException
> Other than that, nodes behave normally, communicating each other.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3936) Gossip should have a 'goodbye' command to indicate shutdown

[Vijay (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241416#comment-13241416
 ] 

Vijay commented on CASSANDRA-3936:
--

+1

> Gossip should have a 'goodbye' command to indicate shutdown
> ---
>
> Key: CASSANDRA-3936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3936
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Brandon Williams
> Fix For: 1.2
>
> Attachments: 3936.txt
>
>
> Cassandra is crash-only, however there are times when you _know_ you are 
> taking the node down (rolling restarts, for instance) where it would be 
> advantageous to instantly have the node marked down rather than wait on the 
> FD.  We could also improve the efficacy of the 'disablegossip' command this 
> way as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3911) Basic QoS support for helping reduce OOMing cluster

[Jonathan Ellis (Updated) (JIRA)]

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

Jonathan Ellis updated CASSANDRA-3911:
--

Reviewer: brandon.williams

> Basic QoS support for helping reduce OOMing cluster
> ---
>
> Key: CASSANDRA-3911
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3911
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Chris Goffinet
>Assignee: Harish Doddi
>Priority: Minor
> Fix For: 1.2
>
> Attachments: CASSANDRA-3911-trunk.txt
>
>
> We'd like to propose adding some basic QoS features to Cassandra. There can 
> be a lot to be done here but for v1 to keep things less invasive, and still 
> provide basics we would like to contribute the following features and see if 
> the community thinks this is OK.
> We would set these on server (cassandra.yaml). If threshold is crossed, we 
> throw an exception up to the client.
> 1) Limit how many rows a client can fetch over RPC through multi-get.
> 2) Limit how many columns may be returned (if count > N) throw exception 
> before processing.
> 3) Limit how many rows and columns a client can try to batch mutate.
> This can be added in our Thrift logic, before any processing can be done. The 
> big reason why we want to do this, is so that customers don't shoot 
> themselves in the foot, by making mistakes or not knowing how many columns 
> they might have returned.
> We can build logic like this into a basic client, but I propose one of the 
> features we might want in Cassandra is support for not being able to OOM a 
> node. We've done lots of work around memtable flushing, dropping messages, 
> etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (CASSANDRA-4097) Classes in org.apache.cassandra.deps:avro:1.4.0-cassandra-1 clash with core Avro classes

[Jonathan Ellis (Issue Comment Edited) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241412#comment-13241412
 ] 

Jonathan Ellis edited comment on CASSANDRA-4097 at 3/29/12 5:35 PM:


{{ls lib/*avro*}}

  was (Author: jbellis):
ls lib/*avro*
  
> Classes in org.apache.cassandra.deps:avro:1.4.0-cassandra-1 clash with core 
> Avro classes
> 
>
> Key: CASSANDRA-4097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4097
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 0.7.0
>Reporter: Andrew Swan
>Priority: Minor
>
> Cassandra has this dependency:
> {code:title=build.xml}...
>  version="1.4.0-cassandra-1">
> ...{code}
> Unfortunately this JAR file contains classes in the {{org.apache.avro}} 
> package that are incompatible with classes of the same fully-qualified name 
> in the current release of Avro. For example, the inner class 
> {{org.apache.avro.Schema$Parser}} found in Avro 1.6.1 is missing from the 
> Cassandra version of that class. This makes it impossible to have both 
> Cassandra and the latest Avro version on the classpath (my use case is an 
> application that embeds Cassandra but also uses Avro 1.6.1 for unrelated 
> serialization purposes). A simple and risk-free solution would be to change 
> the package declaration of Cassandra's Avro classes from {{org.apache.avro}} 
> to (say) {{org.apache.cassandra.avro}}, assuming that the above dependency is 
> only used by Cassandra and no other projects (which seems a reasonable 
> assumption given its name).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4097) Classes in org.apache.cassandra.deps:avro:1.4.0-cassandra-1 clash with core Avro classes

[Jonathan Ellis (Updated) (JIRA)]

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

Jonathan Ellis updated CASSANDRA-4097:
--

 Priority: Minor  (was: Major)
Affects Version/s: (was: 1.0.8)
   0.7.0

ls lib/*avro*

> Classes in org.apache.cassandra.deps:avro:1.4.0-cassandra-1 clash with core 
> Avro classes
> 
>
> Key: CASSANDRA-4097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4097
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 0.7.0
>Reporter: Andrew Swan
>Priority: Minor
>
> Cassandra has this dependency:
> {code:title=build.xml}...
>  version="1.4.0-cassandra-1">
> ...{code}
> Unfortunately this JAR file contains classes in the {{org.apache.avro}} 
> package that are incompatible with classes of the same fully-qualified name 
> in the current release of Avro. For example, the inner class 
> {{org.apache.avro.Schema$Parser}} found in Avro 1.6.1 is missing from the 
> Cassandra version of that class. This makes it impossible to have both 
> Cassandra and the latest Avro version on the classpath (my use case is an 
> application that embeds Cassandra but also uses Avro 1.6.1 for unrelated 
> serialization purposes). A simple and risk-free solution would be to change 
> the package declaration of Cassandra's Avro classes from {{org.apache.avro}} 
> to (say) {{org.apache.cassandra.avro}}, assuming that the above dependency is 
> only used by Cassandra and no other projects (which seems a reasonable 
> assumption given its name).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3990) cqlsh support for CQL 3

[Sylvain Lebresne (Updated) (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-3990:


Reviewer: thepaul
Assignee: Eric Evans  (was: paul cannon)

> cqlsh support for CQL 3
> ---
>
> Key: CASSANDRA-3990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: API
>Reporter: Sylvain Lebresne
>Assignee: Eric Evans
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt
>
>
> Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
> choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3990) cqlsh support for CQL 3

[Eric Evans (Updated) (JIRA)]

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

Eric Evans updated CASSANDRA-3990:
--

Attachment: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt

> cqlsh support for CQL 3
> ---
>
> Key: CASSANDRA-3990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: API
>Reporter: Sylvain Lebresne
>Assignee: paul cannon
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt
>
>
> Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
> choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Brandon Williams (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241351#comment-13241351
 ] 

Brandon Williams commented on CASSANDRA-4099:
-

I see, it's injecting another getFrom call.  +1 (though this version only 
applies to trunk)

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Vijay (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241305#comment-13241305
 ] 

Vijay commented on CASSANDRA-4099:
--

getFrom gets the IP from the message header and the message header is set by 
the caller, which uses FB.BCA and the receiving machine sets it. Plz look at  
Message.getInternalReply for example. Thanks!

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3281) Add an AbstractType anytype which stores meta data on a per column basis

[Jeremiah Jordan (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241280#comment-13241280
 ] 

Jeremiah Jordan commented on CASSANDRA-3281:



bq. Using a seq scan? Or does it actually pull fields out of the PB?

>From what I can tell it actually pulls the fields out of the PB to index them. 
> If we could do this for ProtoBuff/Thrift/JSON/BSON what ever, basically say 
>index Column.Attribute instead of just index Column, and be able to index 
>multiple attributes of a column.  Index Column.Attribute1, 
>Column.Attribute2...  You can get the same thing by using composite columns 
>and breaking your data up to put it into Cassandra, but it would be nice if 
>you could store your blob whole and have Cassandra index it.

> Add an AbstractType anytype which stores meta data on a per column basis
> 
>
> Key: CASSANDRA-3281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3281
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Edward Capriolo
>Priority: Minor
>
> A pet project of mine is an AbstractType for Cassandra that stores metadata 
> of the type in the column. https://github.com/edwardcapriolo/Cassandra-AnyType
> I described my use case any my design decisions here. 
> https://github.com/edwardcapriolo/Cassandra-AnyType/blob/master/README . The 
> biggest cases were needing to support null and '' as keys, column names, and 
> column values, however I also think the technique used to serialize Java 
> Objects as JSON but compare as a Java object is novel. 
> Side node: (The AbstractType interface has changed multiple times between 
> 0.6.X, 0.7.X, and 1.0.0-beta. I hope it stabilizes! ) 
> If people would like AnyType (or parts of it ) incorporated into Cassandra 
> that would be great. I am willing to tweak change it based on other peoples 
> ideas.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4101) Gossip should propagate MessagingService.version

[Brandon Williams (Updated) (JIRA)]

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

Brandon Williams updated CASSANDRA-4101:


Reviewer: vijay2...@yahoo.com

> Gossip should propagate MessagingService.version
> 
>
> Key: CASSANDRA-4101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4101
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: 4101.txt
>
>
> In CASSANDRA-4099 it's becoming apparent that it's time to fix our hacky 
> versioning tricks we've used to remain backward-compatible.  As a first step, 
> let's communicate the version via gossip so we can eventually reason based on 
> that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-4101) Gossip should propagate MessagingService.version

[Brandon Williams (Assigned) (JIRA)]

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

Brandon Williams reassigned CASSANDRA-4101:
---

Assignee: Brandon Williams

> Gossip should propagate MessagingService.version
> 
>
> Key: CASSANDRA-4101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4101
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: 4101.txt
>
>
> In CASSANDRA-4099 it's becoming apparent that it's time to fix our hacky 
> versioning tricks we've used to remain backward-compatible.  As a first step, 
> let's communicate the version via gossip so we can eventually reason based on 
> that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4101) Gossip should propagate MessagingService.version

[Brandon Williams (Updated) (JIRA)]

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

Brandon Williams updated CASSANDRA-4101:


Attachment: 4101.txt

> Gossip should propagate MessagingService.version
> 
>
> Key: CASSANDRA-4101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4101
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: 4101.txt
>
>
> In CASSANDRA-4099 it's becoming apparent that it's time to fix our hacky 
> versioning tricks we've used to remain backward-compatible.  As a first step, 
> let's communicate the version via gossip so we can eventually reason based on 
> that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[2/4] git commit: Merge branch 'cassandra-1.1.0' into cassandra-1.1

[slebresne]

Merge branch 'cassandra-1.1.0' into cassandra-1.1


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

Branch: refs/heads/trunk
Commit: 27c999a11730c2cad39caa30ce57248f27e93232
Parents: 899ec8f e05a327
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:33:35 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:33:35 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 .../cassandra/cql3/statements/DeleteStatement.java |1 -
 3 files changed, 5 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/27c999a1/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/27c999a1/src/java/org/apache/cassandra/cql/DeleteStatement.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/27c999a1/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
--

[3/4] git commit: Merge branch 'cassandra-1.0' into cassandra-1.1.0

[slebresne]

Merge branch 'cassandra-1.0' into cassandra-1.1.0

Conflicts:
src/java/org/apache/cassandra/cql/DeleteStatement.java


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

Branch: refs/heads/trunk
Commit: e05a327e2cbbbc508bd53dee813de894faf6a272
Parents: 68032e9 b0dfb4c
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:32:52 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:32:52 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 .../cassandra/cql3/statements/DeleteStatement.java |1 -
 3 files changed, 5 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e05a327e/CHANGES.txt
--
diff --cc CHANGES.txt
index ae2b0f1,e4d207c..55d17f7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -47,96 -13,9 +47,97 @@@ Merged from 1.0
   * fix race leading to super columns assertion failure (CASSANDRA-3957)
   * ensure that directory is selected for compaction for user-defined
 tasks and upgradesstables (CASSANDRA-3985)
+  * fix NPE on invalid CQL delete command (CASSANDRA-3755)
  
  
 +1.1-beta1
 + * (cqlsh)
 +   + add SOURCE and CAPTURE commands, and --file option (CASSANDRA-3479)
 +   + add ALTER COLUMNFAMILY WITH (CASSANDRA-3523)
 +   + bundle Python dependencies with Cassandra (CASSANDRA-3507)
 +   + added to Debian package (CASSANDRA-3458)
 +   + display byte data instead of erroring out on decode failure 
 + (CASSANDRA-3874)
 + * add nodetool rebuild_index (CASSANDRA-3583)
 + * add nodetool rangekeysample (CASSANDRA-2917)
 + * Fix streaming too much data during move operations (CASSANDRA-3639)
 + * Nodetool and CLI connect to localhost by default (CASSANDRA-3568)
 + * Reduce memory used by primary index sample (CASSANDRA-3743)
 + * (Hadoop) separate input/output configurations (CASSANDRA-3197, 3765)
 + * avoid returning internal Cassandra classes over JMX (CASSANDRA-2805)
 + * add row-level isolation via SnapTree (CASSANDRA-2893)
 + * Optimize key count estimation when opening sstable on startup
 +   (CASSANDRA-2988)
 + * multi-dc replication optimization supporting CL > ONE (CASSANDRA-3577)
 + * add command to stop compactions (CASSANDRA-1740, 3566, 3582)
 + * multithreaded streaming (CASSANDRA-3494)
 + * removed in-tree redhat spec (CASSANDRA-3567)
 + * "defragment" rows for name-based queries under STCS, again (CASSANDRA-2503)
 + * Recycle commitlog segments for improved performance 
 +   (CASSANDRA-3411, 3543, 3557, 3615)
 + * update size-tiered compaction to prioritize small tiers (CASSANDRA-2407)
 + * add message expiration logic to OutboundTcpConnection (CASSANDRA-3005)
 + * off-heap cache to use sun.misc.Unsafe instead of JNA (CASSANDRA-3271)
 + * EACH_QUORUM is only supported for writes (CASSANDRA-3272)
 + * replace compactionlock use in schema migration by checking CFS.isValid
 +   (CASSANDRA-3116)
 + * recognize that "SELECT first ... *" isn't really "SELECT *" 
(CASSANDRA-3445)
 + * Use faster bytes comparison (CASSANDRA-3434)
 + * Bulk loader is no longer a fat client, (HADOOP) bulk load output format
 +   (CASSANDRA-3045)
 + * (Hadoop) add support for KeyRange.filter
 + * remove assumption that keys and token are in bijection
 +   (CASSANDRA-1034, 3574, 3604)
 + * always remove endpoints from delevery queue in HH (CASSANDRA-3546)
 + * fix race between cf flush and its 2ndary indexes flush (CASSANDRA-3547)
 + * fix potential race in AES when a repair fails (CASSANDRA-3548)
 + * Remove columns shadowed by a deleted container even when we cannot purge
 +   (CASSANDRA-3538)
 + * Improve memtable slice iteration performance (CASSANDRA-3545)
 + * more efficient allocation of small bloom filters (CASSANDRA-3618)
 + * Use separate writer thread in SSTableSimpleUnsortedWriter (CASSANDRA-3619)
 + * fsync the directory after new sstable or commitlog segment are created 
(CASSANDRA-3250)
 + * fix minor issues reported by FindBugs (CASSANDRA-3658)
 + * global key/row caches (CASSANDRA-3143, 3849)
 + * optimize memtable iteration during range scan (CASSANDRA-3638)
 + * introduce 'crc_check_chance' in CompressionParameters to support
 +   a checksum percentage checking chance similarly to read-repair 
(CASSANDRA-3611)
 + * a way to deactivate global key/row cache on per-CF basis (CASSANDRA-3667)
 + * fix LeveledCompactionStrategy broken because of generation pre-allocation
 +   in LeveledManifest (CASSANDRA-3691)
 + * finer-grained control over data directories (CASSANDRA-2749)
 + * Fix ClassCastException during hinted handoff (CASSANDRA-3694)
 +

[4/4] git commit: fix NPE on invalid CQL DELETE command

[slebresne]

fix NPE on invalid CQL DELETE command

patch by dbrosius; reviewed by slebresne for CASSANDRA-3755


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

Branch: refs/heads/trunk
Commit: b0dfb4cdc4717a4ba759cc3353e29cc76235d74e
Parents: 281af5e
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:26:53 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:26:53 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b0dfb4cd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c92a242..e4d207c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -13,6 +13,7 @@
  * fix race leading to super columns assertion failure (CASSANDRA-3957)
  * ensure that directory is selected for compaction for user-defined
tasks and upgradesstables (CASSANDRA-3985)
+ * fix NPE on invalid CQL delete command (CASSANDRA-3755)
 
 
 1.0.8

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b0dfb4cd/src/java/org/apache/cassandra/cql/DeleteStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql/DeleteStatement.java 
b/src/java/org/apache/cassandra/cql/DeleteStatement.java
index eb46076..1b33a01 100644
--- a/src/java/org/apache/cassandra/cql/DeleteStatement.java
+++ b/src/java/org/apache/cassandra/cql/DeleteStatement.java
@@ -74,6 +74,8 @@ public class DeleteStatement extends AbstractModification
 /** {@inheritDoc} */
 public List prepareRowMutations(String keyspace, ClientState 
clientState, Long timestamp) throws InvalidRequestException
 {
+CFMetaData metadata = validateColumnFamily(keyspace, columnFamily);
+
 clientState.hasColumnFamilyAccess(columnFamily, Permission.WRITE);
 AbstractType keyType = Schema.instance.getCFMetaData(keyspace, 
columnFamily).getKeyValidator();
 
@@ -81,18 +83,17 @@ public class DeleteStatement extends AbstractModification
 
 for (Term key : keys)
 {
-rowMutations.add(mutationForKey(key.getByteBuffer(keyType), 
keyspace, timestamp, clientState));
+rowMutations.add(mutationForKey(key.getByteBuffer(keyType), 
keyspace, timestamp, clientState, metadata));
 }
 
 return rowMutations;
 }
 
 /** {@inheritDoc} */
-public RowMutation mutationForKey(ByteBuffer key, String keyspace, Long 
timestamp, ClientState clientState) throws InvalidRequestException
+public RowMutation mutationForKey(ByteBuffer key, String keyspace, Long 
timestamp, ClientState clientState, CFMetaData metadata) throws 
InvalidRequestException
 {
 RowMutation rm = new RowMutation(keyspace, key);
 
-CFMetaData metadata = validateColumnFamily(keyspace, columnFamily);
 QueryProcessor.validateKeyAlias(metadata, keyName);
 
 AbstractType comparator = metadata.getComparatorFor(null);

[1/4] git commit: Merge branch 'cassandra-1.1' into trunk

[slebresne]

Updated Branches:
  refs/heads/trunk 25b2a4275 -> 27e322b63


Merge branch 'cassandra-1.1' into trunk


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

Branch: refs/heads/trunk
Commit: 27e322b63776076d593a3b64aabd62bea304aca1
Parents: 25b2a42 27c999a
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:34:26 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:34:26 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 .../cassandra/cql3/statements/DeleteStatement.java |1 -
 3 files changed, 5 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/27e322b6/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/27e322b6/src/java/org/apache/cassandra/cql/DeleteStatement.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/27e322b6/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
--

[1/3] git commit: Merge branch 'cassandra-1.1.0' into cassandra-1.1

[slebresne]

Updated Branches:
  refs/heads/cassandra-1.1 899ec8f25 -> 27c999a11


Merge branch 'cassandra-1.1.0' into cassandra-1.1


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

Branch: refs/heads/cassandra-1.1
Commit: 27c999a11730c2cad39caa30ce57248f27e93232
Parents: 899ec8f e05a327
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:33:35 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:33:35 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 .../cassandra/cql3/statements/DeleteStatement.java |1 -
 3 files changed, 5 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/27c999a1/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/27c999a1/src/java/org/apache/cassandra/cql/DeleteStatement.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/27c999a1/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
--

[2/3] git commit: Merge branch 'cassandra-1.0' into cassandra-1.1.0

[slebresne]

Merge branch 'cassandra-1.0' into cassandra-1.1.0

Conflicts:
src/java/org/apache/cassandra/cql/DeleteStatement.java


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

Branch: refs/heads/cassandra-1.1
Commit: e05a327e2cbbbc508bd53dee813de894faf6a272
Parents: 68032e9 b0dfb4c
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:32:52 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:32:52 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 .../cassandra/cql3/statements/DeleteStatement.java |1 -
 3 files changed, 5 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e05a327e/CHANGES.txt
--
diff --cc CHANGES.txt
index ae2b0f1,e4d207c..55d17f7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -47,96 -13,9 +47,97 @@@ Merged from 1.0
   * fix race leading to super columns assertion failure (CASSANDRA-3957)
   * ensure that directory is selected for compaction for user-defined
 tasks and upgradesstables (CASSANDRA-3985)
+  * fix NPE on invalid CQL delete command (CASSANDRA-3755)
  
  
 +1.1-beta1
 + * (cqlsh)
 +   + add SOURCE and CAPTURE commands, and --file option (CASSANDRA-3479)
 +   + add ALTER COLUMNFAMILY WITH (CASSANDRA-3523)
 +   + bundle Python dependencies with Cassandra (CASSANDRA-3507)
 +   + added to Debian package (CASSANDRA-3458)
 +   + display byte data instead of erroring out on decode failure 
 + (CASSANDRA-3874)
 + * add nodetool rebuild_index (CASSANDRA-3583)
 + * add nodetool rangekeysample (CASSANDRA-2917)
 + * Fix streaming too much data during move operations (CASSANDRA-3639)
 + * Nodetool and CLI connect to localhost by default (CASSANDRA-3568)
 + * Reduce memory used by primary index sample (CASSANDRA-3743)
 + * (Hadoop) separate input/output configurations (CASSANDRA-3197, 3765)
 + * avoid returning internal Cassandra classes over JMX (CASSANDRA-2805)
 + * add row-level isolation via SnapTree (CASSANDRA-2893)
 + * Optimize key count estimation when opening sstable on startup
 +   (CASSANDRA-2988)
 + * multi-dc replication optimization supporting CL > ONE (CASSANDRA-3577)
 + * add command to stop compactions (CASSANDRA-1740, 3566, 3582)
 + * multithreaded streaming (CASSANDRA-3494)
 + * removed in-tree redhat spec (CASSANDRA-3567)
 + * "defragment" rows for name-based queries under STCS, again (CASSANDRA-2503)
 + * Recycle commitlog segments for improved performance 
 +   (CASSANDRA-3411, 3543, 3557, 3615)
 + * update size-tiered compaction to prioritize small tiers (CASSANDRA-2407)
 + * add message expiration logic to OutboundTcpConnection (CASSANDRA-3005)
 + * off-heap cache to use sun.misc.Unsafe instead of JNA (CASSANDRA-3271)
 + * EACH_QUORUM is only supported for writes (CASSANDRA-3272)
 + * replace compactionlock use in schema migration by checking CFS.isValid
 +   (CASSANDRA-3116)
 + * recognize that "SELECT first ... *" isn't really "SELECT *" 
(CASSANDRA-3445)
 + * Use faster bytes comparison (CASSANDRA-3434)
 + * Bulk loader is no longer a fat client, (HADOOP) bulk load output format
 +   (CASSANDRA-3045)
 + * (Hadoop) add support for KeyRange.filter
 + * remove assumption that keys and token are in bijection
 +   (CASSANDRA-1034, 3574, 3604)
 + * always remove endpoints from delevery queue in HH (CASSANDRA-3546)
 + * fix race between cf flush and its 2ndary indexes flush (CASSANDRA-3547)
 + * fix potential race in AES when a repair fails (CASSANDRA-3548)
 + * Remove columns shadowed by a deleted container even when we cannot purge
 +   (CASSANDRA-3538)
 + * Improve memtable slice iteration performance (CASSANDRA-3545)
 + * more efficient allocation of small bloom filters (CASSANDRA-3618)
 + * Use separate writer thread in SSTableSimpleUnsortedWriter (CASSANDRA-3619)
 + * fsync the directory after new sstable or commitlog segment are created 
(CASSANDRA-3250)
 + * fix minor issues reported by FindBugs (CASSANDRA-3658)
 + * global key/row caches (CASSANDRA-3143, 3849)
 + * optimize memtable iteration during range scan (CASSANDRA-3638)
 + * introduce 'crc_check_chance' in CompressionParameters to support
 +   a checksum percentage checking chance similarly to read-repair 
(CASSANDRA-3611)
 + * a way to deactivate global key/row cache on per-CF basis (CASSANDRA-3667)
 + * fix LeveledCompactionStrategy broken because of generation pre-allocation
 +   in LeveledManifest (CASSANDRA-3691)
 + * finer-grained control over data directories (CASSANDRA-2749)
 + * Fix ClassCastException during hinted handoff (CASSANDRA-

[3/3] git commit: fix NPE on invalid CQL DELETE command

[slebresne]

fix NPE on invalid CQL DELETE command

patch by dbrosius; reviewed by slebresne for CASSANDRA-3755


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

Branch: refs/heads/cassandra-1.1
Commit: b0dfb4cdc4717a4ba759cc3353e29cc76235d74e
Parents: 281af5e
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:26:53 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:26:53 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b0dfb4cd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c92a242..e4d207c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -13,6 +13,7 @@
  * fix race leading to super columns assertion failure (CASSANDRA-3957)
  * ensure that directory is selected for compaction for user-defined
tasks and upgradesstables (CASSANDRA-3985)
+ * fix NPE on invalid CQL delete command (CASSANDRA-3755)
 
 
 1.0.8

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b0dfb4cd/src/java/org/apache/cassandra/cql/DeleteStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql/DeleteStatement.java 
b/src/java/org/apache/cassandra/cql/DeleteStatement.java
index eb46076..1b33a01 100644
--- a/src/java/org/apache/cassandra/cql/DeleteStatement.java
+++ b/src/java/org/apache/cassandra/cql/DeleteStatement.java
@@ -74,6 +74,8 @@ public class DeleteStatement extends AbstractModification
 /** {@inheritDoc} */
 public List prepareRowMutations(String keyspace, ClientState 
clientState, Long timestamp) throws InvalidRequestException
 {
+CFMetaData metadata = validateColumnFamily(keyspace, columnFamily);
+
 clientState.hasColumnFamilyAccess(columnFamily, Permission.WRITE);
 AbstractType keyType = Schema.instance.getCFMetaData(keyspace, 
columnFamily).getKeyValidator();
 
@@ -81,18 +83,17 @@ public class DeleteStatement extends AbstractModification
 
 for (Term key : keys)
 {
-rowMutations.add(mutationForKey(key.getByteBuffer(keyType), 
keyspace, timestamp, clientState));
+rowMutations.add(mutationForKey(key.getByteBuffer(keyType), 
keyspace, timestamp, clientState, metadata));
 }
 
 return rowMutations;
 }
 
 /** {@inheritDoc} */
-public RowMutation mutationForKey(ByteBuffer key, String keyspace, Long 
timestamp, ClientState clientState) throws InvalidRequestException
+public RowMutation mutationForKey(ByteBuffer key, String keyspace, Long 
timestamp, ClientState clientState, CFMetaData metadata) throws 
InvalidRequestException
 {
 RowMutation rm = new RowMutation(keyspace, key);
 
-CFMetaData metadata = validateColumnFamily(keyspace, columnFamily);
 QueryProcessor.validateKeyAlias(metadata, keyName);
 
 AbstractType comparator = metadata.getComparatorFor(null);

[2/2] git commit: fix NPE on invalid CQL DELETE command

[slebresne]

fix NPE on invalid CQL DELETE command

patch by dbrosius; reviewed by slebresne for CASSANDRA-3755


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

Branch: refs/heads/cassandra-1.1.0
Commit: b0dfb4cdc4717a4ba759cc3353e29cc76235d74e
Parents: 281af5e
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:26:53 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:26:53 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b0dfb4cd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c92a242..e4d207c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -13,6 +13,7 @@
  * fix race leading to super columns assertion failure (CASSANDRA-3957)
  * ensure that directory is selected for compaction for user-defined
tasks and upgradesstables (CASSANDRA-3985)
+ * fix NPE on invalid CQL delete command (CASSANDRA-3755)
 
 
 1.0.8

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b0dfb4cd/src/java/org/apache/cassandra/cql/DeleteStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql/DeleteStatement.java 
b/src/java/org/apache/cassandra/cql/DeleteStatement.java
index eb46076..1b33a01 100644
--- a/src/java/org/apache/cassandra/cql/DeleteStatement.java
+++ b/src/java/org/apache/cassandra/cql/DeleteStatement.java
@@ -74,6 +74,8 @@ public class DeleteStatement extends AbstractModification
 /** {@inheritDoc} */
 public List prepareRowMutations(String keyspace, ClientState 
clientState, Long timestamp) throws InvalidRequestException
 {
+CFMetaData metadata = validateColumnFamily(keyspace, columnFamily);
+
 clientState.hasColumnFamilyAccess(columnFamily, Permission.WRITE);
 AbstractType keyType = Schema.instance.getCFMetaData(keyspace, 
columnFamily).getKeyValidator();
 
@@ -81,18 +83,17 @@ public class DeleteStatement extends AbstractModification
 
 for (Term key : keys)
 {
-rowMutations.add(mutationForKey(key.getByteBuffer(keyType), 
keyspace, timestamp, clientState));
+rowMutations.add(mutationForKey(key.getByteBuffer(keyType), 
keyspace, timestamp, clientState, metadata));
 }
 
 return rowMutations;
 }
 
 /** {@inheritDoc} */
-public RowMutation mutationForKey(ByteBuffer key, String keyspace, Long 
timestamp, ClientState clientState) throws InvalidRequestException
+public RowMutation mutationForKey(ByteBuffer key, String keyspace, Long 
timestamp, ClientState clientState, CFMetaData metadata) throws 
InvalidRequestException
 {
 RowMutation rm = new RowMutation(keyspace, key);
 
-CFMetaData metadata = validateColumnFamily(keyspace, columnFamily);
 QueryProcessor.validateKeyAlias(metadata, keyName);
 
 AbstractType comparator = metadata.getComparatorFor(null);

[1/2] git commit: Merge branch 'cassandra-1.0' into cassandra-1.1.0

[slebresne]

Updated Branches:
  refs/heads/cassandra-1.1.0 68032e940 -> e05a327e2


Merge branch 'cassandra-1.0' into cassandra-1.1.0

Conflicts:
src/java/org/apache/cassandra/cql/DeleteStatement.java


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

Branch: refs/heads/cassandra-1.1.0
Commit: e05a327e2cbbbc508bd53dee813de894faf6a272
Parents: 68032e9 b0dfb4c
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:32:52 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:32:52 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 .../cassandra/cql3/statements/DeleteStatement.java |1 -
 3 files changed, 5 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e05a327e/CHANGES.txt
--
diff --cc CHANGES.txt
index ae2b0f1,e4d207c..55d17f7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -47,96 -13,9 +47,97 @@@ Merged from 1.0
   * fix race leading to super columns assertion failure (CASSANDRA-3957)
   * ensure that directory is selected for compaction for user-defined
 tasks and upgradesstables (CASSANDRA-3985)
+  * fix NPE on invalid CQL delete command (CASSANDRA-3755)
  
  
 +1.1-beta1
 + * (cqlsh)
 +   + add SOURCE and CAPTURE commands, and --file option (CASSANDRA-3479)
 +   + add ALTER COLUMNFAMILY WITH (CASSANDRA-3523)
 +   + bundle Python dependencies with Cassandra (CASSANDRA-3507)
 +   + added to Debian package (CASSANDRA-3458)
 +   + display byte data instead of erroring out on decode failure 
 + (CASSANDRA-3874)
 + * add nodetool rebuild_index (CASSANDRA-3583)
 + * add nodetool rangekeysample (CASSANDRA-2917)
 + * Fix streaming too much data during move operations (CASSANDRA-3639)
 + * Nodetool and CLI connect to localhost by default (CASSANDRA-3568)
 + * Reduce memory used by primary index sample (CASSANDRA-3743)
 + * (Hadoop) separate input/output configurations (CASSANDRA-3197, 3765)
 + * avoid returning internal Cassandra classes over JMX (CASSANDRA-2805)
 + * add row-level isolation via SnapTree (CASSANDRA-2893)
 + * Optimize key count estimation when opening sstable on startup
 +   (CASSANDRA-2988)
 + * multi-dc replication optimization supporting CL > ONE (CASSANDRA-3577)
 + * add command to stop compactions (CASSANDRA-1740, 3566, 3582)
 + * multithreaded streaming (CASSANDRA-3494)
 + * removed in-tree redhat spec (CASSANDRA-3567)
 + * "defragment" rows for name-based queries under STCS, again (CASSANDRA-2503)
 + * Recycle commitlog segments for improved performance 
 +   (CASSANDRA-3411, 3543, 3557, 3615)
 + * update size-tiered compaction to prioritize small tiers (CASSANDRA-2407)
 + * add message expiration logic to OutboundTcpConnection (CASSANDRA-3005)
 + * off-heap cache to use sun.misc.Unsafe instead of JNA (CASSANDRA-3271)
 + * EACH_QUORUM is only supported for writes (CASSANDRA-3272)
 + * replace compactionlock use in schema migration by checking CFS.isValid
 +   (CASSANDRA-3116)
 + * recognize that "SELECT first ... *" isn't really "SELECT *" 
(CASSANDRA-3445)
 + * Use faster bytes comparison (CASSANDRA-3434)
 + * Bulk loader is no longer a fat client, (HADOOP) bulk load output format
 +   (CASSANDRA-3045)
 + * (Hadoop) add support for KeyRange.filter
 + * remove assumption that keys and token are in bijection
 +   (CASSANDRA-1034, 3574, 3604)
 + * always remove endpoints from delevery queue in HH (CASSANDRA-3546)
 + * fix race between cf flush and its 2ndary indexes flush (CASSANDRA-3547)
 + * fix potential race in AES when a repair fails (CASSANDRA-3548)
 + * Remove columns shadowed by a deleted container even when we cannot purge
 +   (CASSANDRA-3538)
 + * Improve memtable slice iteration performance (CASSANDRA-3545)
 + * more efficient allocation of small bloom filters (CASSANDRA-3618)
 + * Use separate writer thread in SSTableSimpleUnsortedWriter (CASSANDRA-3619)
 + * fsync the directory after new sstable or commitlog segment are created 
(CASSANDRA-3250)
 + * fix minor issues reported by FindBugs (CASSANDRA-3658)
 + * global key/row caches (CASSANDRA-3143, 3849)
 + * optimize memtable iteration during range scan (CASSANDRA-3638)
 + * introduce 'crc_check_chance' in CompressionParameters to support
 +   a checksum percentage checking chance similarly to read-repair 
(CASSANDRA-3611)
 + * a way to deactivate global key/row cache on per-CF basis (CASSANDRA-3667)
 + * fix LeveledCompactionStrategy broken because of generation pre-allocation
 +   in LeveledManifest (CASSANDRA-3691)
 + * finer-grained control over data directories (CAS

git commit: fix NPE on invalid CQL DELETE command

[slebresne]

Updated Branches:
  refs/heads/cassandra-1.0 281af5e4f -> b0dfb4cdc


fix NPE on invalid CQL DELETE command

patch by dbrosius; reviewed by slebresne for CASSANDRA-3755


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

Branch: refs/heads/cassandra-1.0
Commit: b0dfb4cdc4717a4ba759cc3353e29cc76235d74e
Parents: 281af5e
Author: Sylvain Lebresne 
Authored: Thu Mar 29 16:26:53 2012 +0200
Committer: Sylvain Lebresne 
Committed: Thu Mar 29 16:26:53 2012 +0200

--
 CHANGES.txt|1 +
 .../org/apache/cassandra/cql/DeleteStatement.java  |7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b0dfb4cd/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c92a242..e4d207c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -13,6 +13,7 @@
  * fix race leading to super columns assertion failure (CASSANDRA-3957)
  * ensure that directory is selected for compaction for user-defined
tasks and upgradesstables (CASSANDRA-3985)
+ * fix NPE on invalid CQL delete command (CASSANDRA-3755)
 
 
 1.0.8

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b0dfb4cd/src/java/org/apache/cassandra/cql/DeleteStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql/DeleteStatement.java 
b/src/java/org/apache/cassandra/cql/DeleteStatement.java
index eb46076..1b33a01 100644
--- a/src/java/org/apache/cassandra/cql/DeleteStatement.java
+++ b/src/java/org/apache/cassandra/cql/DeleteStatement.java
@@ -74,6 +74,8 @@ public class DeleteStatement extends AbstractModification
 /** {@inheritDoc} */
 public List prepareRowMutations(String keyspace, ClientState 
clientState, Long timestamp) throws InvalidRequestException
 {
+CFMetaData metadata = validateColumnFamily(keyspace, columnFamily);
+
 clientState.hasColumnFamilyAccess(columnFamily, Permission.WRITE);
 AbstractType keyType = Schema.instance.getCFMetaData(keyspace, 
columnFamily).getKeyValidator();
 
@@ -81,18 +83,17 @@ public class DeleteStatement extends AbstractModification
 
 for (Term key : keys)
 {
-rowMutations.add(mutationForKey(key.getByteBuffer(keyType), 
keyspace, timestamp, clientState));
+rowMutations.add(mutationForKey(key.getByteBuffer(keyType), 
keyspace, timestamp, clientState, metadata));
 }
 
 return rowMutations;
 }
 
 /** {@inheritDoc} */
-public RowMutation mutationForKey(ByteBuffer key, String keyspace, Long 
timestamp, ClientState clientState) throws InvalidRequestException
+public RowMutation mutationForKey(ByteBuffer key, String keyspace, Long 
timestamp, ClientState clientState, CFMetaData metadata) throws 
InvalidRequestException
 {
 RowMutation rm = new RowMutation(keyspace, key);
 
-CFMetaData metadata = validateColumnFamily(keyspace, columnFamily);
 QueryProcessor.validateKeyAlias(metadata, keyName);
 
 AbstractType comparator = metadata.getComparatorFor(null);

[jira] [Commented] (CASSANDRA-4099) IncomingTCPConnection recognizes from by doing socket.getInetAddress() instead of BroadCastAddress

[Brandon Williams (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241258#comment-13241258
 ] 

Brandon Williams commented on CASSANDRA-4099:
-

I'm confused, how does 'from' differ from 'msg.getFrom' in this patch?  It 
seems like a no-op.

> IncomingTCPConnection recognizes from by doing socket.getInetAddress() 
> instead of BroadCastAddress
> --
>
> Key: CASSANDRA-4099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4099
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Attachments: 0001-CASSANDRA-4099-v2.patch, 0001-CASSANDRA-4099.patch
>
>
> change "this.from = socket.getInetAddress()" to understand the broad cast IP, 
> but the problem is we dont know until the first packet is received, this 
> ticket is to work around the problem until it reads the first packet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3647) Support arbitrarily nested "documents" in CQL

[Rick Branson (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241228#comment-13241228
 ] 

Rick Branson commented on CASSANDRA-3647:
-

I hate to gold plate here, but this feature is of marginal utility and could be 
implemented on-top of a UDF facility, similar to how PostgreSQL supports XML 
and (in 9.2) JSON formats.

> Support arbitrarily nested "documents" in CQL
> -
>
> Key: CASSANDRA-3647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
> Project: Cassandra
>  Issue Type: New Feature
>  Components: API, Core
>Reporter: Jonathan Ellis
>  Labels: cql
>
> Composite columns introduce the ability to have arbitrarily nested data in a 
> Cassandra row.  We should expose this through CQL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4081) Issue with cassandra-cli "assume" command and custom types

[Pavel Yaskevich (Updated) (JIRA)]

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

Pavel Yaskevich updated CASSANDRA-4081:
---

Attachment: CASSANDRA-4081.patch

> Issue with cassandra-cli "assume" command and custom types
> --
>
> Key: CASSANDRA-4081
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4081
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.0.7
> Environment: Cassandra 1.0.7 on Mac OSX Lion
>Reporter: Drew Kutcharian
>Assignee: Pavel Yaskevich
> Fix For: 1.0.9
>
> Attachments: CASSANDRA-4081.patch
>
>
> There seems to be an issue with cassandra-cli's assume command with a custom 
> type. I get "Syntax error at position 35: missing EOF at '.'"
> To make sure the issue is not with my custom type, I tried it with the 
> built-in BytesType and got the same error:
> [default@test] assume UserDetails validator as 
> org.apache.cassandra.db.marshal.BytesType;
> Syntax error at position 35: missing EOF at '.'
> I also tried it with single and double quotes with no success:
> [default@test] assume UserDetails validator as 
> 'org.apache.cassandra.db.marshal.BytesType';
> Syntax error at position 32: mismatched input 
> ''org.apache.cassandra.db.marshal.BytesType'' expecting Identifier
> Based on the output of "help assume" I should be able to just pass a fqn of a 
> class.
> > It is also valid to specify the fully-qualified class name to a class that
> > extends org.apache.Cassandra.db.marshal.AbstractType.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2864) Alternative Row Cache Implementation

[Daniel Doubleday (Updated) (JIRA)]

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

Daniel Doubleday updated CASSANDRA-2864:


Attachment: (was: rowcache.patch)

> Alternative Row Cache Implementation
> 
>
> Key: CASSANDRA-2864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2864
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Daniel Doubleday
>Assignee: Daniel Doubleday
>Priority: Minor
>
> we have been working on an alternative implementation to the existing row 
> cache(s)
> We have 2 main goals:
> - Decrease memory -> get more rows in the cache without suffering a huge 
> performance penalty
> - Reduce gc pressure
> This sounds a lot like we should be using the new serializing cache in 0.8. 
> Unfortunately our workload consists of loads of updates which would 
> invalidate the cache all the time.
> The second unfortunate thing is that the idea we came up with doesn't fit the 
> new cache provider api...
> It looks like this:
> Like the serializing cache we basically only cache the serialized byte 
> buffer. we don't serialize the bloom filter and try to do some other minor 
> compression tricks (var ints etc not done yet). The main difference is that 
> we don't deserialize but use the normal sstable iterators and filters as in 
> the regular uncached case.
> So the read path looks like this:
> return filter.collectCollatedColumns(memtable iter, cached row iter)
> The write path is not affected. It does not update the cache
> During flush we merge all memtable updates with the cached rows.
> The attached patch is based on 0.8 branch r1143352
> It does not replace the existing row cache but sits aside it. Theres 
> environment switch to choose the implementation. This way it is easy to 
> benchmark performance differences.
> -DuseSSTableCache=true enables the alternative cache. It shares its 
> configuration with the standard row cache. So the cache capacity is shared. 
> We have duplicated a fair amount of code. First we actually refactored the 
> existing sstable filter / reader but than decided to minimize dependencies. 
> Also this way it is easy to customize serialization for in memory sstable 
> rows. 
> We have also experimented a little with compression but since this task at 
> this stage is mainly to kick off discussion we wanted to keep things simple. 
> But there is certainly room for optimizations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2864) Alternative Row Cache Implementation

[Daniel Doubleday (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241192#comment-13241192
 ] 

Daniel Doubleday commented on CASSANDRA-2864:
-

Removed old obsolete patch to prevent confusion


> Alternative Row Cache Implementation
> 
>
> Key: CASSANDRA-2864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2864
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Daniel Doubleday
>Assignee: Daniel Doubleday
>Priority: Minor
>
> we have been working on an alternative implementation to the existing row 
> cache(s)
> We have 2 main goals:
> - Decrease memory -> get more rows in the cache without suffering a huge 
> performance penalty
> - Reduce gc pressure
> This sounds a lot like we should be using the new serializing cache in 0.8. 
> Unfortunately our workload consists of loads of updates which would 
> invalidate the cache all the time.
> The second unfortunate thing is that the idea we came up with doesn't fit the 
> new cache provider api...
> It looks like this:
> Like the serializing cache we basically only cache the serialized byte 
> buffer. we don't serialize the bloom filter and try to do some other minor 
> compression tricks (var ints etc not done yet). The main difference is that 
> we don't deserialize but use the normal sstable iterators and filters as in 
> the regular uncached case.
> So the read path looks like this:
> return filter.collectCollatedColumns(memtable iter, cached row iter)
> The write path is not affected. It does not update the cache
> During flush we merge all memtable updates with the cached rows.
> The attached patch is based on 0.8 branch r1143352
> It does not replace the existing row cache but sits aside it. Theres 
> environment switch to choose the implementation. This way it is easy to 
> benchmark performance differences.
> -DuseSSTableCache=true enables the alternative cache. It shares its 
> configuration with the standard row cache. So the cache capacity is shared. 
> We have duplicated a fair amount of code. First we actually refactored the 
> existing sstable filter / reader but than decided to minimize dependencies. 
> Also this way it is easy to customize serialization for in memory sstable 
> rows. 
> We have also experimented a little with compression but since this task at 
> this stage is mainly to kick off discussion we wanted to keep things simple. 
> But there is certainly room for optimizations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2864) Alternative Row Cache Implementation

[Daniel Doubleday (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241188#comment-13241188
 ] 

Daniel Doubleday commented on CASSANDRA-2864:
-

So ... some final remarks

We have this in production and it's looking good so far.
Our cached real world cfs are pretty skinny so far so the reduction in memsize 
is only ~ 3.5 - 4x.

Latency wise there's no difference (compared to CLHC) keeping the max number of 
items equal. So the improvement comes from being able to keep more rows in 
memory and therefor increase hit ratio or leave more mem for page cache.

If there's any interest in this: the fork we are running lives here:

https://github.com/Smeet/cassandra/tree/cassandra-1.0

This is still work in progress which works for us (counters and supercolumns 
are untested) and allows to switch implementation via startup params.

Again the intention of this patch is to replace both CLHC and SC. 
Silvain expressed concerns that this might not work for counters. Since we 
don't use them I didn't bother to much (at least until it's clear whether this 
is interesting for you or not)

Next step for me is to port to 1.1 and look at the key cache.

Please comment if you want to follow up or close otherwise.

Thanks

> Alternative Row Cache Implementation
> 
>
> Key: CASSANDRA-2864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2864
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Daniel Doubleday
>Assignee: Daniel Doubleday
>Priority: Minor
> Attachments: rowcache.patch
>
>
> we have been working on an alternative implementation to the existing row 
> cache(s)
> We have 2 main goals:
> - Decrease memory -> get more rows in the cache without suffering a huge 
> performance penalty
> - Reduce gc pressure
> This sounds a lot like we should be using the new serializing cache in 0.8. 
> Unfortunately our workload consists of loads of updates which would 
> invalidate the cache all the time.
> The second unfortunate thing is that the idea we came up with doesn't fit the 
> new cache provider api...
> It looks like this:
> Like the serializing cache we basically only cache the serialized byte 
> buffer. we don't serialize the bloom filter and try to do some other minor 
> compression tricks (var ints etc not done yet). The main difference is that 
> we don't deserialize but use the normal sstable iterators and filters as in 
> the regular uncached case.
> So the read path looks like this:
> return filter.collectCollatedColumns(memtable iter, cached row iter)
> The write path is not affected. It does not update the cache
> During flush we merge all memtable updates with the cached rows.
> The attached patch is based on 0.8 branch r1143352
> It does not replace the existing row cache but sits aside it. Theres 
> environment switch to choose the implementation. This way it is easy to 
> benchmark performance differences.
> -DuseSSTableCache=true enables the alternative cache. It shares its 
> configuration with the standard row cache. So the cache capacity is shared. 
> We have duplicated a fair amount of code. First we actually refactored the 
> existing sstable filter / reader but than decided to minimize dependencies. 
> Also this way it is easy to customize serialization for in memory sstable 
> rows. 
> We have also experimented a little with compression but since this task at 
> this stage is mainly to kick off discussion we wanted to keep things simple. 
> But there is certainly room for optimizations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4081) Issue with cassandra-cli "assume" command and custom types

[T Jake Luciani (Updated) (JIRA)]

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

T Jake Luciani updated CASSANDRA-4081:
--

Fix Version/s: 1.0.9

> Issue with cassandra-cli "assume" command and custom types
> --
>
> Key: CASSANDRA-4081
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4081
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.0.7
> Environment: Cassandra 1.0.7 on Mac OSX Lion
>Reporter: Drew Kutcharian
>Assignee: Pavel Yaskevich
> Fix For: 1.0.9
>
>
> There seems to be an issue with cassandra-cli's assume command with a custom 
> type. I get "Syntax error at position 35: missing EOF at '.'"
> To make sure the issue is not with my custom type, I tried it with the 
> built-in BytesType and got the same error:
> [default@test] assume UserDetails validator as 
> org.apache.cassandra.db.marshal.BytesType;
> Syntax error at position 35: missing EOF at '.'
> I also tried it with single and double quotes with no success:
> [default@test] assume UserDetails validator as 
> 'org.apache.cassandra.db.marshal.BytesType';
> Syntax error at position 32: mismatched input 
> ''org.apache.cassandra.db.marshal.BytesType'' expecting Identifier
> Based on the output of "help assume" I should be able to just pass a fqn of a 
> class.
> > It is also valid to specify the fully-qualified class name to a class that
> > extends org.apache.Cassandra.db.marshal.AbstractType.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-4081) Issue with cassandra-cli "assume" command and custom types

[T Jake Luciani (Assigned) (JIRA)]

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

T Jake Luciani reassigned CASSANDRA-4081:
-

Assignee: Pavel Yaskevich

> Issue with cassandra-cli "assume" command and custom types
> --
>
> Key: CASSANDRA-4081
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4081
> Project: Cassandra
>  Issue Type: Bug
>Affects Versions: 1.0.7
> Environment: Cassandra 1.0.7 on Mac OSX Lion
>Reporter: Drew Kutcharian
>Assignee: Pavel Yaskevich
> Fix For: 1.0.9
>
>
> There seems to be an issue with cassandra-cli's assume command with a custom 
> type. I get "Syntax error at position 35: missing EOF at '.'"
> To make sure the issue is not with my custom type, I tried it with the 
> built-in BytesType and got the same error:
> [default@test] assume UserDetails validator as 
> org.apache.cassandra.db.marshal.BytesType;
> Syntax error at position 35: missing EOF at '.'
> I also tried it with single and double quotes with no success:
> [default@test] assume UserDetails validator as 
> 'org.apache.cassandra.db.marshal.BytesType';
> Syntax error at position 32: mismatched input 
> ''org.apache.cassandra.db.marshal.BytesType'' expecting Identifier
> Based on the output of "help assume" I should be able to just pass a fqn of a 
> class.
> > It is also valid to specify the fully-qualified class name to a class that
> > extends org.apache.Cassandra.db.marshal.AbstractType.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira