git commit: add jsr305.jar build dep, to quell CNFE warnings on GuardedBy annotations
Updated Branches: refs/heads/trunk 71c9209e7 -> 65166aa86 add jsr305.jar build dep, to quell CNFE warnings on GuardedBy annotations Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/65166aa8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/65166aa8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/65166aa8 Branch: refs/heads/trunk Commit: 65166aa861f4317f410d6c4381d6dd91ca465e17 Parents: 71c9209 Author: Dave Brosius Authored: Sat Sep 21 00:29:02 2013 -0400 Committer: Dave Brosius Committed: Sat Sep 21 00:29:02 2013 -0400 -- build.xml | 2 ++ 1 file changed, 2 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/65166aa8/build.xml -- diff --git a/build.xml b/build.xml index 5be37ca..5be1fbc 100644 --- a/build.xml +++ b/build.xml @@ -380,6 +380,7 @@ + @@ -410,6 +411,7 @@ +
[3/3] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71c9209e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71c9209e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71c9209e Branch: refs/heads/trunk Commit: 71c9209e765ddf496deebf64d2ad1b7ab5ffa1a8 Parents: 4fb0904 15c738c Author: Dave Brosius Authored: Fri Sep 20 23:36:11 2013 -0400 Committer: Dave Brosius Committed: Fri Sep 20 23:36:11 2013 -0400 -- CHANGES.txt | 5 ++ .../apache/cassandra/net/MessagingService.java | 75 ++-- 2 files changed, 44 insertions(+), 36 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/71c9209e/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/71c9209e/src/java/org/apache/cassandra/net/MessagingService.java --
[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/15c738c5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/15c738c5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/15c738c5 Branch: refs/heads/trunk Commit: 15c738c588828fda29c8ceff0e0fd505770ece2c Parents: 0d976a8 fb43309 Author: Dave Brosius Authored: Fri Sep 20 23:35:27 2013 -0400 Committer: Dave Brosius Committed: Fri Sep 20 23:35:27 2013 -0400 -- CHANGES.txt | 5 ++ .../apache/cassandra/net/MessagingService.java | 75 ++-- 2 files changed, 44 insertions(+), 36 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/15c738c5/CHANGES.txt -- diff --cc CHANGES.txt index 7f30117,b4681ae..f239b5a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,38 -1,10 +1,43 @@@ -1.2.11 +2.0.1 + * Fix bug that could allow reading deleted data temporarily (CASSANDRA-6025) + * Improve memory use defaults (CASSANDRA-5069) + * Make ThriftServer more easlly extensible (CASSANDRA-6058) + * Remove Hadoop dependency from ITransportFactory (CASSANDRA-6062) + * add file_cache_size_in_mb setting (CASSANDRA-5661) + * Improve error message when yaml contains invalid properties (CASSANDRA-5958) + * Improve leveled compaction's ability to find non-overlapping L0 compactions + to work on concurrently (CASSANDRA-5921) + * Notify indexer of columns shadowed by range tombstones (CASSANDRA-5614) + * Log Merkle tree stats (CASSANDRA-2698) + * Switch from crc32 to adler32 for compressed sstable checksums (CASSANDRA-5862) + * Improve offheap memcpy performance (CASSANDRA-5884) + * Use a range aware scanner for cleanup (CASSANDRA-2524) + * Cleanup doesn't need to inspect sstables that contain only local data + (CASSANDRA-5722) + * Add ability for CQL3 to list partition keys (CASSANDRA-4536) + * Improve native protocol serialization (CASSANDRA-5664) + * Upgrade Thrift to 0.9.1 (CASSANDRA-5923) + * Require superuser status for adding triggers (CASSANDRA-5963) + * Make standalone scrubber handle old and new style leveled manifest + (CASSANDRA-6005) + * Fix paxos bugs (CASSANDRA-6012, 6013, 6023) + * Fix paged ranges with multiple replicas (CASSANDRA-6004) + * Fix potential AssertionError during tracing (CASSANDRA-6041) + * Fix NPE in sstablesplit (CASSANDRA-6027) + * Migrate pre-2.0 key/value/column aliases to system.schema_columns + (CASSANDRA-6009) + * Paging filter empty rows too agressively (CASSANDRA-6040) + * Support variadic parameters for IN clauses (CASSANDRA-4210) + * cqlsh: return the result of CAS writes (CASSANDRA-5796) + * Fix validation of IN clauses with 2ndary indexes (CASSANDRA-6050) + * Support named bind variables in CQL (CASSANDRA-6033) +Merged from 1.2: * Allow cache-keys-to-save to be set at runtime (CASSANDRA-5980) + * Allow where clause conditions to be in parenthesis (CASSANDRA-6037) + * Do not open non-ssl storage port if encryption option is all (CASSANDRA-3916) + + + 1.2.10 * Avoid second-guessing out-of-space state (CASSANDRA-5605) * Tuning knobs for dealing with large blobs and many CFs (CASSANDRA-5982) * (Hadoop) Fix CQLRW for thrift tables (CASSANDRA-6002) http://git-wip-us.apache.org/repos/asf/cassandra/blob/15c738c5/src/java/org/apache/cassandra/net/MessagingService.java --
[1/3] git commit: Do not open non-ssl storage port if encryption option is all patch by dbrosius reviewed by jbellis for cassandra-3916
Updated Branches:
refs/heads/trunk 4fb090481 -> 71c9209e7
Do not open non-ssl storage port if encryption option is all
patch by dbrosius reviewed by jbellis for cassandra-3916
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fb43309b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fb43309b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fb43309b
Branch: refs/heads/trunk
Commit: fb43309b4741372f777e8ce910cd496299a1ebbf
Parents: a0fa697
Author: Dave Brosius
Authored: Fri Sep 20 23:24:10 2013 -0400
Committer: Dave Brosius
Committed: Fri Sep 20 23:24:10 2013 -0400
--
CHANGES.txt | 2 +
.../apache/cassandra/net/MessagingService.java | 75 ++--
2 files changed, 41 insertions(+), 36 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb43309b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 27e6f24..b4681ae 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,7 @@
1.2.11
* Allow cache-keys-to-save to be set at runtime (CASSANDRA-5980)
+ * Allow where clause conditions to be in parenthesis (CASSANDRA-6037)
+ * Do not open non-ssl storage port if encryption option is all
(CASSANDRA-3916)
1.2.10
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb43309b/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index 2964d35..a199e83 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -413,45 +413,48 @@ public final class MessagingService implements
MessagingServiceMBean
logger.info("Starting Encrypted Messaging Service on SSL port {}",
DatabaseDescriptor.getSSLStoragePort());
}
-ServerSocketChannel serverChannel = null;
-try
-{
-serverChannel = ServerSocketChannel.open();
-}
-catch (IOException e)
-{
-throw new RuntimeException(e);
-}
-ServerSocket socket = serverChannel.socket();
-try
-{
-socket.setReuseAddress(true);
-}
-catch (SocketException e)
+if
(DatabaseDescriptor.getServerEncryptionOptions().internode_encryption !=
ServerEncryptionOptions.InternodeEncryption.all)
{
-throw new ConfigurationException("Insufficient permissions to
setReuseAddress", e);
-}
-InetSocketAddress address = new InetSocketAddress(localEp,
DatabaseDescriptor.getStoragePort());
-try
-{
-socket.bind(address);
-}
-catch (BindException e)
-{
-if (e.getMessage().contains("in use"))
-throw new ConfigurationException(address + " is in use by
another process. Change listen_address:storage_port in cassandra.yaml to
values that do not conflict with other services");
-else if (e.getMessage().contains("Cannot assign requested
address"))
-throw new ConfigurationException("Unable to bind to address "
+ address
- + ". Set listen_address in
cassandra.yaml to an interface you can bind to, e.g., your private IP address
on EC2");
-else
+ServerSocketChannel serverChannel = null;
+try
+{
+serverChannel = ServerSocketChannel.open();
+}
+catch (IOException e)
+{
throw new RuntimeException(e);
+}
+ServerSocket socket = serverChannel.socket();
+try
+{
+socket.setReuseAddress(true);
+}
+catch (SocketException e)
+{
+throw new ConfigurationException("Insufficient permissions to
setReuseAddress", e);
+}
+InetSocketAddress address = new InetSocketAddress(localEp,
DatabaseDescriptor.getStoragePort());
+try
+{
+socket.bind(address);
+}
+catch (BindException e)
+{
+if (e.getMessage().contains("in use"))
+throw new ConfigurationException(address + " is in use by
another process. Change listen_address:storage_port in cassandra.yaml to
values that do not conflict with other services");
+else if (e.getMessage().contains("Cannot assign requested
address"))
+throw new ConfigurationException("Unable to bind to
address " + add
[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/15c738c5 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/15c738c5 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/15c738c5 Branch: refs/heads/cassandra-2.0 Commit: 15c738c588828fda29c8ceff0e0fd505770ece2c Parents: 0d976a8 fb43309 Author: Dave Brosius Authored: Fri Sep 20 23:35:27 2013 -0400 Committer: Dave Brosius Committed: Fri Sep 20 23:35:27 2013 -0400 -- CHANGES.txt | 5 ++ .../apache/cassandra/net/MessagingService.java | 75 ++-- 2 files changed, 44 insertions(+), 36 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/15c738c5/CHANGES.txt -- diff --cc CHANGES.txt index 7f30117,b4681ae..f239b5a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,38 -1,10 +1,43 @@@ -1.2.11 +2.0.1 + * Fix bug that could allow reading deleted data temporarily (CASSANDRA-6025) + * Improve memory use defaults (CASSANDRA-5069) + * Make ThriftServer more easlly extensible (CASSANDRA-6058) + * Remove Hadoop dependency from ITransportFactory (CASSANDRA-6062) + * add file_cache_size_in_mb setting (CASSANDRA-5661) + * Improve error message when yaml contains invalid properties (CASSANDRA-5958) + * Improve leveled compaction's ability to find non-overlapping L0 compactions + to work on concurrently (CASSANDRA-5921) + * Notify indexer of columns shadowed by range tombstones (CASSANDRA-5614) + * Log Merkle tree stats (CASSANDRA-2698) + * Switch from crc32 to adler32 for compressed sstable checksums (CASSANDRA-5862) + * Improve offheap memcpy performance (CASSANDRA-5884) + * Use a range aware scanner for cleanup (CASSANDRA-2524) + * Cleanup doesn't need to inspect sstables that contain only local data + (CASSANDRA-5722) + * Add ability for CQL3 to list partition keys (CASSANDRA-4536) + * Improve native protocol serialization (CASSANDRA-5664) + * Upgrade Thrift to 0.9.1 (CASSANDRA-5923) + * Require superuser status for adding triggers (CASSANDRA-5963) + * Make standalone scrubber handle old and new style leveled manifest + (CASSANDRA-6005) + * Fix paxos bugs (CASSANDRA-6012, 6013, 6023) + * Fix paged ranges with multiple replicas (CASSANDRA-6004) + * Fix potential AssertionError during tracing (CASSANDRA-6041) + * Fix NPE in sstablesplit (CASSANDRA-6027) + * Migrate pre-2.0 key/value/column aliases to system.schema_columns + (CASSANDRA-6009) + * Paging filter empty rows too agressively (CASSANDRA-6040) + * Support variadic parameters for IN clauses (CASSANDRA-4210) + * cqlsh: return the result of CAS writes (CASSANDRA-5796) + * Fix validation of IN clauses with 2ndary indexes (CASSANDRA-6050) + * Support named bind variables in CQL (CASSANDRA-6033) +Merged from 1.2: * Allow cache-keys-to-save to be set at runtime (CASSANDRA-5980) + * Allow where clause conditions to be in parenthesis (CASSANDRA-6037) + * Do not open non-ssl storage port if encryption option is all (CASSANDRA-3916) + + + 1.2.10 * Avoid second-guessing out-of-space state (CASSANDRA-5605) * Tuning knobs for dealing with large blobs and many CFs (CASSANDRA-5982) * (Hadoop) Fix CQLRW for thrift tables (CASSANDRA-6002) http://git-wip-us.apache.org/repos/asf/cassandra/blob/15c738c5/src/java/org/apache/cassandra/net/MessagingService.java --
[1/2] git commit: Do not open non-ssl storage port if encryption option is all patch by dbrosius reviewed by jbellis for cassandra-3916
Updated Branches:
refs/heads/cassandra-2.0 0d976a8fb -> 15c738c58
Do not open non-ssl storage port if encryption option is all
patch by dbrosius reviewed by jbellis for cassandra-3916
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fb43309b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fb43309b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fb43309b
Branch: refs/heads/cassandra-2.0
Commit: fb43309b4741372f777e8ce910cd496299a1ebbf
Parents: a0fa697
Author: Dave Brosius
Authored: Fri Sep 20 23:24:10 2013 -0400
Committer: Dave Brosius
Committed: Fri Sep 20 23:24:10 2013 -0400
--
CHANGES.txt | 2 +
.../apache/cassandra/net/MessagingService.java | 75 ++--
2 files changed, 41 insertions(+), 36 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb43309b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 27e6f24..b4681ae 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,7 @@
1.2.11
* Allow cache-keys-to-save to be set at runtime (CASSANDRA-5980)
+ * Allow where clause conditions to be in parenthesis (CASSANDRA-6037)
+ * Do not open non-ssl storage port if encryption option is all
(CASSANDRA-3916)
1.2.10
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb43309b/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index 2964d35..a199e83 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -413,45 +413,48 @@ public final class MessagingService implements
MessagingServiceMBean
logger.info("Starting Encrypted Messaging Service on SSL port {}",
DatabaseDescriptor.getSSLStoragePort());
}
-ServerSocketChannel serverChannel = null;
-try
-{
-serverChannel = ServerSocketChannel.open();
-}
-catch (IOException e)
-{
-throw new RuntimeException(e);
-}
-ServerSocket socket = serverChannel.socket();
-try
-{
-socket.setReuseAddress(true);
-}
-catch (SocketException e)
+if
(DatabaseDescriptor.getServerEncryptionOptions().internode_encryption !=
ServerEncryptionOptions.InternodeEncryption.all)
{
-throw new ConfigurationException("Insufficient permissions to
setReuseAddress", e);
-}
-InetSocketAddress address = new InetSocketAddress(localEp,
DatabaseDescriptor.getStoragePort());
-try
-{
-socket.bind(address);
-}
-catch (BindException e)
-{
-if (e.getMessage().contains("in use"))
-throw new ConfigurationException(address + " is in use by
another process. Change listen_address:storage_port in cassandra.yaml to
values that do not conflict with other services");
-else if (e.getMessage().contains("Cannot assign requested
address"))
-throw new ConfigurationException("Unable to bind to address "
+ address
- + ". Set listen_address in
cassandra.yaml to an interface you can bind to, e.g., your private IP address
on EC2");
-else
+ServerSocketChannel serverChannel = null;
+try
+{
+serverChannel = ServerSocketChannel.open();
+}
+catch (IOException e)
+{
throw new RuntimeException(e);
+}
+ServerSocket socket = serverChannel.socket();
+try
+{
+socket.setReuseAddress(true);
+}
+catch (SocketException e)
+{
+throw new ConfigurationException("Insufficient permissions to
setReuseAddress", e);
+}
+InetSocketAddress address = new InetSocketAddress(localEp,
DatabaseDescriptor.getStoragePort());
+try
+{
+socket.bind(address);
+}
+catch (BindException e)
+{
+if (e.getMessage().contains("in use"))
+throw new ConfigurationException(address + " is in use by
another process. Change listen_address:storage_port in cassandra.yaml to
values that do not conflict with other services");
+else if (e.getMessage().contains("Cannot assign requested
address"))
+throw new ConfigurationException("Unable to bind to
git commit: Do not open non-ssl storage port if encryption option is all patch by dbrosius reviewed by jbellis for cassandra-3916
Updated Branches:
refs/heads/cassandra-1.2 a0fa69715 -> fb43309b4
Do not open non-ssl storage port if encryption option is all
patch by dbrosius reviewed by jbellis for cassandra-3916
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fb43309b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fb43309b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fb43309b
Branch: refs/heads/cassandra-1.2
Commit: fb43309b4741372f777e8ce910cd496299a1ebbf
Parents: a0fa697
Author: Dave Brosius
Authored: Fri Sep 20 23:24:10 2013 -0400
Committer: Dave Brosius
Committed: Fri Sep 20 23:24:10 2013 -0400
--
CHANGES.txt | 2 +
.../apache/cassandra/net/MessagingService.java | 75 ++--
2 files changed, 41 insertions(+), 36 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb43309b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 27e6f24..b4681ae 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,7 @@
1.2.11
* Allow cache-keys-to-save to be set at runtime (CASSANDRA-5980)
+ * Allow where clause conditions to be in parenthesis (CASSANDRA-6037)
+ * Do not open non-ssl storage port if encryption option is all
(CASSANDRA-3916)
1.2.10
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fb43309b/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index 2964d35..a199e83 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -413,45 +413,48 @@ public final class MessagingService implements
MessagingServiceMBean
logger.info("Starting Encrypted Messaging Service on SSL port {}",
DatabaseDescriptor.getSSLStoragePort());
}
-ServerSocketChannel serverChannel = null;
-try
-{
-serverChannel = ServerSocketChannel.open();
-}
-catch (IOException e)
-{
-throw new RuntimeException(e);
-}
-ServerSocket socket = serverChannel.socket();
-try
-{
-socket.setReuseAddress(true);
-}
-catch (SocketException e)
+if
(DatabaseDescriptor.getServerEncryptionOptions().internode_encryption !=
ServerEncryptionOptions.InternodeEncryption.all)
{
-throw new ConfigurationException("Insufficient permissions to
setReuseAddress", e);
-}
-InetSocketAddress address = new InetSocketAddress(localEp,
DatabaseDescriptor.getStoragePort());
-try
-{
-socket.bind(address);
-}
-catch (BindException e)
-{
-if (e.getMessage().contains("in use"))
-throw new ConfigurationException(address + " is in use by
another process. Change listen_address:storage_port in cassandra.yaml to
values that do not conflict with other services");
-else if (e.getMessage().contains("Cannot assign requested
address"))
-throw new ConfigurationException("Unable to bind to address "
+ address
- + ". Set listen_address in
cassandra.yaml to an interface you can bind to, e.g., your private IP address
on EC2");
-else
+ServerSocketChannel serverChannel = null;
+try
+{
+serverChannel = ServerSocketChannel.open();
+}
+catch (IOException e)
+{
throw new RuntimeException(e);
+}
+ServerSocket socket = serverChannel.socket();
+try
+{
+socket.setReuseAddress(true);
+}
+catch (SocketException e)
+{
+throw new ConfigurationException("Insufficient permissions to
setReuseAddress", e);
+}
+InetSocketAddress address = new InetSocketAddress(localEp,
DatabaseDescriptor.getStoragePort());
+try
+{
+socket.bind(address);
+}
+catch (BindException e)
+{
+if (e.getMessage().contains("in use"))
+throw new ConfigurationException(address + " is in use by
another process. Change listen_address:storage_port in cassandra.yaml to
values that do not conflict with other services");
+else if (e.getMessage().contains("Cannot assign requested
address"))
+throw new ConfigurationException("Unable to bind to
[jira] [Commented] (CASSANDRA-3916) Do not bind the storage_port if internode_encryption = all
[ https://issues.apache.org/jira/browse/CASSANDRA-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773693#comment-13773693 ] Jonathan Ellis commented on CASSANDRA-3916: --- +1 > Do not bind the storage_port if internode_encryption = all > -- > > Key: CASSANDRA-3916 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3916 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.7 > Environment: Any >Reporter: Wade Poziombka >Assignee: Dave Brosius >Priority: Minor > Fix For: 1.2.11 > > Attachments: 3916.txt > > > We are highly security conscious and having additional clear text ports open > are undesirable. > I have modified locally to get around but it seems that this is a very > trivial fix to only bind the clear text storage_port if the > internode_encryption is not all. If all is selected then no clear text > communication should be permitted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4736) Cassandra should expose a native existence check API
[
https://issues.apache.org/jira/browse/CASSANDRA-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773691#comment-13773691
]
Jonathan Ellis commented on CASSANDRA-4736:
---
My point is that the performance difference between {{SELECT foo}} and {{SELECT
exists(foo)}} is small, unless foo is a blob.
> Cassandra should expose a native existence check API
>
>
> Key: CASSANDRA-4736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4736
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: sankalp kohli
>Priority: Minor
> Labels: features
>
> Currently Cassandra does not have an existence check API. Because of this,
> data needs to be read and thats how you know whether data is present or not.
> This is not optimal because one replica needs to provide data. Instead a new
> API could be exposed where each replica only sends out hash of the data.
> Repairs and other stuff can happen like a normal read call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4412) Add support for EACH_ONE consistency level for writes
[ https://issues.apache.org/jira/browse/CASSANDRA-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4412. --- Resolution: Won't Fix > Add support for EACH_ONE consistency level for writes > - > > Key: CASSANDRA-4412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4412 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Joseph Wayne Norton > Attachments: cassandra-1.0.7.txt > > > Add support for EACH_ONE consistency level for writes. > EACH_ONE A write must be written to the commit log and memory table of > at least one replica node in all data centers. > The purpose of this use case is to guarantee at least one successful write in > each data center before returning success to the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-6075) The token function should allow column identifiers in the correct order only
Michaël Figuière created CASSANDRA-6075:
---
Summary: The token function should allow column identifiers in the
correct order only
Key: CASSANDRA-6075
URL: https://issues.apache.org/jira/browse/CASSANDRA-6075
Project: Cassandra
Issue Type: Bug
Environment: Cassandra 1.2.9
Reporter: Michaël Figuière
Priority: Minor
Given the following table:
{code}
CREATE TABLE t1 (a int, b text, PRIMARY KEY ((a, b)));
{code}
The following request returns an error in cqlsh as literal arguments order is
incorrect:
{code}
SELECT * FROM t1 WHERE token(a, b) > token('s', 1);
Bad Request: Type error: 's' cannot be passed as argument 0 of function token
of type int
{code}
But surprisingly if we provide the column identifier arguments in the wrong
order no error is returned:
{code}
SELECT * FROM t1 WHERE token(a, b) > token(1, 'a'); // correct order is valid
SELECT * FROM t1 WHERE token(b, a) > token(1, 'a'); // incorrect order is valid
as well
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3916) Do not bind the storage_port if internode_encryption = all
[ https://issues.apache.org/jira/browse/CASSANDRA-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3916: Priority: Minor (was: Major) Fix Version/s: 1.2.11 > Do not bind the storage_port if internode_encryption = all > -- > > Key: CASSANDRA-3916 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3916 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.7 > Environment: Any >Reporter: Wade Poziombka >Assignee: Dave Brosius >Priority: Minor > Fix For: 1.2.11 > > Attachments: 3916.txt > > > We are highly security conscious and having additional clear text ports open > are undesirable. > I have modified locally to get around but it seems that this is a very > trivial fix to only bind the clear text storage_port if the > internode_encryption is not all. If all is selected then no clear text > communication should be permitted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3916) Do not bind the storage_port if internode_encryption = all
[ https://issues.apache.org/jira/browse/CASSANDRA-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3916: Attachment: 3916.txt > Do not bind the storage_port if internode_encryption = all > -- > > Key: CASSANDRA-3916 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3916 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.7 > Environment: Any >Reporter: Wade Poziombka >Assignee: Dave Brosius > Attachments: 3916.txt > > > We are highly security conscious and having additional clear text ports open > are undesirable. > I have modified locally to get around but it seems that this is a very > trivial fix to only bind the clear text storage_port if the > internode_encryption is not all. If all is selected then no clear text > communication should be permitted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4412) Add support for EACH_ONE consistency level for writes
[ https://issues.apache.org/jira/browse/CASSANDRA-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773673#comment-13773673 ] Joseph Wayne Norton commented on CASSANDRA-4412: Jonathan - Hello. I'm no longer working on this new feature. Please close this issue or leave it open if you think there is value to the Cassandra project and/or community. Best regards, Joe N. > Add support for EACH_ONE consistency level for writes > - > > Key: CASSANDRA-4412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4412 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Joseph Wayne Norton > Attachments: cassandra-1.0.7.txt > > > Add support for EACH_ONE consistency level for writes. > EACH_ONE A write must be written to the commit log and memory table of > at least one replica node in all data centers. > The purpose of this use case is to guarantee at least one successful write in > each data center before returning success to the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2443) Stream key/row caches during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773658#comment-13773658 ] Jeremiah Jordan commented on CASSANDRA-2443: Yeah, don't need to stream all the data from the caches, just the lists of keys. The new node could then pre-heat the caches before coming out of the bootstrap state. > Stream key/row caches during bootstrap > -- > > Key: CASSANDRA-2443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2443 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Priority: Minor > Labels: ponies > > When adding new nodes to an existing cluster, if we streamed key and row > caches over right before node came into cluster, we could minimize the impact > of a cold node, and reduce the time for the node to get 'warmed' up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6074) Read regression in 2.0.1
[ https://issues.apache.org/jira/browse/CASSANDRA-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McGuire updated CASSANDRA-6074: Description: I'm seeing a regression in stress reads introduced in 2.0.1. Note, that this is a separate regression from CASSANDRA-5933. Setup * 4 node cluster using default settings * Write: -F 3000 -n 3000 -i 5 -l 2 * Read: -n 3000 -o read -i 5 I tried this three times on 2.0.0 and on 2.0.1(tentative; eb96db6c) 2.0.0 is fine, but 2.0.1 timed out of it's read 2 out of the 3 times, and on the one that did succeed, it struggled quite a bit at the start: !stress 2.0.0 vs 2.0.01.png! [Data can be viewed here|http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.0.0v2.0.1.json&metric=interval_op_rate&operation=stress-read&smoothing=4] I will bisect and update this when I find the commit that introduced this. was: I'm seeing a regression in stress reads introduced in 2.0.1. Note, that this is a separate regression from CASSANDRA-5933. Setup * 4 node cluster using default settings * Write: -F 3000 -n 3000 -i 5 -l 2 * Read: -n 3000 -o read -i 5 I tried this three times on 2.0.0 and on 2.0.1(tentative; eb96db6c) 2.0.0 is fine, but 2.0.1 timed out of it's read 2 out of the 3 times: !stress 2.0.0 vs 2.0.01.png! [Data can be viewed here|http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.0.0v2.0.1.json&metric=interval_op_rate&operation=stress-read&smoothing=4] I will bisect and update this when I find the commit that introduced this. > Read regression in 2.0.1 > > > Key: CASSANDRA-6074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6074 > Project: Cassandra > Issue Type: Bug >Reporter: Ryan McGuire > Attachments: stress 2.0.0 vs 2.0.01.png > > > I'm seeing a regression in stress reads introduced in 2.0.1. Note, that this > is a separate regression from CASSANDRA-5933. > Setup > * 4 node cluster using default settings > * Write: -F 3000 -n 3000 -i 5 -l 2 > * Read: -n 3000 -o read -i 5 > I tried this three times on 2.0.0 and on 2.0.1(tentative; eb96db6c) > 2.0.0 is fine, but 2.0.1 timed out of it's read 2 out of the 3 times, and on > the one that did succeed, it struggled quite a bit at the start: > !stress 2.0.0 vs 2.0.01.png! > [Data can be viewed > here|http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.0.0v2.0.1.json&metric=interval_op_rate&operation=stress-read&smoothing=4] > I will bisect and update this when I find the commit that introduced this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6074) Read regression in 2.0.1
[ https://issues.apache.org/jira/browse/CASSANDRA-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McGuire updated CASSANDRA-6074: Description: I'm seeing a regression in stress reads introduced in 2.0.1. Note, that this is a separate regression from CASSANDRA-5933. Setup * 4 node cluster using default settings * Write: -F 3000 -n 3000 -i 5 -l 2 * Read: -n 3000 -o read -i 5 I tried this three times on 2.0.0 and on 2.0.1(tentative; eb96db6c) 2.0.0 is fine, but 2.0.1 timed out of it's read 2 out of the 3 times: !stress 2.0.0 vs 2.0.01.png! [Data can be viewed here|http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.0.0v2.0.1.json&metric=interval_op_rate&operation=stress-read&smoothing=4] I will bisect and update this when I find the commit that introduced this. was: I'm seeing a regression in stress reads introduced in 2.0.1. Setup * 4 node cluster using default settings * Write: -F 3000 -n 3000 -i 5 -l 2 * Read: -n 3000 -o read -i 5 I tried this three times on 2.0.0 and on 2.0.1(tentative; eb96db6c) 2.0.0 is fine, but 2.0.1 timed out of it's read 2 out of the 3 times: !stress 2.0.0 vs 2.0.01.png! [Data can be viewed here|http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.0.0v2.0.1.json&metric=interval_op_rate&operation=stress-read&smoothing=4] I will bisect and update this when I find the commit that introduced this. > Read regression in 2.0.1 > > > Key: CASSANDRA-6074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6074 > Project: Cassandra > Issue Type: Bug >Reporter: Ryan McGuire > Attachments: stress 2.0.0 vs 2.0.01.png > > > I'm seeing a regression in stress reads introduced in 2.0.1. Note, that this > is a separate regression from CASSANDRA-5933. > Setup > * 4 node cluster using default settings > * Write: -F 3000 -n 3000 -i 5 -l 2 > * Read: -n 3000 -o read -i 5 > I tried this three times on 2.0.0 and on 2.0.1(tentative; eb96db6c) > 2.0.0 is fine, but 2.0.1 timed out of it's read 2 out of the 3 times: > !stress 2.0.0 vs 2.0.01.png! > [Data can be viewed > here|http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.0.0v2.0.1.json&metric=interval_op_rate&operation=stress-read&smoothing=4] > I will bisect and update this when I find the commit that introduced this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-6074) Read regression in 2.0.1
Ryan McGuire created CASSANDRA-6074: --- Summary: Read regression in 2.0.1 Key: CASSANDRA-6074 URL: https://issues.apache.org/jira/browse/CASSANDRA-6074 Project: Cassandra Issue Type: Bug Reporter: Ryan McGuire Attachments: stress 2.0.0 vs 2.0.01.png I'm seeing a regression in stress reads introduced in 2.0.1. Setup * 4 node cluster using default settings * Write: -F 3000 -n 3000 -i 5 -l 2 * Read: -n 3000 -o read -i 5 I tried this three times on 2.0.0 and on 2.0.1(tentative; eb96db6c) 2.0.0 is fine, but 2.0.1 timed out of it's read 2 out of the 3 times: !stress 2.0.0 vs 2.0.01.png! [Data can be viewed here|http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.0.0v2.0.1.json&metric=interval_op_rate&operation=stress-read&smoothing=4] I will bisect and update this when I find the commit that introduced this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6074) Read regression in 2.0.1
[ https://issues.apache.org/jira/browse/CASSANDRA-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McGuire updated CASSANDRA-6074: Attachment: stress 2.0.0 vs 2.0.01.png > Read regression in 2.0.1 > > > Key: CASSANDRA-6074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6074 > Project: Cassandra > Issue Type: Bug >Reporter: Ryan McGuire > Attachments: stress 2.0.0 vs 2.0.01.png > > > I'm seeing a regression in stress reads introduced in 2.0.1. Note, that this > is a separate regression from CASSANDRA-5933. > Setup > * 4 node cluster using default settings > * Write: -F 3000 -n 3000 -i 5 -l 2 > * Read: -n 3000 -o read -i 5 > I tried this three times on 2.0.0 and on 2.0.1(tentative; eb96db6c) > 2.0.0 is fine, but 2.0.1 timed out of it's read 2 out of the 3 times: > !stress 2.0.0 vs 2.0.01.png! > [Data can be viewed > here|http://ryanmcguire.info/ds/graph/graph.html?stats=stats.2.0.0v2.0.1.json&metric=interval_op_rate&operation=stress-read&smoothing=4] > I will bisect and update this when I find the commit that introduced this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6072) NPE in Pig CassandraStorage
[ https://issues.apache.org/jira/browse/CASSANDRA-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-6072: --- Assignee: Alex Liu > NPE in Pig CassandraStorage > --- > > Key: CASSANDRA-6072 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6072 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Jeremiah Jordan >Assignee: Alex Liu > > key_alias can be null for tables created from thrift. > Which causes an NPE here: > https://github.com/apache/cassandra/blob/cassandra-1.2/src/java/org/apache/cassandra/hadoop/pig/AbstractCassandraStorage.java#L633 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6072) NPE in Pig CassandraStorage
[ https://issues.apache.org/jira/browse/CASSANDRA-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-6072: --- Summary: NPE in Pig CassandraStorage (was: key_alias can be null for tables created from thrift.) > NPE in Pig CassandraStorage > --- > > Key: CASSANDRA-6072 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6072 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Jeremiah Jordan > > key_alias can be null for tables created from thrift. > Which causes an NPE here: > https://github.com/apache/cassandra/blob/cassandra-1.2/src/java/org/apache/cassandra/hadoop/pig/AbstractCassandraStorage.java#L633 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4736) Cassandra should expose a native existence check API
[ https://issues.apache.org/jira/browse/CASSANDRA-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773581#comment-13773581 ] sankalp kohli commented on CASSANDRA-4736: -- No. We want to check whether a particular row and column exists in Cassnadra. > Cassandra should expose a native existence check API > > > Key: CASSANDRA-4736 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4736 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: sankalp kohli >Priority: Minor > Labels: features > > Currently Cassandra does not have an existence check API. Because of this, > data needs to be read and thats how you know whether data is present or not. > This is not optimal because one replica needs to provide data. Instead a new > API could be exposed where each replica only sends out hash of the data. > Repairs and other stuff can happen like a normal read call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4483) Restarting service
[ https://issues.apache.org/jira/browse/CASSANDRA-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4483. --- Resolution: Later > Restarting service > -- > > Key: CASSANDRA-4483 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4483 > Project: Cassandra > Issue Type: Improvement > Components: Core, Tools > Environment: CentOS release 6.2 (Final) >Reporter: Vladimir Barinov >Priority: Trivial > Labels: lhf > > Cassandra can't restart too quickly. > # /etc/init.d/cassandra status > cassandra (pid 6843) is running... > # /etc/init.d/cassandra restart > Shutdown Cassandra: OK > Starting Cassandra: OK > # /etc/init.d/cassandra status > cassandra is stopped > cassandra log: > xss = -ea -javaagent:/usr/share/cassandra//lib/jamm-0.2.5.jar > -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M > -Xmn200M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port > already in use: 7199; nested exception is: > java.net.BindException: Address already in use -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4458) PerRowSecondaryIndex will call buildIndexAsync multiple times for the same index
[ https://issues.apache.org/jira/browse/CASSANDRA-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4458: -- Assignee: Sam Tunnicliffe > PerRowSecondaryIndex will call buildIndexAsync multiple times for the same > index > > > Key: CASSANDRA-4458 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4458 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jonathan Ellis >Assignee: Sam Tunnicliffe >Priority: Minor > Fix For: 2.1 > > > Mailing list thread: > http://www.mail-archive.com/dev@cassandra.apache.org/msg04624.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6042) Add WARN when there are a lot of tombstones in a query
[ https://issues.apache.org/jira/browse/CASSANDRA-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6042: -- Reviewer: rspitzer (was: jjordan) > Add WARN when there are a lot of tombstones in a query > -- > > Key: CASSANDRA-6042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6042 > Project: Cassandra > Issue Type: Improvement >Reporter: Jeremiah Jordan >Assignee: Lyuben Todorov >Priority: Minor > Fix For: 1.2.11 > > > Now that we count the number of tombstones hit (so it can go in tracing), can > we pick some threshold (or make it configurable with 0 being don't warn), and > spit out a warning saying "Just went through 1 tombstones in partition > XYZ". > Right now if you are having GC problems because some row got a bunch of > tombstones, you can turn on server side tracing, and hope the bad query gets > in there, or you can keep making heap dumps, dig through them, and hope you > catch the query in there. > I have seen code problems at multiple places causing this same issue (some > code causing way more tombstones than it should, for just one row). And it > is a PITA+Luck to debug it right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6042) Add WARN when there are a lot of tombstones in a query
[ https://issues.apache.org/jira/browse/CASSANDRA-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6042: -- Reviewer: jjordan (was: rspitzer) Assignee: Russell Alexander Spitzer (was: Lyuben Todorov) > Add WARN when there are a lot of tombstones in a query > -- > > Key: CASSANDRA-6042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6042 > Project: Cassandra > Issue Type: Improvement >Reporter: Jeremiah Jordan >Assignee: Russell Alexander Spitzer >Priority: Minor > Fix For: 1.2.11 > > > Now that we count the number of tombstones hit (so it can go in tracing), can > we pick some threshold (or make it configurable with 0 being don't warn), and > spit out a warning saying "Just went through 1 tombstones in partition > XYZ". > Right now if you are having GC problems because some row got a bunch of > tombstones, you can turn on server side tracing, and hope the bad query gets > in there, or you can keep making heap dumps, dig through them, and hope you > catch the query in there. > I have seen code problems at multiple places causing this same issue (some > code causing way more tombstones than it should, for just one row). And it > is a PITA+Luck to debug it right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5540) Concurrent secondary index updates remove rows from the index
[
https://issues.apache.org/jira/browse/CASSANDRA-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773518#comment-13773518
]
Robert Coli commented on CASSANDRA-5540:
Oh, weird. I see "affects" in the history but don't see it in the "Details"
section.
Probably I just need to configure my JIRA better, sorry for the noise.
> Concurrent secondary index updates remove rows from the index
> -
>
> Key: CASSANDRA-5540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5540
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexei Bakanov
>Assignee: Sam Tunnicliffe
> Fix For: 1.2.5
>
> Attachments:
> 0001-Use-different-index-updater-for-live-updates-compact.patch, 5540.txt
>
>
> Existing rows disappear from secondary index when doing simultaneous updates
> of a row with the same secondary index value.
> Here is a little pycassa script that reproduces a bug. The script inserts 4
> rows with same secondary index value, reads those rows back and check that
> there are 4 of them.
> Please run two instances of the script simultaneously in two separate
> terminals in order to simulate concurrent updates:
> {code}
> -scrpit.py START-
> import pycassa
> from pycassa.index import *
> pool = pycassa.ConnectionPool('ks123')
> cf = pycassa.ColumnFamily(pool, 'cf1')
> while True:
> for rowKey in xrange(4):
> cf.insert(str(rowKey), {'indexedColumn': 'indexedValue'})
> index_expression = create_index_expression('indexedColumn',
> 'indexedValue')
> index_clause = create_index_clause([index_expression])
> rows = cf.get_indexed_slices(index_clause)
> length = len(list(rows))
> if length == 4:
> pass
> else:
> print 'found just %d rows out of 4' % length
> pool.dispose()
> ---script.py FINISH---
> ---schema cli start---
> create keyspace ks123
> with placement_strategy = 'NetworkTopologyStrategy'
> and strategy_options = {datacenter1 : 1}
> and durable_writes = true;
> use ks123;
> create column family cf1
> with column_type = 'Standard'
> and comparator = 'AsciiType'
> and default_validation_class = 'AsciiType'
> and key_validation_class = 'AsciiType'
> and read_repair_chance = 0.1
> and dclocal_read_repair_chance = 0.0
> and populate_io_cache_on_flush = false
> and gc_grace = 864000
> and min_compaction_threshold = 4
> and max_compaction_threshold = 32
> and replicate_on_write = true
> and compaction_strategy =
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
> and caching = 'KEYS_ONLY'
> and column_metadata = [
> {column_name : 'indexedColumn',
> validation_class : AsciiType,
> index_name : 'INDEX1',
> index_type : 0}]
> and compression_options = {'sstable_compression' :
> 'org.apache.cassandra.io.compress.SnappyCompressor'};
> ---schema cli finish---
> {code}
> Test cluster created with 'ccm create --cassandra-version 1.2.4 --nodes 1
> --start testUpdate'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4412) Add support for EACH_ONE consistency level for writes
[ https://issues.apache.org/jira/browse/CASSANDRA-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773514#comment-13773514 ] Jonathan Ellis commented on CASSANDRA-4412: --- Did you ever get around to testing this, Joseph? Is Cloudian using it, or is the requirement more theoretical? > Add support for EACH_ONE consistency level for writes > - > > Key: CASSANDRA-4412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4412 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Joseph Wayne Norton > Attachments: cassandra-1.0.7.txt > > > Add support for EACH_ONE consistency level for writes. > EACH_ONE A write must be written to the commit log and memory table of > at least one replica node in all data centers. > The purpose of this use case is to guarantee at least one successful write in > each data center before returning success to the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4440) Better output desired to diagnose hung bootstrap due to partial connectivity
[ https://issues.apache.org/jira/browse/CASSANDRA-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4440. --- Resolution: Won't Fix > Better output desired to diagnose hung bootstrap due to partial connectivity > > > Key: CASSANDRA-4440 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4440 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8.10 >Reporter: Thomas Whaples >Priority: Trivial > > I was attempting to set up a new node and bootstrap it into my cluster. > Due to an error in my network configuration, this node was able to > communicate with only a portion of the existing nodes (it could connect to 3 > out of 5 existing nodes). As a result, the node transferred some data, but > ultimately got stuck in a state of 'Joining' the cluster and not doing > anything. Unfortunately, it was a little tricky to diagnose. I only figured > it out when I turned on debug-level monitoring and saw a message about trying > to establish an outbound connection (not a *failure* to establish it, just a > note that it was trying to establish one. I'd quote it, but the debug logs > got rotated in the logspew.) > For posterity, I would like to request that a node in this sort of a > situation present additional messages or other diagnostics. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4332) IndexRangeSliceQuery results contain IndexColumn even though it is not included in SliceRange
[ https://issues.apache.org/jira/browse/CASSANDRA-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4332. --- Resolution: Cannot Reproduce > IndexRangeSliceQuery results contain IndexColumn even though it is not > included in SliceRange > - > > Key: CASSANDRA-4332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4332 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Roland Gude > Attachments: system.log, system.log, system.log > > > This is the magical reappearance of CASSANDRA-2964 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4387) Multiple RPC threads waiting on a single thread
[ https://issues.apache.org/jira/browse/CASSANDRA-4387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4387. --- Resolution: Cannot Reproduce > Multiple RPC threads waiting on a single thread > --- > > Key: CASSANDRA-4387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4387 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.7 > Environment: sun java 6.24 >Reporter: Jason Harvey >Priority: Minor > Attachments: output.log > > > I'm investigating a load spike issue on our cluster. A thread dump that I > collected during a spike shows a peculiar symptom. There are 162 RPC threads > all parked waiting on a single > java.util.concurrent.SynchronousQueue$TransferStack thread. Brandon took a > peek and recommended I create a ticket for investigation. > Full thread dump attached. The thread which is being waited on is > 0x0006ac1aba60. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4369) Sortable counter type for 'top N' type query use cases
[ https://issues.apache.org/jira/browse/CASSANDRA-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4369. --- Resolution: Won't Fix > Sortable counter type for 'top N' type query use cases > -- > > Key: CASSANDRA-4369 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4369 > Project: Cassandra > Issue Type: New Feature >Reporter: Ahmet AKYOL > Labels: ponies > > Current counter type is not sortable by values, AFAIK. Here's a related > question : > http://stackoverflow.com/questions/8428364/how-to-get-sorted-counters-from-cassandra > This feature can be very handy for 'top N' type query use cases like sorting > user points and finding top users in a reputation system. > Of course, support in CQL 3 is trivial. > IMHO, from implementation point of view, this looks unnatural to C* since C* > sorts column names not the values.Maybe a composite column solution like > (counter,char) is more proper but I can't imagine a way to make this work > right now, it doesn't make sense to me. On the other hand, it would be very > useful for us, the users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2568) Write only mode
[ https://issues.apache.org/jira/browse/CASSANDRA-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2568. --- Resolution: Duplicate > Write only mode > --- > > Key: CASSANDRA-2568 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2568 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Burroughs >Priority: Minor > > Allow a node to receive writes (which are relatively cheap) but not reads > (random io). The purpose is to allow a major compaction or repair to be run > on a node that is under too much load for this be safely done "live". > Marking a node as down by disabling gossip is good enough in some cases(for > major compaction). But for repairs is insufficient, since hints will build > back up once I repeat the process on the next node. > This is presumably a rather complicated change in to gossip to accommodate > the new state. I am also concerned of the effects of having different > numbers of nodes available for write and read quorums. > See also: http://www.mail-archive.com/dev@cassandra.apache.org/msg02240.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2568) Write only mode
[ https://issues.apache.org/jira/browse/CASSANDRA-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773558#comment-13773558 ] Jonathan Ellis commented on CASSANDRA-2568: --- Superceded by CASSANDRA-4839 > Write only mode > --- > > Key: CASSANDRA-2568 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2568 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Burroughs >Priority: Minor > > Allow a node to receive writes (which are relatively cheap) but not reads > (random io). The purpose is to allow a major compaction or repair to be run > on a node that is under too much load for this be safely done "live". > Marking a node as down by disabling gossip is good enough in some cases(for > major compaction). But for repairs is insufficient, since hints will build > back up once I repeat the process on the next node. > This is presumably a rather complicated change in to gossip to accommodate > the new state. I am also concerned of the effects of having different > numbers of nodes available for write and read quorums. > See also: http://www.mail-archive.com/dev@cassandra.apache.org/msg02240.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4839) Online toggle for node write-only status
[ https://issues.apache.org/jira/browse/CASSANDRA-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773559#comment-13773559 ] Jonathan Ellis commented on CASSANDRA-4839: --- Still on your list, Rick? > Online toggle for node write-only status > > > Key: CASSANDRA-4839 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4839 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Rick Branson >Priority: Minor > Attachments: 4839_revised.txt, 4839.txt > > > It would be really great if users could disable/enable reads on a given node, > while still allowing write operations to take place. This would be similar to > how we enable/disable thrift and gossip using JMX. > The scenario for using this is that often a node needs to be brought down for > maintenance for a few minutes, and while the node is catching up from hints, > which can take 10-30 minutes depending on write load, it will serve stale > data. Do the math for a rolling restart of a large cluster and you have > potential windows of hours or days where a large amount of inconsistency is > surfacing. > Avoiding this large time gap of inconsistency during regular maintenance > alleviates concerns about inconsistent data surfaced to users during normal, > planned activities. While a read consistency >ONE can indeed be used to > prevent any inconsistency from the scenario above, it seems ridiculous to > always incur the cost to cover the 0.1% case. > In addition, it would open up the ability for a node to (optionally) > automatically "go dark" for reads while it's receiving hints after joining > the cluster or perhaps during repair. These obviously have their own > complications and justify separate tickets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-6042) Add WARN when there are a lot of tombstones in a query
[ https://issues.apache.org/jira/browse/CASSANDRA-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773557#comment-13773557 ] Jonathan Ellis commented on CASSANDRA-6042: --- (Search for the string "tombstoned" for where we're tracing it.) > Add WARN when there are a lot of tombstones in a query > -- > > Key: CASSANDRA-6042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6042 > Project: Cassandra > Issue Type: Improvement >Reporter: Jeremiah Jordan >Assignee: Lyuben Todorov >Priority: Minor > Fix For: 1.2.11 > > > Now that we count the number of tombstones hit (so it can go in tracing), can > we pick some threshold (or make it configurable with 0 being don't warn), and > spit out a warning saying "Just went through 1 tombstones in partition > XYZ". > Right now if you are having GC problems because some row got a bunch of > tombstones, you can turn on server side tracing, and hope the bad query gets > in there, or you can keep making heap dumps, dig through them, and hope you > catch the query in there. > I have seen code problems at multiple places causing this same issue (some > code causing way more tombstones than it should, for just one row). And it > is a PITA+Luck to debug it right now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4268) Expose full stop() operation through JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4268: -- Assignee: Tyler Hobbs > Expose full stop() operation through JMX > > > Key: CASSANDRA-4268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4268 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs >Priority: Minor > Labels: jmx > > We already expose ways to stop just the RPC server or gossip. This would > fully shutdown the process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5672) Add enumumerated column to system_trace.events table to signify the type of event.
[ https://issues.apache.org/jira/browse/CASSANDRA-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5672: -- Fix Version/s: (was: 2.1) Assignee: (was: Tyler Hobbs) > Add enumumerated column to system_trace.events table to signify the type of > event. > -- > > Key: CASSANDRA-5672 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5672 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Ryan McGuire >Priority: Minor > > Tracing of queries is useful for at least two different purposes: > * Interactively diagnosing a problem, via cqlsh, by a human. > * Programatically recording and responding to how queries behave. > This second purpose is not well suited to how the system_trace.events table > is currently organized, as the only identifying characteristic of each event > is a free-form string that can (and has) been changed in later versions. > [~jbellis] [mentioned the > possibility|http://www.datastax.com/dev/blog/advanced-request-tracing-in-cassandra-1-2] > of adding an enumeration of event types that would be immutable. > Reference [this > dtest|https://github.com/riptano/cassandra-dtest/pull/13/files] that parses > the strings in this table via regex. If these strings change, this test will > break. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6024) sstableloader uploads full range sstable into some single range node(s) only
[ https://issues.apache.org/jira/browse/CASSANDRA-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6024: -- Priority: Major (was: Critical) > sstableloader uploads full range sstable into some single range node(s) only > > > Key: CASSANDRA-6024 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6024 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools > Environment: CentOS x64, Oracle JDK 7u17 x64, Cassandra 1.2.9 >Reporter: Viktor Jevdokimov >Assignee: Yuki Morishita > > sstableloader from 1.2.9 uploads full-size sstables (not divided by token > ranges) generated with SSTableSimpleUnsortedWriter (no compression options) > into Cassandra 1.2.9 nodes of some single token range (on different clusters > may be different range, but the same on the same cluster). > sstableloader from Cassandra 1.2.6 uploads to Cassandra 1.2.9 nodes as > expected, sstables sent divided by token ranges. > VNodes are not used, partitioner is RandomPartitioner. > In both cases with 1.2.6 and 1.2.9 all sstables files generated the same, no > binary difference. > All target nodes returns correct token ranges. > example 1: > 3 nodes, 1 DC, RF=2, 2 out of 3 nodes receives 100% of sstable data instead > of 66.6%, rest node receives nothing. > example 2: > 32 nodes, 4 DCs, 8 nodes per DC, each DC RF=1 (total RF=4), same range node > in each DC receives 100% of sstable instead of 1/8 (cleanup will remove 7/8 > of received data), other nodes receives nothing. > excerpts from sstableloader log when node does not receive a data: > INFO [main] 2013-09-13 01:03:41,336 Stream context metadata [], 2 sstables. > INFO [main] 2013-09-13 01:03:41,338 Streaming to /1.2.3.4 > DEBUG [main] 2013-09-13 01:03:41,349 Files are > DEBUG [Streaming to /1.2.3.4:1] 2013-09-13 01:03:41,448 Received StreamReply > StreamReply(sessionId=90e67680-1bff-11e3-b6f0-7df633a2f7a1, file='', > action=SESSION_FINISHED) > DEBUG [Streaming to /1.2.3.4:1] 2013-09-13 01:03:41,448 closing with status > true > INFO [Streaming to /1.2.3.4:1] 2013-09-13 01:03:41,449 Finished streaming > session to /1.2.3.4 > DEBUG [Streaming to /1.2.3.4:1] 2013-09-13 01:03:41,450 Done streaming null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4165) Generate Digest file for compressed SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4165: -- Assignee: Marcus Eriksson > Generate Digest file for compressed SSTables > > > Key: CASSANDRA-4165 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4165 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Minor > Attachments: 0001-Generate-digest-for-compressed-files-as-well.patch, > 4165-rebased.txt > > > We use the generated *Digest.sha1-files to verify backups, would be nice if > they were generated for compressed sstables as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4209) Randomly getting "Invalid bytes remaining after an end-of-component at component1" exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-4209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4209.
---
Resolution: Cannot Reproduce
> Randomly getting "Invalid bytes remaining after an end-of-component at
> component1" exceptions
> -
>
> Key: CASSANDRA-4209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4209
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.9
> Environment: Linux version 2.6.21.7-2.fc8xen
> (mockbu...@xenbuilder4.fedora.phx.redhat.com)
>Reporter: Alon Peer
>
> I have a CF with composite column sort:
> {noformat}
> ColumnFamily: MyCF
> 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.CompositeType(org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.IntegerType)
> Row cache size / save period in seconds / keys to save : 0.0/0/all
> Row Cache Provider: org.apache.cassandra.cache.SerializingCacheProvider
> Key cache size / save period in seconds: 20.0/14400
> GC grace seconds: 864000
> Compaction min/max thresholds: 4/32
> Read repair chance: 0.1
> Replicate on write: true
> Bloom Filter FP chance: default
> Built indexes: []
> Compaction Strategy:
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
> Compression Options:
> chunk_length_kb: 64
> sstable_compression: org.apache.cassandra.io.compress.SnappyCompressor
> {noformat}
> I'm using [phpcassa|https://github.com/thobbs/phpcassa] to communicate with
> my Cassandra cluster.
> I'm getting the following exception from time to time while reading/writing
> to this CF:
> {noformat}
> exception 'cassandra_InvalidRequestException' with message
> 'Invalid bytes remaining after an end-of-component at component1' in
> /phpcassa/thrift/packages/cassandra/Cassandra.php:256\nStack trace:
> #0 /phpcassa/thrift/packages/cassandra/Cassandra.php(256):
> thrift_protocol_read_binary(Object(TBinaryProtocolAccelerated),
> 'cassandra_Cassa...', false)
> #1 /phpcassa/thrift/packages/cassandra/Cassandra.php(229):
> CassandraClient->recv_get_slice()
> #2 [internal function]: CassandraClient->get_slice('6034-28141406',
> Object(cassandra_ColumnParent), Object(cassandra_SlicePredicate), 2)
> ...
> {noformat}
> I've thoroughly checked my code, I'm always sending the same parameters to
> Cassandra, and there's no format error. My column name request is always
> AsciiType:IntegerType.
> The weird part is that this is completely random. If I run a get() query
> once, I get the exception, but the following request with the same parameters
> succeeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4165) Generate Digest file for compressed SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773543#comment-13773543 ] Vijay commented on CASSANDRA-4165: -- Hi Jonathan, 3648 actually adds block level CRC for uncompressed files and writes to a separate file (CRC.db), and uses it during the streaming parts of the file to validate before streaming (not during normal reads). Hence we need 2 Checksums during the flush 1 for blocks and the md5 for the whole file. > Generate Digest file for compressed SSTables > > > Key: CASSANDRA-4165 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4165 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Minor > Attachments: 0001-Generate-digest-for-compressed-files-as-well.patch, > 4165-rebased.txt > > > We use the generated *Digest.sha1-files to verify backups, would be nice if > they were generated for compressed sstables as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4663) Streaming sends one file at a time serially.
[ https://issues.apache.org/jira/browse/CASSANDRA-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773537#comment-13773537 ] Jonathan Ellis commented on CASSANDRA-4663: --- So we can close this as Duplicate, right? > Streaming sends one file at a time serially. > - > > Key: CASSANDRA-4663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4663 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: sankalp kohli >Priority: Minor > Labels: perfomance > > This is not fast enough when someone is using SSD and may be 10G link. We > should try to create multiple connections and send multiple files in > parallel. > Current approach under utilize the link(even 1G). > This change will improve the bootstrapping time of a node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4817) Update sstable2json for 1.1.x
[ https://issues.apache.org/jira/browse/CASSANDRA-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4817. --- Resolution: Fixed > Update sstable2json for 1.1.x > - > > Key: CASSANDRA-4817 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4817 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Joaquin Casares >Priority: Minor > Labels: datastax_qa > > This format is still needed in 1.1.5: > bin/json2sstable -K KS -c CF CF.json KS-CF-he-2-Data.db > to comply with this method: > https://github.com/apache/cassandra/blob/cassandra-1.1.5/src/java/org/apache/cassandra/io/sstable/Descriptor.java#L160 > even though 1.1.x now uses the directory structure KS/CF/CF-he-2-Data.db. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4818) Update sstableloader for 1.1.x
[
https://issues.apache.org/jira/browse/CASSANDRA-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4818.
---
Resolution: Fixed
> Update sstableloader for 1.1.x
> --
>
> Key: CASSANDRA-4818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4818
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Joaquin Casares
> Labels: datastax_qa
>
> This was done on Cassandra 1.1.5:
> {CODE}
> $ ls -1 Keyspace1/Keyspace1/Standard1/
> Standard1-51-Data.db
> Standard1-51-Index.db
> Standard1-hc-51-Data.db
> Standard1-hc-51-Index.db
> Standard1-tmp-hc-46-Data.db
> Standard1-tmp-hc-46-Index.db
> $ ~/repos/cassandra/bin/sstableloader -d localhost
> Keyspace1/Keyspace1/Standard1/
> WARN 15:41:56,023 Invalid file 'Standard1-51-Data.db' in data directory
> Keyspace1/Keyspace1/Standard1.
> WARN 15:41:56,024 Invalid file 'Standard1-51-Index.db' in data directory
> Keyspace1/Keyspace1/Standard1.
> Skipping file Standard1-hc-51-Data.db: column family Keyspace1.hc doesn't
> exist
> Skipping file Standard1-tmp-hc-46-Data.db: column family Keyspace1.tmp
> doesn't exist
> No sstables to stream
> progress: [total: 100 - 0MB/s (avg: 0MB/s)]
> {CODE}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4736) Cassandra should expose a native existence check API
[
https://issues.apache.org/jira/browse/CASSANDRA-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773551#comment-13773551
]
Jonathan Ellis commented on CASSANDRA-4736:
---
So basically, {{SELECT exists(foo) ... }}? Are you storing large blobs?
> Cassandra should expose a native existence check API
>
>
> Key: CASSANDRA-4736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4736
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: sankalp kohli
>Priority: Minor
> Labels: features
>
> Currently Cassandra does not have an existence check API. Because of this,
> data needs to be read and thats how you know whether data is present or not.
> This is not optimal because one replica needs to provide data. Instead a new
> API could be exposed where each replica only sends out hash of the data.
> Repairs and other stuff can happen like a normal read call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4758) Allow throttling bulk load separately from streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773548#comment-13773548 ] Jonathan Ellis commented on CASSANDRA-4758: --- Why would we want to throttle bulk load separate from other streaming, in the first place? > Allow throttling bulk load separately from streaming > > > Key: CASSANDRA-4758 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4758 > Project: Cassandra > Issue Type: Improvement >Reporter: Nick Bailey > Labels: ponies > > Currently when you call the bulkload jmx call, the only way to achieve > throttling is by tuning the streaming throttle in general, which affects all > streaming operations. > It would be nice to be able to throttle bulk loading separately. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4638) Patch to bin/cassandra to use 64bit JVM if available
[ https://issues.apache.org/jira/browse/CASSANDRA-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4638: -- Reviewer: urandom (was: eevans) > Patch to bin/cassandra to use 64bit JVM if available > > > Key: CASSANDRA-4638 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4638 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.1.4 > Environment: Tested on Solaris 11 with Oracle supplied JVM 1.6 and 1.7 >Reporter: Bernhard Roth > Labels: 64bit, linux, solaris > Attachments: cassandra.patch > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Cassandra uses by default the JAVA binary at $JAVA_HOME/bin and complains at > start that the 64bit version should be used. > Well, even if the 64bit JAVA version is installed, cassandra still does not > use it. > Attached patch solves this problem by checking if $JAVA_HOME/bin/amd64/java > binary exists. If yes, it will be used for cassandra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4638) Patch to bin/cassandra to use 64bit JVM if available
[ https://issues.apache.org/jira/browse/CASSANDRA-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773530#comment-13773530 ] Jonathan Ellis commented on CASSANDRA-4638: --- Well, that didn't work very well did it, [~urandom]? > Patch to bin/cassandra to use 64bit JVM if available > > > Key: CASSANDRA-4638 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4638 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.1.4 > Environment: Tested on Solaris 11 with Oracle supplied JVM 1.6 and 1.7 >Reporter: Bernhard Roth > Labels: 64bit, linux, solaris > Attachments: cassandra.patch > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Cassandra uses by default the JAVA binary at $JAVA_HOME/bin and complains at > start that the 64bit version should be used. > Well, even if the 64bit JAVA version is installed, cassandra still does not > use it. > Attached patch solves this problem by checking if $JAVA_HOME/bin/amd64/java > binary exists. If yes, it will be used for cassandra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-6073) Changes for Pig collections break CQL prepared statements
Chad Johnston created CASSANDRA-6073: Summary: Changes for Pig collections break CQL prepared statements Key: CASSANDRA-6073 URL: https://issues.apache.org/jira/browse/CASSANDRA-6073 Project: Cassandra Issue Type: Bug Components: Hadoop Environment: 1.2.10-tentative branch Reporter: Chad Johnston I've checked out and built the 1.2.10-tentative branch, and I've noticed that all of my CQL prepared statements are now broken. Looking into the code, it looks like the "#" -> "=" and "@" -> "?" translations were removed. I tried to replace these in one of my scripts with "=" and "?", but there's other code that splits the query string on "=", causing the prepared statement to be malformed. If I look at the comments on https://issues.apache.org/jira/browse/CASSANDRA-5867, where this change was made, I see a single mention of URL encoding the CQL query. Is this the expectation going forward? Was there a reason that the "#" and "@" mappings were removed? Further: I've tried URL encoding, and changing the CqlStorage code back to its previous behavior. I get the same error in this case of a long being a different size than expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-6072) key_alias can be null for tables created from thrift.
Jeremiah Jordan created CASSANDRA-6072: -- Summary: key_alias can be null for tables created from thrift. Key: CASSANDRA-6072 URL: https://issues.apache.org/jira/browse/CASSANDRA-6072 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Jeremiah Jordan key_alias can be null for tables created from thrift. Which causes an NPE here: https://github.com/apache/cassandra/blob/cassandra-1.2/src/java/org/apache/cassandra/hadoop/pig/AbstractCassandraStorage.java#L633 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4725) VERSION string conflict in C++ programs
[ https://issues.apache.org/jira/browse/CASSANDRA-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4725. --- Resolution: Won't Fix > VERSION string conflict in C++ programs > --- > > Key: CASSANDRA-4725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4725 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jochen Topf > > In cassandra.thrift there is a definition like this: > const string VERSION = "19.32.0" > When building the C++ code with thrift, this leads to a file > cassandra_constants.h and cassandra_constants.cpp which contain the following > lines: > cassandra_constants.cpp: VERSION = "19.32.0"; > cassandra_constants.h: std::string VERSION; > Unfortunately "VERSION" is all uppercase, this is generally used in macros in > C++ and the macro "VERSION" is used in many programs for instance when using > GNU autoconf. If there is a VERSION macro it will be expanded and those lines > will break. > Maybe we can rename this to "Version" or so? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4603) use Map internally in schema_ tables where appropriate
[
https://issues.apache.org/jira/browse/CASSANDRA-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773528#comment-13773528
]
Jonathan Ellis commented on CASSANDRA-4603:
---
bq. we'd be able to remove them in 2.1 provided we formalize that 2.0 is a
mandatory stop before upgrading to 2.1+.
We've already signed up for that (CASSANDRA-5996).
> use Map internally in schema_ tables where appropriate
> --
>
> Key: CASSANDRA-4603
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4603
> Project: Cassandra
> Issue Type: Improvement
> Components: API, Core
>Affects Versions: 1.2.0
>Reporter: Jonathan Ellis
>Priority: Minor
> Labels: cql3
> Fix For: 2.1
>
>
> {replication, compression, compaction}_parameters should be stored as Map
> type.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4725) VERSION string conflict in C++ programs
[ https://issues.apache.org/jira/browse/CASSANDRA-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773545#comment-13773545 ] Jonathan Ellis commented on CASSANDRA-4725: --- Doesn't seem like it's worth breaking existing clients to fix this; new clients should use native protocol instead. > VERSION string conflict in C++ programs > --- > > Key: CASSANDRA-4725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4725 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jochen Topf > > In cassandra.thrift there is a definition like this: > const string VERSION = "19.32.0" > When building the C++ code with thrift, this leads to a file > cassandra_constants.h and cassandra_constants.cpp which contain the following > lines: > cassandra_constants.cpp: VERSION = "19.32.0"; > cassandra_constants.h: std::string VERSION; > Unfortunately "VERSION" is all uppercase, this is generally used in macros in > C++ and the macro "VERSION" is used in many programs for instance when using > GNU autoconf. If there is a VERSION macro it will be expanded and those lines > will break. > Maybe we can rename this to "Version" or so? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4521) OutboundTcpConnection could drop outgoing messages and not log it.
[ https://issues.apache.org/jira/browse/CASSANDRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4521. --- Resolution: Duplicate > OutboundTcpConnection could drop outgoing messages and not log it. > --- > > Key: CASSANDRA-4521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4521 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.0 beta 1 > Environment: trunk >Reporter: sankalp kohli >Priority: Minor > Labels: message > Original Estimate: 0.1h > Remaining Estimate: 0.1h > > Since there is one connection between two nodes and all writes are handled by > single thread, there is a chance that a message gets old enough and is > dropped in OutboundTcpConnection. These dropped message does not get logged > by MessageService. > We should definitely log these. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4165) Generate Digest file for compressed SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4165: -- Attachment: 4165-rebased.txt We've had CASSANDRA-5791 come up as well, so I think it's reasonable to say that this is useful for more than just Spotify. Attached is Marcus's patch rebased to 2.0, but we may need to dig a little deeper; I'm not quite sure what the right treatment of the CRC component is, but it appears to duplicate the inline checksum that we compute for the compressed writer which seems odd. Git places the blame on CASSANDRA-3648. Any light to shed [~vijay2...@yahoo.com] [~jasobrown]? > Generate Digest file for compressed SSTables > > > Key: CASSANDRA-4165 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4165 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Priority: Minor > Attachments: 0001-Generate-digest-for-compressed-files-as-well.patch, > 4165-rebased.txt > > > We use the generated *Digest.sha1-files to verify backups, would be nice if > they were generated for compressed sstables as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-1632) Thread workflow and cpu affinity
[ https://issues.apache.org/jira/browse/CASSANDRA-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown reassigned CASSANDRA-1632: -- Assignee: Jason Brown > Thread workflow and cpu affinity > > > Key: CASSANDRA-1632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1632 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Goffinet >Assignee: Jason Brown > > Here are some thoughts I wanted to write down, we need to run some serious > benchmarks to see the benefits: > 1) All thread pools for our stages use a shared queue per stage. For some > stages we could move to a model where each thread has its own queue. This > would reduce lock contention on the shared queue. This workload only suits > the stages that have no variance, else you run into thread starvation. Some > stages that this might work: ROW-MUTATION. > 2) Set cpu affinity for each thread in each stage. If we can pin threads to > specific cores, and control the workflow of a message from Thrift down to > each stage, we should see improvements on reducing L1 cache misses. We would > need to build a JNI extension (to set cpu affinity), as I could not find > anywhere in JDK where it was exposed. > 3) Batching the delivery of requests across stage boundaries. Peter Schuller > hasn't looked deep enough yet into the JDK, but he thinks there may be > significant improvements to be had there. Especially in high-throughput > situations. If on each consumption you were to consume everything in the > queue, rather than implying a synchronization point in between each request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1632) Thread workflow and cpu affinity
[ https://issues.apache.org/jira/browse/CASSANDRA-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773430#comment-13773430 ] Stu Hood commented on CASSANDRA-1632: - Regarding 1): ForkJoinPool implements per-worker queues with work-stealing to deal with this problem. Would be interesting to just drop ForkJoinPool in and see how it does. > Thread workflow and cpu affinity > > > Key: CASSANDRA-1632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1632 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Goffinet >Assignee: Jason Brown > > Here are some thoughts I wanted to write down, we need to run some serious > benchmarks to see the benefits: > 1) All thread pools for our stages use a shared queue per stage. For some > stages we could move to a model where each thread has its own queue. This > would reduce lock contention on the shared queue. This workload only suits > the stages that have no variance, else you run into thread starvation. Some > stages that this might work: ROW-MUTATION. > 2) Set cpu affinity for each thread in each stage. If we can pin threads to > specific cores, and control the workflow of a message from Thrift down to > each stage, we should see improvements on reducing L1 cache misses. We would > need to build a JNI extension (to set cpu affinity), as I could not find > anywhere in JDK where it was exposed. > 3) Batching the delivery of requests across stage boundaries. Peter Schuller > hasn't looked deep enough yet into the JDK, but he thinks there may be > significant improvements to be had there. Especially in high-throughput > situations. If on each consumption you were to consume everything in the > queue, rather than implying a synchronization point in between each request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5632) Cross-DC bandwidth-saving broken
[
https://issues.apache.org/jira/browse/CASSANDRA-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773487#comment-13773487
]
Jeremy Hanna commented on CASSANDRA-5632:
-
I believe for the issue that was fixed here it originated in 1.2 and was
present up through 1.2.5.
> Cross-DC bandwidth-saving broken
>
>
> Key: CASSANDRA-5632
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5632
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
>Reporter: Jonathan Ellis
>Assignee: Jonathan Ellis
> Fix For: 1.2.6
>
> Attachments: 5632.txt, 5632-v2.txt, cassandra-topology.properties,
> fix_patch_bug.log
>
>
> We group messages by destination as follows to avoid sending multiple
> messages to a remote datacenter:
> {code}
> // Multimap that holds onto all the messages and addresses meant for
> a specific datacenter
> Map> dcMessages
> {code}
> When we cleaned out the MessageProducer stuff for 2.0, this code
> {code}
> Multimap messages =
> dcMessages.get(dc);
> ...
>
> messages.put(producer.getMessage(Gossiper.instance.getVersion(destination)),
> destination);
> {code}
> turned into
> {code}
> Multimap messages =
> dcMessages.get(dc);
> ...
> messages.put(rm.createMessage(), destination);
> {code}
> Thus, we weren't actually grouping anything anymore -- each destination
> replica was stored under a separate Message key, unlike under the old
> CachingMessageProducer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5540) Concurrent secondary index updates remove rows from the index
[
https://issues.apache.org/jira/browse/CASSANDRA-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773309#comment-13773309
]
Jonathan Ellis commented on CASSANDRA-5540:
---
No, affects 1.2.0+ as indicated.
> Concurrent secondary index updates remove rows from the index
> -
>
> Key: CASSANDRA-5540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5540
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexei Bakanov
>Assignee: Sam Tunnicliffe
> Fix For: 1.2.5
>
> Attachments:
> 0001-Use-different-index-updater-for-live-updates-compact.patch, 5540.txt
>
>
> Existing rows disappear from secondary index when doing simultaneous updates
> of a row with the same secondary index value.
> Here is a little pycassa script that reproduces a bug. The script inserts 4
> rows with same secondary index value, reads those rows back and check that
> there are 4 of them.
> Please run two instances of the script simultaneously in two separate
> terminals in order to simulate concurrent updates:
> {code}
> -scrpit.py START-
> import pycassa
> from pycassa.index import *
> pool = pycassa.ConnectionPool('ks123')
> cf = pycassa.ColumnFamily(pool, 'cf1')
> while True:
> for rowKey in xrange(4):
> cf.insert(str(rowKey), {'indexedColumn': 'indexedValue'})
> index_expression = create_index_expression('indexedColumn',
> 'indexedValue')
> index_clause = create_index_clause([index_expression])
> rows = cf.get_indexed_slices(index_clause)
> length = len(list(rows))
> if length == 4:
> pass
> else:
> print 'found just %d rows out of 4' % length
> pool.dispose()
> ---script.py FINISH---
> ---schema cli start---
> create keyspace ks123
> with placement_strategy = 'NetworkTopologyStrategy'
> and strategy_options = {datacenter1 : 1}
> and durable_writes = true;
> use ks123;
> create column family cf1
> with column_type = 'Standard'
> and comparator = 'AsciiType'
> and default_validation_class = 'AsciiType'
> and key_validation_class = 'AsciiType'
> and read_repair_chance = 0.1
> and dclocal_read_repair_chance = 0.0
> and populate_io_cache_on_flush = false
> and gc_grace = 864000
> and min_compaction_threshold = 4
> and max_compaction_threshold = 32
> and replicate_on_write = true
> and compaction_strategy =
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
> and caching = 'KEYS_ONLY'
> and column_metadata = [
> {column_name : 'indexedColumn',
> validation_class : AsciiType,
> index_name : 'INDEX1',
> index_type : 0}]
> and compression_options = {'sstable_compression' :
> 'org.apache.cassandra.io.compress.SnappyCompressor'};
> ---schema cli finish---
> {code}
> Test cluster created with 'ccm create --cassandra-version 1.2.4 --nodes 1
> --start testUpdate'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-6071) CqlStorage loading compact table adds an extraneous field to the pig schema
[
https://issues.apache.org/jira/browse/CASSANDRA-6071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6071:
--
Reviewer: brandon.williams
> CqlStorage loading compact table adds an extraneous field to the pig schema
> ---
>
> Key: CASSANDRA-6071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6071
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 1.2.11
>
> Attachments: 6071.txt
>
>
> {code}
> CREATE TABLE t (
> key text,
> field1 int,
> field2 int
> PRIMARY KEY (key, field1)
> ) WITH COMPACT STORAGE;
> INSERT INTO t (key,field1,field2) VALUES ('key1',1,2);
> INSERT INTO t (key,field1,field2) VALUES ('key2',1,2);
> INSERT INTO t (key,field1,field2) VALUES ('key3',1,2);
> {code}
> {code}
> grunt> t = LOAD 'cql://ks/t' USING CqlStorage();
> grunt> describe t;
> t: {key: chararray,field1: int,field2: int,value: int}
> dump t;
> (key1,1,2,)
> (key3,1,2,)
> (key2,1,2,)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3998) CLI: NUL character for data not visible
[
https://issues.apache.org/jira/browse/CASSANDRA-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3998.
---
Resolution: Won't Fix
> CLI: NUL character for data not visible
> ---
>
> Key: CASSANDRA-3998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3998
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.8
>Reporter: Tyler Hobbs
>
> When using UTF8Type or AsciiType, if a column name or value is only 0x00
> bytes, the CLI will not show any indication that data is there. Here's an
> example where the column value is "0x00":
> {noformat}
> [default@Foo] get Foo2['key'];
> => (column=a, value=, timestamp=1330925963085434)
> {noformat}
> I'm not sure what the best solution is, but the current behavior is deceptive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3487) better repair session timeouts and retrys
[ https://issues.apache.org/jira/browse/CASSANDRA-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3487. --- Resolution: Won't Fix > better repair session timeouts and retrys > - > > Key: CASSANDRA-3487 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3487 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Vijay >Priority: Minor > Fix For: 2.1 > > > It would be great if we can timeout a validation compaction which is taking > long or had an exception while doing a Validation. > Repair can gossip its status to all the other nodes, hence any node which is > waiting for response of a "tree request" to wait until it complete, if the > repair is not going to complete because of exception or because it is too > busy taking the incoming request we can timeout the user request. > Bonus: By displaying the repair gossip via nodetool, user/script running the > request can have a better handle on whats going on in the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3889) malformed UPDATE queries causing NumberFormatException, AssertionError
[
https://issues.apache.org/jira/browse/CASSANDRA-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3889.
---
Resolution: Won't Fix
> malformed UPDATE queries causing NumberFormatException, AssertionError
> --
>
> Key: CASSANDRA-3889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3889
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
> Environment: Cassandra 1.1
>Reporter: paul cannon
>Priority: Minor
> Labels: cql
>
> Given a columnfamily like:
> {code}
> CREATE TABLE CounterCF (KEY text PRIMARY KEY, count_me counter)
> WITH comparator = ascii AND default_validation = counter;
> {code}
> This query causes Cassandra to throw a NumberFormatException and close the
> thrift connection (yes, it's not valid, cause it's a counter CF)
> {code}
> UPDATE CounterCF SET count_me = count_me + 2, x = 'a' WHERE key = 'counter1';
> {code}
> And this variant causes an AssertionError and a permanently unresponsive
> thrift connection:
> {code}
> update CounterCF set count_me=count_me+2, x='' where key = 'counter1';
> {code}
> When a valid hex string (with a multiple of 2 hex digits) is used instead of
> 'a' or '', then the expected InvalidRequestException is seen.
> This is related to CASSANDRA-2851, but seems unimportant and incidental
> enough that a new ticket is more appropriate than reopening that one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5791) A nodetool command to validate all sstables in a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5791: -- Assignee: (was: Lyuben Todorov) Okay, sounds like we're feature creeping a bit here. CASSANDRA-4165 is open for adding a digest to compressed sstables. If you want a full scrub, then you should use scrub. :) > A nodetool command to validate all sstables in a node > - > > Key: CASSANDRA-5791 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5791 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: sankalp kohli >Priority: Minor > Fix For: 1.2.11 > > > CUrrently there is no nodetool command to validate all sstables on disk. The > only way to do this is to run a repair and see if it succeeds. But we cannot > repair the system keyspace. > Also we can run upgrade sstables but that re writes all the sstables. > This command should check the hash of all sstables and return whether all > data is readable all not. This should NOT care about consistency. > The compressed sstables do not have hash so not sure how it will work there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3916) Do not bind the storage_port if internode_encryption = all
[ https://issues.apache.org/jira/browse/CASSANDRA-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3916: -- Assignee: Dave Brosius > Do not bind the storage_port if internode_encryption = all > -- > > Key: CASSANDRA-3916 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3916 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.7 > Environment: Any >Reporter: Wade Poziombka >Assignee: Dave Brosius > > We are highly security conscious and having additional clear text ports open > are undesirable. > I have modified locally to get around but it seems that this is a very > trivial fix to only bind the clear text storage_port if the > internode_encryption is not all. If all is selected then no clear text > communication should be permitted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2443) Stream key/row caches during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773437#comment-13773437 ] Yuki Morishita commented on CASSANDRA-2443: --- We can't just stream key cache because file names and position change, though it may be possible to build Bloom Filter of cached keys and stream it before files, and the bootstrapping node can build it's own key cache as it receives SSTables. > Stream key/row caches during bootstrap > -- > > Key: CASSANDRA-2443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2443 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Priority: Minor > Labels: ponies > > When adding new nodes to an existing cluster, if we streamed key and row > caches over right before node came into cluster, we could minimize the impact > of a cold node, and reduce the time for the node to get 'warmed' up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5202) CFs should have globally and temporally unique CF IDs to prevent "reusing" data from earlier incarnation of same CF name
[ https://issues.apache.org/jira/browse/CASSANDRA-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773133#comment-13773133 ] Jonathan Ellis commented on CASSANDRA-5202: --- CASSANDRA-6060 is related since it also contemplates changing CFID assignment (back to unique ints via CAS). > CFs should have globally and temporally unique CF IDs to prevent "reusing" > data from earlier incarnation of same CF name > > > Key: CASSANDRA-5202 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5202 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.9 > Environment: OS: Windows 7, > Server: Cassandra 1.1.9 release drop > Client: astyanax 1.56.21, > JVM: Sun/Oracle JVM 64 bit (jdk1.6.0_27) >Reporter: Marat Bedretdinov >Assignee: Yuki Morishita > Labels: test > Fix For: 2.1 > > Attachments: 5202-1.1.txt, 5202-2.0.0.txt, astyanax-stress-driver.zip > > > Attached is a driver that sequentially: > 1. Drops keyspace > 2. Creates keyspace > 4. Creates 2 column families > 5. Seeds 1M rows with 100 columns > 6. Queries these 2 column families > The above steps are repeated 1000 times. > The following exception is observed at random (race - SEDA?): > ERROR [ReadStage:55] 2013-01-29 19:24:52,676 AbstractCassandraDaemon.java > (line 135) Exception in thread Thread[ReadStage:55,5,main] > java.lang.AssertionError: DecoratedKey(-1, ) != > DecoratedKey(62819832764241410631599989027761269388, 313a31) in > C:\var\lib\cassandra\data\user_role_reverse_index\business_entity_role\user_role_reverse_index-business_entity_role-hf-1-Data.db > at > org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:60) > at > org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67) > at > org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79) > at > org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256) > at > org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64) > at > org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1367) > at > org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1229) > at > org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1164) > at org.apache.cassandra.db.Table.getRow(Table.java:378) > at > org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69) > at > org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:822) > at > org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1271) > 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) > This exception appears in the server at the time of client submitting a query > request (row slice) and not at the time data is seeded. The client times out > and this data can no longer be queried as the same exception would always > occur from there on. > Also on iteration 201, it appears that dropping column families failed and as > a result their recreation failed with unique column family name violation > (see exception below). Note that the data files are actually gone, so it > appears that the server runtime responsible for creating column family was > out of sync with the piece that dropped them: > Starting dropping column families > Dropped column families > Starting dropping keyspace > Dropped keyspace > Starting creating column families > Created column families > Starting seeding data > Total rows inserted: 100 in 5105 ms > Iteration: 200; Total running time for 1000 queries is 232; Average running > time of 1000 queries is 0 ms > Starting dropping column families > Dropped column families > Starting dropping keyspace > Dropped keyspace > Starting creating column families > Created column families > Starting seeding data > Total rows inserted: 100 in 5361 ms > Iteration: 201; Total running time for 1000 queries is 222; Average running > time of 1000 queries is 0 ms > Starting dropping column families > Starting creating column families > Exception in thread "main" > com.netflix.astyanax.connectionpool.exceptions.BadRequestException: > BadRequestException: [host=127.0.0.1(127.0.0.1):9160, latency=2468(2469), > attempts=1]InvalidRequestException(why:Keyspace names
[jira] [Resolved] (CASSANDRA-4134) Do not send hints before a node is fully up
[
https://issues.apache.org/jira/browse/CASSANDRA-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4134.
---
Resolution: Cannot Reproduce
> Do not send hints before a node is fully up
> ---
>
> Key: CASSANDRA-4134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4134
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joaquin Casares
>Priority: Minor
>
> After seeing this on a cluster and working with Pavel, we have seen the
> following errors disappear after all migrations have been applied:
> {noformat}
> ERROR [MutationStage:1] 2012-04-09 18:16:00,240 RowMutationVerbHandler.java
> (line 61) Error in row mutation
> org.apache.cassandra.db.UnserializableColumnFamilyException: Couldn't find
> cfId=1028
> at
> org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:129)
> at
> org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:401)
> at
> org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:409)
> at org.apache.cassandra.db.RowMutation.fromBytes(RowMutation.java:357)
> at
> org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:42)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> and
> ERROR [ReadStage:69] 2012-04-09 18:16:01,715 AbstractCassandraDaemon.java
> (line 139) Fatal exception in thread Thread[ReadStage:69,5,main]
> java.lang.IllegalArgumentException: Unknown ColumnFamily content_indexes in
> keyspace linkcurrent
> at org.apache.cassandra.config.Schema.getComparator(Schema.java:223)
> at
> org.apache.cassandra.db.ColumnFamily.getComparatorFor(ColumnFamily.java:300)
> at
> org.apache.cassandra.db.ReadCommand.getComparator(ReadCommand.java:92)
> at
> org.apache.cassandra.db.SliceByNamesReadCommand.(SliceByNamesReadCommand.java:44)
> at
> org.apache.cassandra.db.SliceByNamesReadCommandSerializer.deserialize(SliceByNamesReadCommand.java:106)
> at
> org.apache.cassandra.db.SliceByNamesReadCommandSerializer.deserialize(SliceByNamesReadCommand.java:74)
> at
> org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:132)
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:51)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> It seems as though as soon as the correct Migration is applied, the Hints are
> accepted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3697) 'nodetool -h localhost repair' fails when there is an empty ks
[ https://issues.apache.org/jira/browse/CASSANDRA-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3697. --- Resolution: Not A Problem > 'nodetool -h localhost repair' fails when there is an empty ks > -- > > Key: CASSANDRA-3697 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3697 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.6 >Reporter: Joaquin Casares >Priority: Minor > Attachments: 3697.diff > > > If there is an empty KS, the assertion error thrown kills the entire repair, > when a keyspace is not specified. > To replicate: > Start a new cluster > nodetool -h localhost repair > Create a new keyspace with no column families > nodetool -h localhost repair > Assertion error is thrown to the prompt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3998) CLI: NUL character for data not visible
[
https://issues.apache.org/jira/browse/CASSANDRA-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773463#comment-13773463
]
Aleksey Yeschenko commented on CASSANDRA-3998:
--
{noformat}
cqlsh:test> insert into test2(id, val) VALUES ( 0, blobAsascii(0x004600));
cqlsh:test> select * from test2;
id | val
+---
0 | \x00F\x00
(1 rows)
{noformat}
No.
> CLI: NUL character for data not visible
> ---
>
> Key: CASSANDRA-3998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3998
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.8
>Reporter: Tyler Hobbs
>
> When using UTF8Type or AsciiType, if a column name or value is only 0x00
> bytes, the CLI will not show any indication that data is there. Here's an
> example where the column value is "0x00":
> {noformat}
> [default@Foo] get Foo2['key'];
> => (column=a, value=, timestamp=1330925963085434)
> {noformat}
> I'm not sure what the best solution is, but the current behavior is deceptive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3825) hung upon nodetool cleanup, kill
[ https://issues.apache.org/jira/browse/CASSANDRA-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3825. --- Resolution: Cannot Reproduce > hung upon nodetool cleanup, kill > > > Key: CASSANDRA-3825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3825 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.7 >Reporter: Bayle Shanks >Priority: Minor > > i did > bin/nodetool -h localhost repair > bin/nodetool -h localhost compact > which terminated. Then i did > bin/nodetool -h localhost cleanup > which did not. CPU usage was close to zero. I left it running overnight but > it didn't terminate. Cassandra was running with -f on screen, so i logged in > and typed cntl-C. Cassandra said that it stopped listening to thrift clients > but it did not then shut down. Additional cntl-Cs didn't do anything. i had > to kill -9 the process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4105) Use WritableComparable / Writable in RecordReader
[ https://issues.apache.org/jira/browse/CASSANDRA-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4105. --- Resolution: Won't Fix > Use WritableComparable / Writable in RecordReader > - > > Key: CASSANDRA-4105 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4105 > Project: Cassandra > Issue Type: Wish > Components: Hadoop >Affects Versions: 0.8.11, 1.0.9, 1.1.1, 1.2.0 beta 1 >Reporter: Patrik Modesto > > Cassandra uses ByteByffer/List as key/value in RecordWriter. This > prevents the use of MultipleOutputs class that requires a key to be > WritableComparable and value to be Writable. MultipleOutputs is a very handy > class that provides a way to write to several differrent OutputFormats from a > reducer. In our case I have a mapreduce job that produces two results which I > need to write to Cassandra and to a file respectively and as for now I need > to run that mapreduce twice which is quite expensive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3848) EmbeddedCassandraService needs a stop() method
[ https://issues.apache.org/jira/browse/CASSANDRA-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3848. --- Resolution: Won't Fix > EmbeddedCassandraService needs a stop() method > -- > > Key: CASSANDRA-3848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3848 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: David Hawthorne >Priority: Trivial > > I just need a stop() method in EmbeddedCassandraService so I can shut it down > as part of my unit tests, so I can test fail behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4102) Upgrade to Jackson 2
[ https://issues.apache.org/jira/browse/CASSANDRA-4102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773462#comment-13773462 ] Jonathan Ellis commented on CASSANDRA-4102: --- Avro is gone now. > Upgrade to Jackson 2 > > > Key: CASSANDRA-4102 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4102 > Project: Cassandra > Issue Type: Bug >Reporter: Ben McCann >Priority: Minor > > Cassandra is currently using Jackson 1.4.0. It would be nice to upgrade to > Jackson 2, which is a smaller, lighter, and more modular library. I'm using > Play Framework and SBT, which complain vociferously about Jackson 1 not > having its javadoc jars in the Maven repository. Upgrading to Jackson 2 > would fix this annoyance. > Files using Jackson are: > src/java/org/apache/cassandra/utils/FBUtilities.java > src/java/org/apache/cassandra/tools/SSTableExport.java > src/java/org/apache/cassandra/db/compaction/LeveledManifest.java > Info on Jackson 2 is available on Github and the wiki: > https://github.com/FasterXML/jackson-core > http://wiki.fasterxml.com/JacksonRelease20 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4053) IncomingTcpConnection can not be closed when the peer is brutaly terminated or switch is failed
[ https://issues.apache.org/jira/browse/CASSANDRA-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4053: -- Assignee: Marcus Eriksson > IncomingTcpConnection can not be closed when the peer is brutaly terminated > or switch is failed > --- > > Key: CASSANDRA-4053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4053 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.8 >Reporter: Zhu Han >Assignee: Marcus Eriksson > > IncomingTcpConnection has no way to detect the peer is down when the peer > meets power loss or the network infrastructure is failed, and the thread is > leaked... > For safety, as least SO_KEEPALIVE should be set on those > IncomingTcpConnections. The better way is to close the incoming connections > when failure detector notifies the peer failure, but it requires some extra > bookmarking. > Besides it, it would be better if IncomingTcpConnection and > OutgoingTcpConnection is marked as daemon thread... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4048) SSTableLoader meets problem during the apply of the schema update
[ https://issues.apache.org/jira/browse/CASSANDRA-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4048. --- Resolution: Cannot Reproduce > SSTableLoader meets problem during the apply of the schema update > --- > > Key: CASSANDRA-4048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4048 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.0.8 >Reporter: Zhu Han >Priority: Minor > > SSTableLoader tries to apply the "drop column family" meta data update, and > meets below problem. Seems like the column family > is dropped multiple times? > user@luzhou:/data/apache-cassandra-1.0.8$ bin/sstableloader -i hostA,hostB > /tmp/out/store/ > Starting client (and waiting 30 seconds for gossip) ... > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > ERROR 18:35:51,423 Error in ThreadPoolExecutor > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > ERROR 18:35:51,595 Error in ThreadPoolExecutor > java.lang.IllegalArgumentException: Unknown CF 1000 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at > org.apache.cassandra.db.migration.DropColumnFamily.applyModels(DropColumnFamily.java:70) > at org.apache.cassandra.db.migration.Migration.apply(Migration.java:156) > at > org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:73) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4053) IncomingTcpConnection can not be closed when the peer is brutaly terminated or switch is failed
[ https://issues.apache.org/jira/browse/CASSANDRA-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773458#comment-13773458 ] Jonathan Ellis commented on CASSANDRA-4053: --- Is this still relevant [~krummas]? > IncomingTcpConnection can not be closed when the peer is brutaly terminated > or switch is failed > --- > > Key: CASSANDRA-4053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4053 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.8 >Reporter: Zhu Han >Assignee: Marcus Eriksson > > IncomingTcpConnection has no way to detect the peer is down when the peer > meets power loss or the network infrastructure is failed, and the thread is > leaked... > For safety, as least SO_KEEPALIVE should be set on those > IncomingTcpConnections. The better way is to close the incoming connections > when failure detector notifies the peer failure, but it requires some extra > bookmarking. > Besides it, it would be better if IncomingTcpConnection and > OutgoingTcpConnection is marked as daemon thread... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4075) Dropped keyspaces and cfs do not get deleted
[ https://issues.apache.org/jira/browse/CASSANDRA-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4075. --- Resolution: Cannot Reproduce > Dropped keyspaces and cfs do not get deleted > > > Key: CASSANDRA-4075 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4075 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.8.1 >Reporter: Joaquin Casares > Labels: datastax_qa > > Tested in 0.8.10, reported in 0.8.1. > Dropped keyspaces and column families have their sstables marked as > Compacted, but will not disappear, even on restart. > Worked correctly in 1.0.8 where the sstables get deleted almost immediately > following the column family drop. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3848) EmbeddedCassandraService needs a stop() method
[ https://issues.apache.org/jira/browse/CASSANDRA-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773443#comment-13773443 ] Jonathan Ellis commented on CASSANDRA-3848: --- Closing since nobody cares enough to submit a new patch. > EmbeddedCassandraService needs a stop() method > -- > > Key: CASSANDRA-3848 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3848 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: David Hawthorne >Priority: Trivial > > I just need a stop() method in EmbeddedCassandraService so I can shut it down > as part of my unit tests, so I can test fail behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-1956) Convert row cache to row+filter cache
[ https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay resolved CASSANDRA-1956. -- Resolution: Duplicate Yep, Closing this as it is duplicate to CASSANDRA-5357. > Convert row cache to row+filter cache > - > > Key: CASSANDRA-1956 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1956 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Stu Hood >Assignee: Vijay >Priority: Minor > Fix For: 2.1 > > Attachments: 0001-1956-cache-updates-v0.patch, > 0001-commiting-block-cache.patch, 0001-re-factor-row-cache.patch, > 0001-row-cache-filter.patch, 0002-1956-updates-to-thrift-and-avro-v0.patch, > 0002-add-query-cache.patch > > > Changing the row cache to a row+filter cache would make it much more useful. > We currently have to warn against using the row cache with wide rows, where > the read pattern is typically a peek at the head, but this usecase would be > perfect supported by a cache that stored only columns matching the filter. > Possible implementations: > * (copout) Cache a single filter per row, and leave the cache key as is > * Cache a list of filters per row, leaving the cache key as is: this is > likely to have some gotchas for weird usage patterns, and it requires the > list overheard > * Change the cache key to "rowkey+filterid": basically ideal, but you need a > secondary index to lookup cache entries by rowkey so that you can keep them > in sync with the memtable > * others? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4043) RecentBloomFilterFalseRatio and RecentBloomFilterFalsePositives reset each other
[
https://issues.apache.org/jira/browse/CASSANDRA-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4043:
--
Assignee: Tyler Hobbs
> RecentBloomFilterFalseRatio and RecentBloomFilterFalsePositives reset each
> other
>
>
> Key: CASSANDRA-4043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4043
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.8
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Trivial
> Labels: jmx
>
> If either of the ColumnFamily JMX attributes {{RecentBloomFilterFalseRatio}}
> or {{RecentBloomFilterFalsePositives}} are read, both are reset. This means
> if you try to read both attributes at the same time (like jconsole does, for
> example), one of them is guaranteed to be 0.
> The solution might be that we store a separate false positives counter for
> the ratio and the normal count and reset them separately. Some refactoring
> should be done at the same time so that the BloomFilterTracker calculates the
> false positive ratio itself instead of having DataTracker fetch both counters
> and calculate the ratio.
> On a related note, why does nodetool not use the Recent versions of the bloom
> filter metrics?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3813) Cassandra-cli doesn't give any useful error on index creation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3813.
---
Resolution: Won't Fix
> Cassandra-cli doesn't give any useful error on index creation failure
> -
>
> Key: CASSANDRA-3813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3813
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.0.5
> Environment: DSE 1.0.5 inside the Cassandra-cli. Still nothing
> useful even with --debug flag.
>Reporter: Eric Lubow
> Labels: cli
>
> [default@linkcurrent] update column family report_by_account_content with
> comparator='UTF8Type' and column_metadata = [
> ... { column_name:'meta:account-id',
> validation_class:'UTF8Type',index_type:KEYS},
> ... { column_name:'meta:filter-hash',
> validation_class:'UTF8Type',index_type:KEYS}
> ... ];
> null
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3998) CLI: NUL character for data not visible
[
https://issues.apache.org/jira/browse/CASSANDRA-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773454#comment-13773454
]
Jonathan Ellis commented on CASSANDRA-3998:
---
[~iamaleksey] is this relevant to cqlsh?
> CLI: NUL character for data not visible
> ---
>
> Key: CASSANDRA-3998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3998
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.8
>Reporter: Tyler Hobbs
>
> When using UTF8Type or AsciiType, if a column name or value is only 0x00
> bytes, the CLI will not show any indication that data is there. Here's an
> example where the column value is "0x00":
> {noformat}
> [default@Foo] get Foo2['key'];
> => (column=a, value=, timestamp=1330925963085434)
> {noformat}
> I'm not sure what the best solution is, but the current behavior is deceptive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-1975) Multi NIC/IP support
[ https://issues.apache.org/jira/browse/CASSANDRA-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1975. --- Resolution: Won't Fix > Multi NIC/IP support > > > Key: CASSANDRA-1975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1975 > Project: Cassandra > Issue Type: Improvement >Reporter: Max Sanders >Priority: Minor > Labels: ponies > > Every node should listen on more than one IP. When a node is contacted a > random IP for that node is chosen. If the node can not be reached by this IP > an other IP is used. > This way you don't need multipathing switches or Distributed Split Multi-Link > Trunking hardware that is very expensive. You could use normal hardware that > is inexpensive. > If a cable is plugged of or a switch failed it is no problem. Also you can > use the second/third network for load balancing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3487) better repair session timeouts and retrys
[ https://issues.apache.org/jira/browse/CASSANDRA-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773415#comment-13773415 ] Yuki Morishita commented on CASSANDRA-3487: --- Added exception handling for validation to fail repair session in 2.0. We still don't have timeout, though I think we don't need one because when the node is choked, gossip/failure detector would kill repair session. > better repair session timeouts and retrys > - > > Key: CASSANDRA-3487 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3487 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Vijay >Priority: Minor > Fix For: 2.1 > > > It would be great if we can timeout a validation compaction which is taking > long or had an exception while doing a Validation. > Repair can gossip its status to all the other nodes, hence any node which is > waiting for response of a "tree request" to wait until it complete, if the > repair is not going to complete because of exception or because it is too > busy taking the incoming request we can timeout the user request. > Bonus: By displaying the repair gossip via nodetool, user/script running the > request can have a better handle on whats going on in the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3763) compactionstats throws ArithmeticException: / by zero
[ https://issues.apache.org/jira/browse/CASSANDRA-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3763. --- Resolution: Cannot Reproduce > compactionstats throws ArithmeticException: / by zero > - > > Key: CASSANDRA-3763 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3763 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Affects Versions: 1.0.7, 1.0.8, 1.0.9, 1.0.10, 1.1.0, 1.1.1, 1.1.2, 1.1.3, > 1.1.4 > Environment: debian linux - openvz kernel, oracle java 1.6.0.26 >Reporter: Zenek Kraweznik >Priority: Trivial > > compactionstats looks like this: > # nodetool -h localhost compactionstats > Exception in thread "main" java.lang.ArithmeticException: / by zero > at > org.apache.cassandra.db.compaction.LeveledManifest.getEstimatedTasks(LeveledManifest.java:435) > at > org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getEstimatedRemainingTasks(LeveledCompactionStrategy.java:128) > at > org.apache.cassandra.db.compaction.CompactionManager.getPendingTasks(CompactionManager.java:1060) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) > at > com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) > at > com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65) > at > com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) > at > javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1404) > at > javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) > at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) > at > javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) > at > javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:600) > at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) > at sun.rmi.transport.Transport$1.run(Transport.java:159) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:155) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) > 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) > # > nodetool is working fine in other actions: > # nodetool -h localhost netstats > Mode: NORMAL > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 2 > Responses n/a 0 1810 > # -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3746) updating row_cache_provider does not take affect until after a node is restarted
[ https://issues.apache.org/jira/browse/CASSANDRA-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3746. --- Resolution: Later > updating row_cache_provider does not take affect until after a node is > restarted > > > Key: CASSANDRA-3746 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3746 > Project: Cassandra > Issue Type: Bug >Reporter: B. Todd Burruss > > using CLI to update row_cache_provider does not take affect until after a > node is restarted, even though "describe" shows it as set. not sure if you > consider this a bug, but has caused me some grief with my testing of > providers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3605) Exception swallowing in Hex.java
[
https://issues.apache.org/jira/browse/CASSANDRA-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3605.
---
Resolution: Won't Fix
> Exception swallowing in Hex.java
>
>
> Key: CASSANDRA-3605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3605
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 1.0.5
> Environment: all
>Reporter: Zoltan Farkas
>Priority: Minor
>
> org.apache.cassandra.utils.Hex line 94:
> try
> {
> s = stringConstructor.newInstance(0, c.length, c);
> }
> catch (Exception e)
> {
> // Swallowing as we'll just use a copying constructor
> }
> this code does not comply with coding standard, caught exception needs to be
> rethrown as RuntimeException
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3578) Multithreaded commitlog
[ https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773408#comment-13773408 ] Jonathan Ellis commented on CASSANDRA-3578: --- I've seen several cases of nodes failing to keep up with write requests where the commitlog was the bottleneck. These were all workloads throwing MB-sized columns around. Granted, that's not exactly our bread and butter. > Multithreaded commitlog > --- > > Key: CASSANDRA-3578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3578 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Priority: Minor > Attachments: 0001-CASSANDRA-3578.patch, parallel_commit_log_2.patch > > > Brian Aker pointed out a while ago that allowing multiple threads to modify > the commitlog simultaneously (reserving space for each with a CAS first, the > way we do in the SlabAllocator.Region.allocate) can improve performance, > since you're not bottlenecking on a single thread to do all the copying and > CRC computation. > Now that we use mmap'd CommitLog segments (CASSANDRA-3411) this becomes > doable. > (moved from CASSANDRA-622, which was getting a bit muddled.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-1472) Add bitmap secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1472. --- Resolution: Later Reviewer: (was: tjake) > Add bitmap secondary indexes > > > Key: CASSANDRA-1472 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1472 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Stu Hood > Attachments: 0.7-1472-v5.tgz, 0.7-1472-v6.tgz, 1472-v3.tgz, > 1472-v4.tgz, 1472-v5.tgz, anatomy.png, > ASF.LICENSE.NOT.GRANTED--0001-CASSANDRA-1472-rebased-to-0.7-branch.txt, > ASF.LICENSE.NOT.GRANTED--0019-Rename-bugfixes-and-fileclose.txt, > v4-bench-c32.txt > > > Bitmap indexes are a very efficient structure for dealing with immutable > data. We can take advantage of the fact that SSTables are immutable by > attaching them directly to SSTables as a new component (supported by > CASSANDRA-1471). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-1598) Add Boolean Expression to secondary querying
[ https://issues.apache.org/jira/browse/CASSANDRA-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1598. --- Resolution: Later > Add Boolean Expression to secondary querying > > > Key: CASSANDRA-1598 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1598 > Project: Cassandra > Issue Type: New Feature > Components: API >Affects Versions: 0.7 beta 3 >Reporter: Todd Nine > > Add boolean operators similar to Lucene style searches. Currently there is > implicit support for the && operator. It would be helpful to also add > support for ||/Union operators. I would envision this as the client would be > required to construct the expression tree and pass it via the thrift > interface. > BooleanExpression --> BooleanOrIndexExpression > --> BooleanOperator > --> BooleanOrIndexExpression > I'd like to take a crack at this since it will greatly improve my Datanucleus > plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3499) Make the 'load' interface pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3499. --- Resolution: Later > Make the 'load' interface pluggable > --- > > Key: CASSANDRA-3499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3499 > Project: Cassandra > Issue Type: Bug >Reporter: Chris Goffinet >Priority: Minor > > We should make the 'Load' attribute of the cluster at least pluggable. One > use case we had was we could build a plugin that was specific to us, that > could be tied directly into our time series database we have for all of our > infrastructure. This would allow us to populate and expose more data per node > instead of needing to gossip this data around (CPU/Network/Memory/etc) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3560) incorrect description for nodetool scrub/upgradesstables and invalidaterow/keycache
[ https://issues.apache.org/jira/browse/CASSANDRA-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3560. --- Resolution: Cannot Reproduce > incorrect description for nodetool scrub/upgradesstables and > invalidaterow/keycache > --- > > Key: CASSANDRA-3560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3560 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.0.5 >Reporter: Ramesh Natarajan >Priority: Trivial > > Description for the following commands needs to be corrected > scrub [keyspace] [cfnames] - Scrub (rebuild sstables for) one or more > column family > upgradesstables [keyspace] [cfnames] - Scrub (rebuild sstables for) one or > more column family > invalidatekeycache [keyspace] [cfnames] - Invalidate the key cache of one > or more column family > invalidaterowcache [keyspace] [cfnames] - Invalidate the key cache of one > or more column family -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3487) better repair session timeouts and retrys
[ https://issues.apache.org/jira/browse/CASSANDRA-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773403#comment-13773403 ] Jonathan Ellis commented on CASSANDRA-3487: --- Is this still an issue [~yukim]? > better repair session timeouts and retrys > - > > Key: CASSANDRA-3487 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3487 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Vijay >Priority: Minor > Fix For: 2.1 > > > It would be great if we can timeout a validation compaction which is taking > long or had an exception while doing a Validation. > Repair can gossip its status to all the other nodes, hence any node which is > waiting for response of a "tree request" to wait until it complete, if the > repair is not going to complete because of exception or because it is too > busy taking the incoming request we can timeout the user request. > Bonus: By displaying the repair gossip via nodetool, user/script running the > request can have a better handle on whats going on in the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-1657) support in-memory column families
[ https://issues.apache.org/jira/browse/CASSANDRA-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1657. --- Resolution: Later > support in-memory column families > - > > Key: CASSANDRA-1657 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1657 > Project: Cassandra > Issue Type: Improvement >Reporter: Peter Schuller >Priority: Minor > > Some workloads are such that you absolutely depend on column families being > in-memory for performance, yet you most definitely want all the things that > Cassandra offers in terms of replication, consistency, durability etc. > In order to semi-deterministically ensure acceptable performance for such > data, Cassandra could support in-memory column families. Such an in-memory > column family would imply that mlock() be used on sstables for this column > family. On start-up and on compaction completion, they could be mmap():ed > with MAP_POPULATE (Linux specific) or else just mmap():ed + mlock():ed in > such a way as to otherwise guarantee it is in-memory (such as userland > traversal of the entire file). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2609) Repair multi-DC awareness
[ https://issues.apache.org/jira/browse/CASSANDRA-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2609. --- Resolution: Won't Fix > Repair multi-DC awareness > - > > Key: CASSANDRA-2609 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2609 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Sylvain Lebresne >Priority: Minor > Labels: ponies > > Repair has no multi-DC awareness in that if you have 2 DC with 3 replica in > each, a repair of a node will transit 3 merkle tree cross-DC and potentially > initiate as many cross-DC streaming (with likely a non null intersection > between those). In theory, we could repair separately in each DC, then repair > between only two node cross-DC (that we know are up to date in their > respective DC) and finally re-repair in the separate DC (to pass the cross-DC > changes to all nodes of the DC). > It is yet unclear to me if we can make that efficient enough that it is worth > the added complexity, so this is really meant as an exploratory ticket. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5351) Avoid repairing already-repaired data by default
[ https://issues.apache.org/jira/browse/CASSANDRA-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773398#comment-13773398 ] Jonathan Ellis commented on CASSANDRA-5351: --- Then the question becomes, who should be the repair coordinator? If you say "the first replicay from the ReplicationStrategy," then what do you do if that node is down while other nodes receive data, and doesn't know it's supposed to kick one off? It's a whole can of worms that I'd rather not open so I hope someone has a better idea. :) > Avoid repairing already-repaired data by default > > > Key: CASSANDRA-5351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5351 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Jonathan Ellis >Assignee: Lyuben Todorov > Labels: repair > Fix For: 2.1 > > > Repair has always built its merkle tree from all the data in a columnfamily, > which is guaranteed to work but is inefficient. > We can improve this by remembering which sstables have already been > successfully repaired, and only repairing sstables new since the last repair. > (This automatically makes CASSANDRA-3362 much less of a problem too.) > The tricky part is, compaction will (if not taught otherwise) mix repaired > data together with non-repaired. So we should segregate unrepaired sstables > from the repaired ones. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-1599) Add sort/order support for secondary indexing
[ https://issues.apache.org/jira/browse/CASSANDRA-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1599. --- Resolution: Later > Add sort/order support for secondary indexing > - > > Key: CASSANDRA-1599 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1599 > Project: Cassandra > Issue Type: New Feature > Components: API >Reporter: Todd Nine > Original Estimate: 32h > Remaining Estimate: 32h > > For a lot of users paging is a standard use case on many web applications. > It would be nice to allow paging as part of a Boolean Expression. > Page -> start index >-> end index >-> page timestamp >-> Sort Order > When sorting, is it possible to sort both ASC and DESC? > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2609) Repair multi-DC awareness
[ https://issues.apache.org/jira/browse/CASSANDRA-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773387#comment-13773387 ] Jonathan Ellis commented on CASSANDRA-2609: --- I'm going to predict that this is unnecessary complexity once CASSANDRA-5351 and possibly CASSANDRA-3362 are done. > Repair multi-DC awareness > - > > Key: CASSANDRA-2609 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2609 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Sylvain Lebresne >Priority: Minor > Labels: ponies > > Repair has no multi-DC awareness in that if you have 2 DC with 3 replica in > each, a repair of a node will transit 3 merkle tree cross-DC and potentially > initiate as many cross-DC streaming (with likely a non null intersection > between those). In theory, we could repair separately in each DC, then repair > between only two node cross-DC (that we know are up to date in their > respective DC) and finally re-repair in the separate DC (to pass the cross-DC > changes to all nodes of the DC). > It is yet unclear to me if we can make that efficient enough that it is worth > the added complexity, so this is really meant as an exploratory ticket. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
