[jira] [Commented] (CASSANDRA-8291) Parent repair session is not removed in remote node
[ https://issues.apache.org/jira/browse/CASSANDRA-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209434#comment-14209434 ] Marcus Eriksson commented on CASSANDRA-8291: +1 > Parent repair session is not removed in remote node > --- > > Key: CASSANDRA-8291 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8291 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Yuki Morishita >Priority: Minor > Labels: repair > Fix For: 2.1.3 > > Attachments: > 0001-remove-parent-session-after-anticompaction-in-remote.patch > > > After anti-compaction is run on remote node, parent repair session is not > removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: make sure streams get closed
Repository: cassandra
Updated Branches:
refs/heads/trunk 938248640 -> 7c93b04b3
make sure streams get closed
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7c93b04b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7c93b04b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7c93b04b
Branch: refs/heads/trunk
Commit: 7c93b04b34844afdc3a502af9e7fb296f43dc068
Parents: 9382486
Author: Dave Brosius
Authored: Wed Nov 12 22:53:47 2014 -0500
Committer: Dave Brosius
Committed: Wed Nov 12 22:53:47 2014 -0500
--
src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7c93b04b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index 9994038..07f7f53 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -2173,16 +2173,18 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
private void writeSnapshotManifest(final JSONArray filesJSONArr, final
String snapshotName)
{
final File manifestFile =
directories.getSnapshotManifestFile(snapshotName);
-final JSONObject manifestJSON = new JSONObject();
-manifestJSON.put("files", filesJSONArr);
try
{
if (!manifestFile.getParentFile().exists())
manifestFile.getParentFile().mkdirs();
-PrintStream out = new PrintStream(manifestFile);
-out.println(manifestJSON.toJSONString());
-out.close();
+
+try (PrintStream out = new PrintStream(manifestFile))
+{
+final JSONObject manifestJSON = new JSONObject();
+manifestJSON.put("files", filesJSONArr);
+out.println(manifestJSON.toJSONString());
+}
}
catch (IOException e)
{
cassandra git commit: create the cache name format only once
Repository: cassandra Updated Branches: refs/heads/trunk 88d4a14a8 -> 938248640 create the cache name format only once Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/93824864 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/93824864 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/93824864 Branch: refs/heads/trunk Commit: 93824864022825c5a22d000e78afe86ea5aed796 Parents: 88d4a14 Author: Dave Brosius Authored: Wed Nov 12 22:45:32 2014 -0500 Committer: Dave Brosius Committed: Wed Nov 12 22:47:06 2014 -0500 -- src/java/org/apache/cassandra/cache/AutoSavingCache.java | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/93824864/src/java/org/apache/cassandra/cache/AutoSavingCache.java -- diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java b/src/java/org/apache/cassandra/cache/AutoSavingCache.java index 9a79e38..4ac2328 100644 --- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java +++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java @@ -306,13 +306,14 @@ public class AutoSavingCache extends InstrumentingCache
[jira] [Created] (CASSANDRA-8305) add check of the system wall clock time at startup
Jason Brown created CASSANDRA-8305: -- Summary: add check of the system wall clock time at startup Key: CASSANDRA-8305 URL: https://issues.apache.org/jira/browse/CASSANDRA-8305 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jason Brown Assignee: Jason Brown Priority: Minor Fix For: 3.0, 2.1.3 Attachments: v1.txt Related to CASSANDRA-8296, we should add a check of the system wall clock at startup to make sure it 'looks' reasonable. This check will prevent a node from starting with a bad generation in it's gossip metadata (and causing many problems downstream of that). Note that this is intended as a simple check of the clock at startup and not a comprehensive, ongoing check of clocks during the running of the process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/3] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1
Conflicts:
src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
src/java/org/apache/cassandra/transport/Server.java
src/java/org/apache/cassandra/transport/SimpleClient.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5615a79c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5615a79c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5615a79c
Branch: refs/heads/trunk
Commit: 5615a79cf0b4579af363688124d3f57fa7efa00d
Parents: 1217afb 37d33b2
Author: Jason Brown
Authored: Wed Nov 12 16:16:31 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 16:16:31 2014 -0800
--
src/java/org/apache/cassandra/security/SSLFactory.java| 10 +-
.../apache/cassandra/thrift/CustomTThreadPoolServer.java | 3 ++-
src/java/org/apache/cassandra/transport/Server.java | 2 +-
src/java/org/apache/cassandra/transport/SimpleClient.java | 2 +-
4 files changed, 9 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5615a79c/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --cc src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index 8a4d016,f25c761..7e67110
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@@ -35,7 -35,7 +35,8 @@@ import org.slf4j.LoggerFactory
import org.apache.cassandra.concurrent.NamedThreadFactory;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.config.EncryptionOptions.ClientEncryptionOptions;
+import org.apache.cassandra.utils.JVMStabilityInspector;
+ import org.apache.cassandra.security.SSLFactory;
import org.apache.thrift.TException;
import org.apache.thrift.TProcessor;
import org.apache.thrift.protocol.TProtocol;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5615a79c/src/java/org/apache/cassandra/transport/Server.java
--
diff --cc src/java/org/apache/cassandra/transport/Server.java
index 2a60242,df4f127..ba6e895
--- a/src/java/org/apache/cassandra/transport/Server.java
+++ b/src/java/org/apache/cassandra/transport/Server.java
@@@ -324,10 -296,13 +324,10 @@@ public class Server implements Cassandr
sslEngine.setUseClientMode(false);
sslEngine.setEnabledCipherSuites(encryptionOptions.cipher_suites);
sslEngine.setNeedClientAuth(encryptionOptions.require_client_auth);
- sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello",
"TLSv1", "TLSv1.1", "TLSv1.2"});
+ sslEngine.setEnabledProtocols(SSLFactory.ACCEPTED_PROTOCOLS);
-
SslHandler sslHandler = new SslHandler(sslEngine);
-sslHandler.setIssueHandshake(true);
-ChannelPipeline pipeline = super.getPipeline();
-pipeline.addFirst("ssl", sslHandler);
-return pipeline;
+super.initChannel(channel);
+channel.pipeline().addFirst("ssl", sslHandler);
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5615a79c/src/java/org/apache/cassandra/transport/SimpleClient.java
--
diff --cc src/java/org/apache/cassandra/transport/SimpleClient.java
index 2e1e45e,1ed9ab9..3a6ecf7
--- a/src/java/org/apache/cassandra/transport/SimpleClient.java
+++ b/src/java/org/apache/cassandra/transport/SimpleClient.java
@@@ -253,8 -259,11 +253,8 @@@ public class SimpleClien
SSLEngine sslEngine = sslContext.createSSLEngine();
sslEngine.setUseClientMode(true);
sslEngine.setEnabledCipherSuites(encryptionOptions.cipher_suites);
- sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello",
"TLSv1", "TLSv1.1", "TLSv1.2"});
+ sslEngine.setEnabledProtocols(SSLFactory.ACCEPTED_PROTOCOLS);
-ChannelPipeline pipeline = super.getPipeline();
-
-pipeline.addFirst("ssl", new SslHandler(sslEngine));
-return pipeline;
+channel.pipeline().addFirst("ssl", new SslHandler(sslEngine));
}
}
[3/3] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/88d4a14a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/88d4a14a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/88d4a14a Branch: refs/heads/trunk Commit: 88d4a14a885274837898853d3ec4c11223aa8a73 Parents: e15cf78 5615a79 Author: Jason Brown Authored: Wed Nov 12 16:16:59 2014 -0800 Committer: Jason Brown Committed: Wed Nov 12 16:16:59 2014 -0800 -- src/java/org/apache/cassandra/security/SSLFactory.java| 10 +- .../apache/cassandra/thrift/CustomTThreadPoolServer.java | 3 ++- src/java/org/apache/cassandra/transport/Server.java | 2 +- src/java/org/apache/cassandra/transport/SimpleClient.java | 2 +- 4 files changed, 9 insertions(+), 8 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/88d4a14a/src/java/org/apache/cassandra/transport/Server.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/88d4a14a/src/java/org/apache/cassandra/transport/SimpleClient.java --
[2/2] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1
Conflicts:
src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
src/java/org/apache/cassandra/transport/Server.java
src/java/org/apache/cassandra/transport/SimpleClient.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5615a79c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5615a79c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5615a79c
Branch: refs/heads/cassandra-2.1
Commit: 5615a79cf0b4579af363688124d3f57fa7efa00d
Parents: 1217afb 37d33b2
Author: Jason Brown
Authored: Wed Nov 12 16:16:31 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 16:16:31 2014 -0800
--
src/java/org/apache/cassandra/security/SSLFactory.java| 10 +-
.../apache/cassandra/thrift/CustomTThreadPoolServer.java | 3 ++-
src/java/org/apache/cassandra/transport/Server.java | 2 +-
src/java/org/apache/cassandra/transport/SimpleClient.java | 2 +-
4 files changed, 9 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5615a79c/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --cc src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index 8a4d016,f25c761..7e67110
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@@ -35,7 -35,7 +35,8 @@@ import org.slf4j.LoggerFactory
import org.apache.cassandra.concurrent.NamedThreadFactory;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.config.EncryptionOptions.ClientEncryptionOptions;
+import org.apache.cassandra.utils.JVMStabilityInspector;
+ import org.apache.cassandra.security.SSLFactory;
import org.apache.thrift.TException;
import org.apache.thrift.TProcessor;
import org.apache.thrift.protocol.TProtocol;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5615a79c/src/java/org/apache/cassandra/transport/Server.java
--
diff --cc src/java/org/apache/cassandra/transport/Server.java
index 2a60242,df4f127..ba6e895
--- a/src/java/org/apache/cassandra/transport/Server.java
+++ b/src/java/org/apache/cassandra/transport/Server.java
@@@ -324,10 -296,13 +324,10 @@@ public class Server implements Cassandr
sslEngine.setUseClientMode(false);
sslEngine.setEnabledCipherSuites(encryptionOptions.cipher_suites);
sslEngine.setNeedClientAuth(encryptionOptions.require_client_auth);
- sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello",
"TLSv1", "TLSv1.1", "TLSv1.2"});
+ sslEngine.setEnabledProtocols(SSLFactory.ACCEPTED_PROTOCOLS);
-
SslHandler sslHandler = new SslHandler(sslEngine);
-sslHandler.setIssueHandshake(true);
-ChannelPipeline pipeline = super.getPipeline();
-pipeline.addFirst("ssl", sslHandler);
-return pipeline;
+super.initChannel(channel);
+channel.pipeline().addFirst("ssl", sslHandler);
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5615a79c/src/java/org/apache/cassandra/transport/SimpleClient.java
--
diff --cc src/java/org/apache/cassandra/transport/SimpleClient.java
index 2e1e45e,1ed9ab9..3a6ecf7
--- a/src/java/org/apache/cassandra/transport/SimpleClient.java
+++ b/src/java/org/apache/cassandra/transport/SimpleClient.java
@@@ -253,8 -259,11 +253,8 @@@ public class SimpleClien
SSLEngine sslEngine = sslContext.createSSLEngine();
sslEngine.setUseClientMode(true);
sslEngine.setEnabledCipherSuites(encryptionOptions.cipher_suites);
- sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello",
"TLSv1", "TLSv1.1", "TLSv1.2"});
+ sslEngine.setEnabledProtocols(SSLFactory.ACCEPTED_PROTOCOLS);
-ChannelPipeline pipeline = super.getPipeline();
-
-pipeline.addFirst("ssl", new SslHandler(sslEngine));
-return pipeline;
+channel.pipeline().addFirst("ssl", new SslHandler(sslEngine));
}
}
[1/3] cassandra git commit: ninja-fix nit from casandra-8265 commit (make repeated strings a constant)
Repository: cassandra
Updated Branches:
refs/heads/trunk e15cf78b5 -> 88d4a14a8
ninja-fix nit from casandra-8265 commit (make repeated strings a constant)
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/37d33b20
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/37d33b20
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/37d33b20
Branch: refs/heads/trunk
Commit: 37d33b2086abb8e073a3ec7f9de23150eb49fb32
Parents: b93f48a
Author: Jason Brown
Authored: Wed Nov 12 16:12:36 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 16:12:36 2014 -0800
--
src/java/org/apache/cassandra/security/SSLFactory.java| 10 +-
.../apache/cassandra/thrift/CustomTThreadPoolServer.java | 3 ++-
src/java/org/apache/cassandra/transport/Server.java | 2 +-
src/java/org/apache/cassandra/transport/SimpleClient.java | 2 +-
4 files changed, 9 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/37d33b20/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index 260c828..956ba67 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -50,7 +50,7 @@ import com.google.common.collect.Sets;
public final class SSLFactory
{
private static final Logger logger =
LoggerFactory.getLogger(SSLFactory.class);
-
+public static final String[] ACCEPTED_PROTOCOLS = new String[]
{"SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2"};
private static boolean checkedExpiry = false;
public static SSLServerSocket getServerSocket(EncryptionOptions options,
InetAddress address, int port) throws IOException
@@ -61,7 +61,7 @@ public final class SSLFactory
String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
serverSocket.setNeedClientAuth(options.require_client_auth);
-serverSocket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
serverSocket.bind(new InetSocketAddress(address, port), 500);
return serverSocket;
}
@@ -73,7 +73,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
@@ -84,7 +84,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
@@ -95,7 +95,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket) ctx.getSocketFactory().createSocket();
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/37d33b20/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index 3111deb..f25c761 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -35,6 +35,7 @@ import org.slf4j.LoggerFactory;
import org.apache.cassandra.concurrent.NamedThreadFactory;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.config.EncryptionOptions.ClientEncryptionOptions;
+import org.apache.cassandra.security.SSLFactory;
import org.apache.thrift.TException;
import org.apache.thrift.TProcessor;
import org.apache.thr
[1/2] cassandra git commit: ninja-fix nit from casandra-8265 commit (make repeated strings a constant)
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 1217afb5c -> 5615a79cf
ninja-fix nit from casandra-8265 commit (make repeated strings a constant)
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/37d33b20
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/37d33b20
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/37d33b20
Branch: refs/heads/cassandra-2.1
Commit: 37d33b2086abb8e073a3ec7f9de23150eb49fb32
Parents: b93f48a
Author: Jason Brown
Authored: Wed Nov 12 16:12:36 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 16:12:36 2014 -0800
--
src/java/org/apache/cassandra/security/SSLFactory.java| 10 +-
.../apache/cassandra/thrift/CustomTThreadPoolServer.java | 3 ++-
src/java/org/apache/cassandra/transport/Server.java | 2 +-
src/java/org/apache/cassandra/transport/SimpleClient.java | 2 +-
4 files changed, 9 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/37d33b20/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index 260c828..956ba67 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -50,7 +50,7 @@ import com.google.common.collect.Sets;
public final class SSLFactory
{
private static final Logger logger =
LoggerFactory.getLogger(SSLFactory.class);
-
+public static final String[] ACCEPTED_PROTOCOLS = new String[]
{"SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2"};
private static boolean checkedExpiry = false;
public static SSLServerSocket getServerSocket(EncryptionOptions options,
InetAddress address, int port) throws IOException
@@ -61,7 +61,7 @@ public final class SSLFactory
String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
serverSocket.setNeedClientAuth(options.require_client_auth);
-serverSocket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
serverSocket.bind(new InetSocketAddress(address, port), 500);
return serverSocket;
}
@@ -73,7 +73,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
@@ -84,7 +84,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
@@ -95,7 +95,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket) ctx.getSocketFactory().createSocket();
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/37d33b20/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index 3111deb..f25c761 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -35,6 +35,7 @@ import org.slf4j.LoggerFactory;
import org.apache.cassandra.concurrent.NamedThreadFactory;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.config.EncryptionOptions.ClientEncryptionOptions;
+import org.apache.cassandra.security.SSLFactory;
import org.apache.thrift.TException;
import org.apache.thrift.TProcessor;
impor
cassandra git commit: ninja-fix nit from casandra-8265 commit (make repeated strings a constant)
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 b93f48a5d -> 37d33b208
ninja-fix nit from casandra-8265 commit (make repeated strings a constant)
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/37d33b20
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/37d33b20
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/37d33b20
Branch: refs/heads/cassandra-2.0
Commit: 37d33b2086abb8e073a3ec7f9de23150eb49fb32
Parents: b93f48a
Author: Jason Brown
Authored: Wed Nov 12 16:12:36 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 16:12:36 2014 -0800
--
src/java/org/apache/cassandra/security/SSLFactory.java| 10 +-
.../apache/cassandra/thrift/CustomTThreadPoolServer.java | 3 ++-
src/java/org/apache/cassandra/transport/Server.java | 2 +-
src/java/org/apache/cassandra/transport/SimpleClient.java | 2 +-
4 files changed, 9 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/37d33b20/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index 260c828..956ba67 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -50,7 +50,7 @@ import com.google.common.collect.Sets;
public final class SSLFactory
{
private static final Logger logger =
LoggerFactory.getLogger(SSLFactory.class);
-
+public static final String[] ACCEPTED_PROTOCOLS = new String[]
{"SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2"};
private static boolean checkedExpiry = false;
public static SSLServerSocket getServerSocket(EncryptionOptions options,
InetAddress address, int port) throws IOException
@@ -61,7 +61,7 @@ public final class SSLFactory
String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
serverSocket.setNeedClientAuth(options.require_client_auth);
-serverSocket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
serverSocket.bind(new InetSocketAddress(address, port), 500);
return serverSocket;
}
@@ -73,7 +73,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
@@ -84,7 +84,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
@@ -95,7 +95,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket) ctx.getSocketFactory().createSocket();
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
-socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
+socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/37d33b20/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index 3111deb..f25c761 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -35,6 +35,7 @@ import org.slf4j.LoggerFactory;
import org.apache.cassandra.concurrent.NamedThreadFactory;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.config.EncryptionOptions.ClientEncryptionOptions;
+import org.apache.cassandra.security.SSLFactory;
import org.apache.thrift.TException;
import org.apache.thrift.TProcessor;
impor
[1/3] cassandra git commit: Disable SSLv3 for POODLE
Repository: cassandra
Updated Branches:
refs/heads/trunk eb1c2831c -> e15cf78b5
Disable SSLv3 for POODLE
patch by Jeremiah Jordan; reviewed by jasobrown for CASSANDRA-8265
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b93f48a5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b93f48a5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b93f48a5
Branch: refs/heads/trunk
Commit: b93f48a5db321bf7c9fb55a800ed6ab2d6f6b102
Parents: be79142
Author: Jason Brown
Authored: Wed Nov 12 15:58:13 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 15:58:13 2014 -0800
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/security/SSLFactory.java | 4
.../org/apache/cassandra/thrift/CustomTThreadPoolServer.java | 4
src/java/org/apache/cassandra/transport/Server.java | 1 +
src/java/org/apache/cassandra/transport/SimpleClient.java| 1 +
5 files changed, 11 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 47e611c..809a102 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Disable SSLv3 for POODLE (CASSANDRA-8265)
* Fix millisecond timestamps in Tracing (CASSANDRA-8297)
* Include keyspace name in error message when there are insufficient
live nodes to stream from (CASSANDRA-8221)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index 3cb0670..260c828 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -61,6 +61,7 @@ public final class SSLFactory
String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
serverSocket.setNeedClientAuth(options.require_client_auth);
+serverSocket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
serverSocket.bind(new InetSocketAddress(address, port), 500);
return serverSocket;
}
@@ -72,6 +73,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
@@ -82,6 +84,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
@@ -92,6 +95,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket) ctx.getSocketFactory().createSocket();
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index d1a3304..3111deb 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -27,6 +27,8 @@ import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
+import javax.net.ssl.SSLServerSocket;
+
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -251,6 +253,8 @@ public class CustomTThreadPoolServer extends TServer
params.requireClientAuth(true);
}
TServerSocket sslServer =
TSSLTransportFactory.getServerSocket(addr.getPort()
[2/3] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1
Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/transport/Server.java
src/java/org/apache/cassandra/transport/SimpleClient.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1217afb5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1217afb5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1217afb5
Branch: refs/heads/trunk
Commit: 1217afb5cf68e1d1d8bfc951b74fc4e0fa7b17f2
Parents: 26ea0f6 b93f48a
Author: Jason Brown
Authored: Wed Nov 12 16:07:12 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 16:07:12 2014 -0800
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/security/SSLFactory.java | 4
.../org/apache/cassandra/thrift/CustomTThreadPoolServer.java | 4
src/java/org/apache/cassandra/transport/Server.java | 2 +-
src/java/org/apache/cassandra/transport/SimpleClient.java| 1 +
5 files changed, 11 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1217afb5/CHANGES.txt
--
diff --cc CHANGES.txt
index 51a3ed0,809a102..1910f31
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,8 -1,5 +1,9 @@@
-2.0.12:
+2.1.3
+ * Support for frozen collections (CASSANDRA-7859)
+ * Fix overflow on histogram computation (CASSANDRA-8028)
+ * Have paxos reuse the timestamp generation of normal queries
(CASSANDRA-7801)
+Merged from 2.0:
+ * Disable SSLv3 for POODLE (CASSANDRA-8265)
* Fix millisecond timestamps in Tracing (CASSANDRA-8297)
* Include keyspace name in error message when there are insufficient
live nodes to stream from (CASSANDRA-8221)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1217afb5/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1217afb5/src/java/org/apache/cassandra/transport/Server.java
--
diff --cc src/java/org/apache/cassandra/transport/Server.java
index 8af6ee8,092e1ba..2a60242
--- a/src/java/org/apache/cassandra/transport/Server.java
+++ b/src/java/org/apache/cassandra/transport/Server.java
@@@ -324,10 -296,13 +324,10 @@@ public class Server implements Cassandr
sslEngine.setUseClientMode(false);
sslEngine.setEnabledCipherSuites(encryptionOptions.cipher_suites);
sslEngine.setNeedClientAuth(encryptionOptions.require_client_auth);
-
+ sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello",
"TLSv1", "TLSv1.1", "TLSv1.2"});
-
SslHandler sslHandler = new SslHandler(sslEngine);
-sslHandler.setIssueHandshake(true);
-ChannelPipeline pipeline = super.getPipeline();
-pipeline.addFirst("ssl", sslHandler);
-return pipeline;
+super.initChannel(channel);
+channel.pipeline().addFirst("ssl", sslHandler);
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1217afb5/src/java/org/apache/cassandra/transport/SimpleClient.java
--
diff --cc src/java/org/apache/cassandra/transport/SimpleClient.java
index 3cf9b7b,3bcf751..2e1e45e
--- a/src/java/org/apache/cassandra/transport/SimpleClient.java
+++ b/src/java/org/apache/cassandra/transport/SimpleClient.java
@@@ -253,7 -259,11 +253,8 @@@ public class SimpleClien
SSLEngine sslEngine = sslContext.createSSLEngine();
sslEngine.setUseClientMode(true);
sslEngine.setEnabledCipherSuites(encryptionOptions.cipher_suites);
+ sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello",
"TLSv1", "TLSv1.1", "TLSv1.2"});
-ChannelPipeline pipeline = super.getPipeline();
-
-pipeline.addFirst("ssl", new SslHandler(sslEngine));
-return pipeline;
+channel.pipeline().addFirst("ssl", new SslHandler(sslEngine));
}
}
[3/3] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e15cf78b Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e15cf78b Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e15cf78b Branch: refs/heads/trunk Commit: e15cf78b551b9e7329eb05ab8e6fead905bbfeee Parents: eb1c283 1217afb Author: Jason Brown Authored: Wed Nov 12 16:07:44 2014 -0800 Committer: Jason Brown Committed: Wed Nov 12 16:07:44 2014 -0800 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/security/SSLFactory.java | 4 .../org/apache/cassandra/thrift/CustomTThreadPoolServer.java | 4 src/java/org/apache/cassandra/transport/Server.java | 2 +- src/java/org/apache/cassandra/transport/SimpleClient.java| 1 + 5 files changed, 11 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e15cf78b/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e15cf78b/src/java/org/apache/cassandra/transport/Server.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e15cf78b/src/java/org/apache/cassandra/transport/SimpleClient.java --
[1/2] cassandra git commit: Disable SSLv3 for POODLE
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 26ea0f6d7 -> 1217afb5c
Disable SSLv3 for POODLE
patch by Jeremiah Jordan; reviewed by jasobrown for CASSANDRA-8265
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b93f48a5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b93f48a5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b93f48a5
Branch: refs/heads/cassandra-2.1
Commit: b93f48a5db321bf7c9fb55a800ed6ab2d6f6b102
Parents: be79142
Author: Jason Brown
Authored: Wed Nov 12 15:58:13 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 15:58:13 2014 -0800
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/security/SSLFactory.java | 4
.../org/apache/cassandra/thrift/CustomTThreadPoolServer.java | 4
src/java/org/apache/cassandra/transport/Server.java | 1 +
src/java/org/apache/cassandra/transport/SimpleClient.java| 1 +
5 files changed, 11 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 47e611c..809a102 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Disable SSLv3 for POODLE (CASSANDRA-8265)
* Fix millisecond timestamps in Tracing (CASSANDRA-8297)
* Include keyspace name in error message when there are insufficient
live nodes to stream from (CASSANDRA-8221)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index 3cb0670..260c828 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -61,6 +61,7 @@ public final class SSLFactory
String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
serverSocket.setNeedClientAuth(options.require_client_auth);
+serverSocket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
serverSocket.bind(new InetSocketAddress(address, port), 500);
return serverSocket;
}
@@ -72,6 +73,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
@@ -82,6 +84,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
@@ -92,6 +95,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket) ctx.getSocketFactory().createSocket();
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index d1a3304..3111deb 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -27,6 +27,8 @@ import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
+import javax.net.ssl.SSLServerSocket;
+
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -251,6 +253,8 @@ public class CustomTThreadPoolServer extends TServer
params.requireClientAuth(true);
}
TServerSocket sslServer =
TSSLTransportFactory.getServerSocke
[2/2] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1
Conflicts:
CHANGES.txt
src/java/org/apache/cassandra/transport/Server.java
src/java/org/apache/cassandra/transport/SimpleClient.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1217afb5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1217afb5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1217afb5
Branch: refs/heads/cassandra-2.1
Commit: 1217afb5cf68e1d1d8bfc951b74fc4e0fa7b17f2
Parents: 26ea0f6 b93f48a
Author: Jason Brown
Authored: Wed Nov 12 16:07:12 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 16:07:12 2014 -0800
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/security/SSLFactory.java | 4
.../org/apache/cassandra/thrift/CustomTThreadPoolServer.java | 4
src/java/org/apache/cassandra/transport/Server.java | 2 +-
src/java/org/apache/cassandra/transport/SimpleClient.java| 1 +
5 files changed, 11 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1217afb5/CHANGES.txt
--
diff --cc CHANGES.txt
index 51a3ed0,809a102..1910f31
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,8 -1,5 +1,9 @@@
-2.0.12:
+2.1.3
+ * Support for frozen collections (CASSANDRA-7859)
+ * Fix overflow on histogram computation (CASSANDRA-8028)
+ * Have paxos reuse the timestamp generation of normal queries
(CASSANDRA-7801)
+Merged from 2.0:
+ * Disable SSLv3 for POODLE (CASSANDRA-8265)
* Fix millisecond timestamps in Tracing (CASSANDRA-8297)
* Include keyspace name in error message when there are insufficient
live nodes to stream from (CASSANDRA-8221)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1217afb5/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1217afb5/src/java/org/apache/cassandra/transport/Server.java
--
diff --cc src/java/org/apache/cassandra/transport/Server.java
index 8af6ee8,092e1ba..2a60242
--- a/src/java/org/apache/cassandra/transport/Server.java
+++ b/src/java/org/apache/cassandra/transport/Server.java
@@@ -324,10 -296,13 +324,10 @@@ public class Server implements Cassandr
sslEngine.setUseClientMode(false);
sslEngine.setEnabledCipherSuites(encryptionOptions.cipher_suites);
sslEngine.setNeedClientAuth(encryptionOptions.require_client_auth);
-
+ sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello",
"TLSv1", "TLSv1.1", "TLSv1.2"});
-
SslHandler sslHandler = new SslHandler(sslEngine);
-sslHandler.setIssueHandshake(true);
-ChannelPipeline pipeline = super.getPipeline();
-pipeline.addFirst("ssl", sslHandler);
-return pipeline;
+super.initChannel(channel);
+channel.pipeline().addFirst("ssl", sslHandler);
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1217afb5/src/java/org/apache/cassandra/transport/SimpleClient.java
--
diff --cc src/java/org/apache/cassandra/transport/SimpleClient.java
index 3cf9b7b,3bcf751..2e1e45e
--- a/src/java/org/apache/cassandra/transport/SimpleClient.java
+++ b/src/java/org/apache/cassandra/transport/SimpleClient.java
@@@ -253,7 -259,11 +253,8 @@@ public class SimpleClien
SSLEngine sslEngine = sslContext.createSSLEngine();
sslEngine.setUseClientMode(true);
sslEngine.setEnabledCipherSuites(encryptionOptions.cipher_suites);
+ sslEngine.setEnabledProtocols(new String[] {"SSLv2Hello",
"TLSv1", "TLSv1.1", "TLSv1.2"});
-ChannelPipeline pipeline = super.getPipeline();
-
-pipeline.addFirst("ssl", new SslHandler(sslEngine));
-return pipeline;
+channel.pipeline().addFirst("ssl", new SslHandler(sslEngine));
}
}
[jira] [Created] (CASSANDRA-8304) Explore evicting replacement state sooner
Brandon Williams created CASSANDRA-8304: --- Summary: Explore evicting replacement state sooner Key: CASSANDRA-8304 URL: https://issues.apache.org/jira/browse/CASSANDRA-8304 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 3.0 As a follow-up to CASSANDRA-8260 Tyler suggests we evict and quarantine in step 2. I don't want to change any core gossip logic in 2.0 at this point, but his theory seems feasible and we should explore it for 3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Disable SSLv3 for POODLE
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 be7914229 -> b93f48a5d
Disable SSLv3 for POODLE
patch by Jeremiah Jordan; reviewed by jasobrown for CASSANDRA-8265
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b93f48a5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b93f48a5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b93f48a5
Branch: refs/heads/cassandra-2.0
Commit: b93f48a5db321bf7c9fb55a800ed6ab2d6f6b102
Parents: be79142
Author: Jason Brown
Authored: Wed Nov 12 15:58:13 2014 -0800
Committer: Jason Brown
Committed: Wed Nov 12 15:58:13 2014 -0800
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/security/SSLFactory.java | 4
.../org/apache/cassandra/thrift/CustomTThreadPoolServer.java | 4
src/java/org/apache/cassandra/transport/Server.java | 1 +
src/java/org/apache/cassandra/transport/SimpleClient.java| 1 +
5 files changed, 11 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 47e611c..809a102 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Disable SSLv3 for POODLE (CASSANDRA-8265)
* Fix millisecond timestamps in Tracing (CASSANDRA-8297)
* Include keyspace name in error message when there are insufficient
live nodes to stream from (CASSANDRA-8221)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index 3cb0670..260c828 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -61,6 +61,7 @@ public final class SSLFactory
String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
serverSocket.setNeedClientAuth(options.require_client_auth);
+serverSocket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
serverSocket.bind(new InetSocketAddress(address, port), 500);
return serverSocket;
}
@@ -72,6 +73,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
@@ -82,6 +84,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port);
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
@@ -92,6 +95,7 @@ public final class SSLFactory
SSLSocket socket = (SSLSocket) ctx.getSocketFactory().createSocket();
String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
socket.setEnabledCipherSuites(suits);
+socket.setEnabledProtocols(new String[] {"SSLv2Hello", "TLSv1",
"TLSv1.1", "TLSv1.2"});
return socket;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b93f48a5/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index d1a3304..3111deb 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -27,6 +27,8 @@ import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
+import javax.net.ssl.SSLServerSocket;
+
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -251,6 +253,8 @@ public class CustomTThreadPoolServer extends TServer
params.requireClientAuth(true);
}
TServerSocket sslServer =
TSSLTransportFactory.getServerSocke
[jira] [Commented] (CASSANDRA-8289) Allow users to debug/test UDF
[
https://issues.apache.org/jira/browse/CASSANDRA-8289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208943#comment-14208943
]
Robert Stupp commented on CASSANDRA-8289:
-
Initial draft working. [Code is
here|https://github.com/snazy/cassandra/tree/8289-udftest/tools/udftest/src]
Basically allows to write code like the following.
{{penetrate}} calls the UDF with many variations and combinations on input
parameters like {{null}} or {{Double.NaN}} to see if the UDF fails for some
(maybe uncommon) argument values.
{{execute}} calls the UDF with the arguments provided.
{code}
public class UDFTestTest
{
@Test
public void basicTest() throws Throwable
{
UDF udf = UDFs.create("CREATE FUNCTION foo(inp int, d double) RETURNS
text LANGUAGE java AS 'return \"foo\";'");
udf.penetrate();
}
@Test(expected = InvalidRequestException.class)
public void npeTest() throws Throwable
{
UDF udf = UDFs.create("CREATE FUNCTION foo(inp int, d double) RETURNS
text LANGUAGE java AS 'return inp.toString() + d;'");
udf.penetrate();
}
@Test
public void executionTest() throws Throwable
{
UDF udf = UDFs.create("CREATE FUNCTION foo(inp int, d double) RETURNS
text LANGUAGE java AS 'return \"x\" + inp + \"x\" + d + \"x\";'");
Assert.assertEquals("xnullxnullx", udf.execute(null, null));
Assert.assertEquals("x5x9.1x", udf.execute(5, 9.1d));
}
}
{code}
> Allow users to debug/test UDF
> -
>
> Key: CASSANDRA-8289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8289
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: udf
> Fix For: 3.0
>
>
> Currently it's not possible to execute unit tests against UDFs nor is it
> possible to debug them.
> Idea is to provide some kind of minimalistic "framework" to execute at least
> scalar UDFs from a unit test.
> Basically that UDF-executor would take the information that 'CREATE FUNCTION'
> takes, compiles that UDF and allows the user to call it using plain java
> calls.
> In case of the Java language it could also generate Java source files to
> enable users to set breakpoints.
> It could also check for timeouts to identify e.g. "endless loop" scenarios or
> do some byte code analysis to check for "evil" package usage.
> For example:
> {code}
> import org.apache.cassandra.udfexec.*
> public class MyUnitTest {
> @Test
> public void testIt() {
> UDFExec sinExec = UDFExec.compile("sin", "java",
> Double.class, // return type
> Double.class // argument type(s)
> );
> sinExec.call(2.0d);
> sinExec.call(null);
> }
> }
> {code}
> Note: this one is not intended to do some "magic" to start a debugger on a C*
> node and debug it there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8260) Replacing a node can leave the old node in system.peers on the replacement
[ https://issues.apache.org/jira/browse/CASSANDRA-8260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-8260: Reviewer: Jason Brown (was: Tyler Hobbs) > Replacing a node can leave the old node in system.peers on the replacement > -- > > Key: CASSANDRA-8260 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8260 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams > Fix For: 2.0.12 > > Attachments: 8260.txt > > > Here's what happens: > Nodes: X, Y, Z. Z replaces Y which is dead. > 0. Replacement finishes > 1. Z removes Y, quarantines and evicts (that is, removes the state) > 2. X sees the replacement, quarantines, but keeps state > 3. 60s elapses > 4. quarantine on Z expires > 5. X sends syn to Z, repopulates Y endpoint state and persists to > system.peers, but Z sees the conflict and does not update tMD for Y. > 6. FatClient timer on Z starts counting. > 7. quarantine on X expires, fat client has been idle, evicts and > re-quarantines > 8. 30s elapses > 9. Fat client timeout occurs on Z, evicts and re-quarantines > 10. 30s elapses > 11. quarantine on X expires, so it never gets repopulated with Y since Z > already removed it > It's important to note here that there is a small but relevant gap between > steps 1 and 2, which then correlates to steps 4 and 5, and step 5 is where > the problem occurs. This also explains why it looks related to RING_DELAY, > since the quarantine is RING_DELAY * 2, but Y never quarantines and the fat > client timeout is RING_DELAY, effectively making the discrepancy near equal > to RING_DELAY in the end. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8228) Log malfunctioning host on prepareForRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208902#comment-14208902 ] Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-8228: - [~ garo5], Do you suggest to list all the host addresses in the error message? Thanks > Log malfunctioning host on prepareForRepair > --- > > Key: CASSANDRA-8228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8228 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Juho Mäkinen >Priority: Trivial > Labels: lhf > > Repair startup goes thru ActiveRepairService.prepareForRepair() which might > result with "Repair failed with error Did not get positive replies from all > endpoints." error, but there's no other logging regarding to this error. > It seems that it would be trivial to modify the prepareForRepair() to log the > host address which caused the error, thus ease the debugging effort. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8298) cassandra-stress legacy
[ https://issues.apache.org/jira/browse/CASSANDRA-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs reassigned CASSANDRA-8298: -- Assignee: T Jake Luciani (was: Tyler Hobbs) > cassandra-stress legacy > > > Key: CASSANDRA-8298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8298 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Centos 6.5 Cassandra 2.1.1 >Reporter: Edgardo Vega >Assignee: T Jake Luciani > > Running cassandra-stress legacy failed immediately with a error. > Running in legacy support mode. Translating command to: > stress write n=100 -col n=fixed(5) size=fixed(34) data=repeat(1) -rate > threads=50 -log interval=10 -mode thrift > Invalid parameter data=repeat(1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8299) cassandra-stress unique keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs reassigned CASSANDRA-8299: -- Assignee: T Jake Luciani (was: Tyler Hobbs) > cassandra-stress unique keys > > > Key: CASSANDRA-8299 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8299 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Centos 6.5 Cassandra version 2.1.1 >Reporter: Edgardo Vega >Assignee: T Jake Luciani > > In the old stress tool you could use -n 1 and get 1 unique keys in > the keyspace. > In the new stress tool there doesn't seem to be a way to do this. For example > if I have the following definition: > table_definition: | > CREATE TABLE table( > key uuid PRIMARY KEY, > col1 text, > col2 text, > col3 text > ) WITH comment='A table' > ### Column Distribution Specifications ### > columnspec: > - name: key > size: fixed(36) > population: uniform(1..100B) > - name: col1 > size: fixed(100) > - name: col2 > size: fixed(100) > - name: col3 > size: fixed(100) > and then run > cassandra-stress user n=1 profile=stress.yaml ops\(insert=1\) > If you look at the keyspace was only 59000 keys. The new tool needs to be > able to generated unique ids. In our tested we want to see how the number of > keys effects the cluster when doing queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7124) Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
[
https://issues.apache.org/jira/browse/CASSANDRA-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208895#comment-14208895
]
Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-7124:
-
If we change the return type of parallelAllSSTableOperation, one more
challenge is that down the execution chain, at the calling level where the
"forceKeyspaceCleanup" method is called, it expects an int return value. So
till this point you cannot bubble up the Future object collection. Somewhere
you have to drop that and return an int. In the case of the repair command, it
starts the execution of a thread and then it increments a new AtomicInteger()
and returns that number as the return value. So wouldn't it be better in the
parallelAllSSTableOperation method itself we return something like and
AtomicInteger() or something like that? So that we will not have issues down
the line.
Sorry about the long mails. I want to make sure that we do it right in the
first place it self. Thanks
> Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
>
>
> Key: CASSANDRA-7124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7124
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
> Attachments: cassandra-trunk-temp-7124.txt
>
>
> If {{nodetool cleanup}} or some other long-running operation takes too long
> to complete, you'll see an error like the one in CASSANDRA-2126, so you can't
> tell if the operation completed successfully or not. CASSANDRA-4767 fixed
> this for repairs with JMX notifications. We should do something similar for
> nodetool cleanup, compact, decommission, move, relocate, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208873#comment-14208873
]
Tyler Hobbs commented on CASSANDRA-8286:
[~blerer] can you review?
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.0.12, 2.1.3
>
> Attachments: 8286-2.0.txt, 8286-2.1.txt, 8286-trunk.txt
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8286) Regression in ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-8286:
---
Attachment: 8286-2.0.txt
8286-trunk.txt
8286-2.1.txt
In 2.0, the problem was in {{SelectStatement.processOrderingClause()}} where
{{ColumnIdentifier.Raw}} instances were being compared with
{{ColumnIdentifier}} instances.
In 2.1 and trunk, the behavior of {{processOrderingClause()}} was changed, so
that problem didn't appear. However, there were two additional issues:
First, in {{Selection.usingFunctions()}} simply checked {{instanceof
ColumnIdentifier}}, which is false for {{ColumnIdentifier.Raw}}, causing all
selections to be treated as function/field selections
({{SelectionWithFunctions}}).
Second, there was an existing bug with {{SelectionWithFunctions}}. In
{{Selection.addColumnForOrdering()}}, the internal list of {{columns}} is
updated, which works for {{SimpleSelection}}, but is insufficient for
{{SelectionWithFunctions}}, which depends on its pre-built list of
{{Selectors}}. So, if there were any functions or field selections, {{ORDER
BY}} columns would not be properly added to the list of selections. Since the
previously mentioned bug resulted in all selections being
{{SelectionWithFunctions}}, the normal selection case was also broken.
The 2.1 and trunk patches override {{addColumnForOrdering()}} in
{{SelectionWithFunctions}} to update the selectors, and I pushed an [additional
dtest|https://github.com/riptano/cassandra-dtest/commit/da86a8eae38179c12b3576ec3d4beaaa0750144c]
to cover selecting functions with {{ORDER BY}} clauses.
> Regression in ORDER BY
> --
>
> Key: CASSANDRA-8286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8286
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.0.12, 2.1.3
>
> Attachments: 8286-2.0.txt, 8286-2.1.txt, 8286-trunk.txt
>
>
> The dtest {{cql_tests.py:TestCQL.order_by_multikey_test}} is now failing in
> 2.0:
> http://cassci.datastax.com/job/cassandra-2.0_dtest/lastCompletedBuild/testReport/cql_tests/TestCQL/order_by_multikey_test/history/
> This failure began at the commit for CASSANDRA-8178.
> The error message reads
> {code}==
> ERROR: order_by_multikey_test (cql_tests.TestCQL)
> --
> Traceback (most recent call last):
> File "/Users/philipthompson/cstar/cassandra-dtest/dtest.py", line 524, in
> wrapped
> f(obj)
> File "/Users/philipthompson/cstar/cassandra-dtest/cql_tests.py", line 1807,
> in order_by_multikey_test
> res = cursor.execute("SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;")
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 1281,
> in execute
> result = future.result(timeout)
> File "/Library/Python/2.7/site-packages/cassandra/cluster.py", line 2771,
> in result
> raise self._final_exception
> InvalidRequest: code=2200 [Invalid query] message="ORDER BY could not be used
> on columns missing in select clause."{code}
> and occurs at the query {{SELECT col1 FROM test WHERE my_id in('key1',
> 'key2', 'key3') ORDER BY col1;}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7124) Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
[
https://issues.apache.org/jira/browse/CASSANDRA-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208817#comment-14208817
]
Rajanarayanan Thottuvaikkatumana commented on CASSANDRA-7124:
-
[~yukim], Thanks for the quick response. Let me tackle the issues one step at a
time. Regarding the changes of your suggestion "Make
CompactionManager#parallelAllSSTableOperation asynchronous by returning
Future", here are my comments/observations:
1) In the parallelAllSSTableOperation method, there are more than one Future
object and it is stored in an ArrayList. Then the executor.submit callable is
added to the list of Futures. The for each of the Future object, it calls the
get method and here is the waiting happens till the job completion (the
blocking happens here). For making it asynchronous, we should get rid of the
iteration of the Future objects and the call to get. Is that the right
understanding
2) Since we are dealing with a list of Future objects, we should be returning
the List of Future objects. Right?
3) There is a "markAllCompacting()" call before starting the method and there
is an "unmarkCompacting(compactingSSTables)" at the end. Since we are making it
asynchronous, how do we deal with the marking/unmark business?
4) In the beginning, we are checking whether the "compactingSSTables" are empty
or null. Since we are returning Future objects, in these cases is it OK to
return null in this case when "compactingSSTables" are empty or null?
Thanks a lot in advance.
> Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
>
>
> Key: CASSANDRA-7124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7124
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
> Attachments: cassandra-trunk-temp-7124.txt
>
>
> If {{nodetool cleanup}} or some other long-running operation takes too long
> to complete, you'll see an error like the one in CASSANDRA-2126, so you can't
> tell if the operation completed successfully or not. CASSANDRA-4767 fixed
> this for repairs with JMX notifications. We should do something similar for
> nodetool cleanup, compact, decommission, move, relocate, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-5483) Repair tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208811#comment-14208811 ] Joshua McKenzie commented on CASSANDRA-5483: Linked branch looks good, renames are solid, tests out fine. 300MB of repairs at RF=3 generated around 300k of event trace data so I'm comfortable with the current level; we can revisit paring that down in the future as appropriate. Patch doesn't apply/rebase to current trunk cleanly - if I could get you to do a quick rebase we'll be ready to wrap this up. Thanks for all the hard work on this! > Repair tracing > -- > > Key: CASSANDRA-5483 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5483 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Yuki Morishita >Assignee: Ben Chan >Priority: Minor > Labels: repair > Fix For: 3.0 > > Attachments: 5483-full-trunk.txt, > 5483-v06-04-Allow-tracing-ttl-to-be-configured.patch, > 5483-v06-05-Add-a-command-column-to-system_traces.events.patch, > 5483-v06-06-Fix-interruption-in-tracestate-propagation.patch, > 5483-v07-07-Better-constructor-parameters-for-DebuggableThreadPoolExecutor.patch, > 5483-v07-08-Fix-brace-style.patch, > 5483-v07-09-Add-trace-option-to-a-more-complete-set-of-repair-functions.patch, > 5483-v07-10-Correct-name-of-boolean-repairedAt-to-fullRepair.patch, > 5483-v08-11-Shorten-trace-messages.-Use-Tracing-begin.patch, > 5483-v08-12-Trace-streaming-in-Differencer-StreamingRepairTask.patch, > 5483-v08-13-sendNotification-of-local-traces-back-to-nodetool.patch, > 5483-v08-14-Poll-system_traces.events.patch, > 5483-v08-15-Limit-trace-notifications.-Add-exponential-backoff.patch, > 5483-v09-16-Fix-hang-caused-by-incorrect-exit-code.patch, > 5483-v10-17-minor-bugfixes-and-changes.patch, > 5483-v10-rebased-and-squashed-471f5cc.patch, 5483-v11-01-squashed.patch, > 5483-v11-squashed-nits.patch, 5483-v12-02-cassandra-yaml-ttl-doc.patch, > 5483-v13-608fb03-May-14-trace-formatting-changes.patch, > 5483-v14-01-squashed.patch, > 5483-v15-02-Hook-up-exponential-backoff-functionality.patch, > 5483-v15-03-Exact-doubling-for-exponential-backoff.patch, > 5483-v15-04-Re-add-old-StorageService-JMX-signatures.patch, > 5483-v15-05-Move-command-column-to-system_traces.sessions.patch, > 5483-v15.patch, 5483-v17-00.patch, 5483-v17-01.patch, 5483-v17.patch, > ccm-repair-test, cqlsh-left-justify-text-columns.patch, > prerepair-vs-postbuggedrepair.diff, test-5483-system_traces-events.txt, > trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch, > trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch, > tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt, > tr...@8ebeee1-5483-v01-002-simple-repair-tracing.txt, > v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch, > v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch, > v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch > > > I think it would be nice to log repair stats and results like query tracing > stores traces to system keyspace. With it, you don't have to lookup each log > file to see what was the status and how it performed the repair you invoked. > Instead, you can query the repair log with session ID to see the state and > stats of all nodes involved in that repair session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[ https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208807#comment-14208807 ] Robert Stupp commented on CASSANDRA-7386: - Thanks for the explanation. The root cause for CASSANDRA-5605 (as far as I understand) was that the sum of "space reserved for compactions" + "required space" did not match any disk. I'm with with ignoring write-rate and read-rate - seems reasonable now. Any assumption about the "load" of the disks would depend on the usage of the data (which we cannot foresee ... yet). Moving to something else that takes the "hotness" of the sstables into account is the way to go - but not easy. Requires a huge number of metric instances (. Not easy to combine these metrics as a "forecast" for compactions. Yea - basically only the current disk space seems to be usable for this ticket. Will make it like that. > JBOD threshold to prevent unbalanced disk utilization > - > > Key: CASSANDRA-7386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7386 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Assignee: Robert Stupp >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, > mean-writevalue-7disks.png, patch_2_1_branch_proto.diff, > sstable-count-second-run.png > > > Currently the pick the disks are picked first by number of current tasks, > then by free space. This helps with performance but can lead to large > differences in utilization in some (unlikely but possible) scenarios. Ive > seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and > STCS (although my suspicion is that STCS makes it worse since harder to be > balanced). > I purpose the algorithm change a little to have some maximum range of > utilization where it will pick by free space over load (acknowledging it can > be slower). So if a disk A is 30% full and disk B is 5% full it will never > pick A over B until it balances out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8265) Disable SSLv3 for POODLE
[ https://issues.apache.org/jira/browse/CASSANDRA-8265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-8265: --- Fix Version/s: 2.1.3 > Disable SSLv3 for POODLE > > > Key: CASSANDRA-8265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8265 > Project: Cassandra > Issue Type: Bug >Reporter: Jeremiah Jordan >Assignee: Jeremiah Jordan > Fix For: 2.0.12, 2.1.3 > > Attachments: 0001-CASSANDRA-8265-Disable-SSLv3-on-all-sockets.txt > > > We should probably disable SSLv3. > http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8265) Disable SSLv3 for POODLE
[ https://issues.apache.org/jira/browse/CASSANDRA-8265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-8265: --- Reviewer: Jason Brown > Disable SSLv3 for POODLE > > > Key: CASSANDRA-8265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8265 > Project: Cassandra > Issue Type: Bug >Reporter: Jeremiah Jordan >Assignee: Jeremiah Jordan > Fix For: 2.0.12, 2.1.3 > > Attachments: 0001-CASSANDRA-8265-Disable-SSLv3-on-all-sockets.txt > > > We should probably disable SSLv3. > http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8265) Disable SSLv3 for POODLE
[ https://issues.apache.org/jira/browse/CASSANDRA-8265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-8265: --- Fix Version/s: 2.0.12 > Disable SSLv3 for POODLE > > > Key: CASSANDRA-8265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8265 > Project: Cassandra > Issue Type: Bug >Reporter: Jeremiah Jordan >Assignee: Jeremiah Jordan > Fix For: 2.0.12, 2.1.3 > > Attachments: 0001-CASSANDRA-8265-Disable-SSLv3-on-all-sockets.txt > > > We should probably disable SSLv3. > http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8265) Disable SSLv3 for POODLE
[ https://issues.apache.org/jira/browse/CASSANDRA-8265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan updated CASSANDRA-8265: --- Attachment: 0001-CASSANDRA-8265-Disable-SSLv3-on-all-sockets.txt > Disable SSLv3 for POODLE > > > Key: CASSANDRA-8265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8265 > Project: Cassandra > Issue Type: Bug >Reporter: Jeremiah Jordan >Assignee: Jeremiah Jordan > Attachments: 0001-CASSANDRA-8265-Disable-SSLv3-on-all-sockets.txt > > > We should probably disable SSLv3. > http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8193) Multi-DC parallel snapshot repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208794#comment-14208794 ] Yuki Morishita commented on CASSANDRA-8193: --- Say you have RF of dc1=1, dc2=1, dc3=1, then your DatacenterAwareRequestCoordinator will send merkle tree requests to all datacenters at once, which ends up to the same behavior as ParallelRequestCoordinator. bq. I think it's more of a performance improvement rather than a new feature. I gree this is improvement, but at least we need to preserve current behavior. If you can make this to be an extension, then, in my opinion, it is safe to put this into 2.0. > Multi-DC parallel snapshot repair > - > > Key: CASSANDRA-8193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8193 > Project: Cassandra > Issue Type: Improvement >Reporter: Jimmy Mårdell >Assignee: Jimmy Mårdell >Priority: Minor > Fix For: 2.0.12 > > Attachments: cassandra-2.0-8193-1.txt > > > The current behaviour of snapshot repair is to let one node at a time > calculate a merkle tree. This is to ensure only one node at a time is doing > the expensive calculation. The drawback is that it takes even longer time to > do the merkle tree calculation. > In a multi-DC setup, I think it would make more sense to have one node in > each DC calculate the merkle tree at the same time. This would yield a > significant improvement when you have many data centers. > I'm not sure how relevant this is in 2.1, but I don't see us upgrading to 2.1 > any time soon. Unless there is an obvious drawback that I'm missing, I'd like > to implement this in the 2.0 branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/3] cassandra git commit: Fix millisecond timestamps in Tracing
Repository: cassandra
Updated Branches:
refs/heads/trunk cf94e3c31 -> eb1c2831c
Fix millisecond timestamps in Tracing
patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe for
CASSANDRA-8297
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/be791422
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/be791422
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/be791422
Branch: refs/heads/trunk
Commit: be791422972a2ee485239e3d724ffcab3d8fdace
Parents: a6802aa
Author: Aleksey Yeschenko
Authored: Wed Nov 12 23:44:00 2014 +0300
Committer: Aleksey Yeschenko
Committed: Wed Nov 12 23:46:53 2014 +0300
--
CHANGES.txt | 1 +
.../org/apache/cassandra/config/CFMetaData.java | 4 ++--
.../org/apache/cassandra/tracing/Tracing.java | 21 +---
3 files changed, 8 insertions(+), 18 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 842643c..47e611c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Fix millisecond timestamps in Tracing (CASSANDRA-8297)
* Include keyspace name in error message when there are insufficient
live nodes to stream from (CASSANDRA-8221)
* Avoid overlap in L1 when L0 contains many nonoverlapping
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 391341f..9d69710 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -217,7 +217,7 @@ public final class CFMetaData
+ "started_at
timestamp,"
+ "parameters
map,"
+ "duration int"
- + ") WITH
COMMENT='traced sessions'",
+ + ") WITH
COMMENT='traced sessions' AND default_time_to_live=86400",
Tracing.TRACE_KS);
public static final CFMetaData TraceEventsCf = compile("CREATE TABLE " +
Tracing.EVENTS_CF + " ("
@@ -228,7 +228,7 @@ public final class CFMetaData
+ "activity text,"
+ "source_elapsed
int,"
+ "PRIMARY KEY
(session_id, event_id)"
- + ")",
+ + ") WITH
default_time_to_live=86400",
Tracing.TRACE_KS);
public static final CFMetaData BatchlogCf = compile("CREATE TABLE " +
SystemKeyspace.BATCHLOG_CF + " ("
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/src/java/org/apache/cassandra/tracing/Tracing.java
--
diff --git a/src/java/org/apache/cassandra/tracing/Tracing.java
b/src/java/org/apache/cassandra/tracing/Tracing.java
index 88239be..b38dc10 100644
--- a/src/java/org/apache/cassandra/tracing/Tracing.java
+++ b/src/java/org/apache/cassandra/tracing/Tracing.java
@@ -59,15 +59,13 @@ public class Tracing
public static final String SESSIONS_CF = "sessions";
public static final String TRACE_HEADER = "TraceSession";
-private static final int TTL = 24 * 3600;
-
private static final Logger logger =
LoggerFactory.getLogger(Tracing.class);
private final InetAddress localAddress = FBUtilities.getLocalAddress();
-private final ThreadLocal state = new
ThreadLocal();
+private final ThreadLocal state = new ThreadLocal<>();
-private final ConcurrentMap sessions = new
ConcurrentHashMap();
+private final ConcurrentMap sessions = new
ConcurrentHashMap<>();
public static final Tracing instance = new Tracing();
@@ -93,16 +91,7 @@ public class Tracing
private static void addColumn(ColumnFamily cf, ByteBuffer name, ByteBuffer
value)
{
-cf.addColumn(new ExpiringColumn(name, value,
System.currentTimeMillis(), TTL));
-}
-
-public void addParameterColumns(ColumnFamily cf, Map
rawPayload)
-{
-for (Map.Entry entry : rawPayload.entrySet())
-{
-
[2/3] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt src/java/org/apache/cassandra/tracing/Tracing.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/26ea0f6d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/26ea0f6d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/26ea0f6d Branch: refs/heads/trunk Commit: 26ea0f6d7442760d1aeb57ce0b8ab6f86c3190a8 Parents: deff175 be79142 Author: Aleksey Yeschenko Authored: Thu Nov 13 00:34:14 2014 +0300 Committer: Aleksey Yeschenko Committed: Thu Nov 13 00:34:14 2014 +0300 -- CHANGES.txt | 2 + .../org/apache/cassandra/config/CFMetaData.java | 4 +- .../apache/cassandra/tracing/TraceState.java| 20 ++--- .../org/apache/cassandra/tracing/Tracing.java | 80 +--- 4 files changed, 36 insertions(+), 70 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/26ea0f6d/CHANGES.txt -- diff --cc CHANGES.txt index 5b63f48,47e611c..51a3ed0 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,40 -1,11 +1,42 @@@ -2.0.12: +2.1.3 + * Support for frozen collections (CASSANDRA-7859) + * Fix overflow on histogram computation (CASSANDRA-8028) + * Have paxos reuse the timestamp generation of normal queries (CASSANDRA-7801) +Merged from 2.0: + * Fix millisecond timestamps in Tracing (CASSANDRA-8297) * Include keyspace name in error message when there are insufficient live nodes to stream from (CASSANDRA-8221) * Avoid overlap in L1 when L0 contains many nonoverlapping sstables (CASSANDRA-8211) * Improve PropertyFileSnitch logging (CASSANDRA-8183) - * Abort liveRatio calculation if the memtable is flushed (CASSANDRA-8164) + ++ +2.1.2 + * (cqlsh) parse_for_table_meta errors out on queries with undefined + grammars (CASSANDRA-8262) + * (cqlsh) Fix SELECT ... TOKEN() function broken in C* 2.1.1 (CASSANDRA-8258) + * Fix Cassandra crash when running on JDK8 update 40 (CASSANDRA-8209) + * Optimize partitioner tokens (CASSANDRA-8230) + * Improve compaction of repaired/unrepaired sstables (CASSANDRA-8004) + * Make cache serializers pluggable (CASSANDRA-8096) + * Fix issues with CONTAINS (KEY) queries on secondary indexes + (CASSANDRA-8147) + * Fix read-rate tracking of sstables for some queries (CASSANDRA-8239) + * Fix default timestamp in QueryOptions (CASSANDRA-8246) + * Set socket timeout when reading remote version (CASSANDRA-8188) + * Refactor how we track live size (CASSANDRA-7852) + * Make sure unfinished compaction files are removed (CASSANDRA-8124) + * Fix shutdown when run as Windows service (CASSANDRA-8136) + * Fix DESCRIBE TABLE with custom indexes (CASSANDRA-8031) + * Fix race in RecoveryManagerTest (CASSANDRA-8176) + * Avoid IllegalArgumentException while sorting sstables in + IndexSummaryManager (CASSANDRA-8182) + * Shutdown JVM on file descriptor exhaustion (CASSANDRA-7579) + * Add 'die' policy for commit log and disk failure (CASSANDRA-7927) + * Fix installing as service on Windows (CASSANDRA-8115) + * Fix CREATE TABLE for CQL2 (CASSANDRA-8144) + * Avoid boxing in ColumnStats min/max trackers (CASSANDRA-8109) +Merged from 2.0: * Correctly handle non-text column names in cql3 (CASSANDRA-8178) * Fix deletion for indexes on primary key columns (CASSANDRA-8206) * Add 'nodetool statusgossip' (CASSANDRA-8125) http://git-wip-us.apache.org/repos/asf/cassandra/blob/26ea0f6d/src/java/org/apache/cassandra/config/CFMetaData.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/26ea0f6d/src/java/org/apache/cassandra/tracing/TraceState.java -- diff --cc src/java/org/apache/cassandra/tracing/TraceState.java index cfff295,5fec633..399b6e9 --- a/src/java/org/apache/cassandra/tracing/TraceState.java +++ b/src/java/org/apache/cassandra/tracing/TraceState.java @@@ -29,9 -28,9 +29,9 @@@ import org.slf4j.helpers.MessageFormatt import org.apache.cassandra.concurrent.Stage; import org.apache.cassandra.concurrent.StageManager; import org.apache.cassandra.config.CFMetaData; - import org.apache.cassandra.db.ArrayBackedSortedColumns; ++import org.apache.cassandra.db.CFRowAdder; import org.apache.cassandra.db.ColumnFamily; -import org.apache.cassandra.db.RowMutation; -import org.apache.cassandra.db.TreeMapBackedSortedColumns; +import org.apache.cassandra.db.Mutation; import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.utils.FBUtilities; import org.apache.cassandra.utils.UUIDGen; @@@ -91,21 -87,21 +91,23 @@@ public class TraceStat public static vo
[3/3] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk
Conflicts:
src/java/org/apache/cassandra/config/CFMetaData.java
src/java/org/apache/cassandra/tracing/TraceState.java
src/java/org/apache/cassandra/tracing/Tracing.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eb1c2831
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eb1c2831
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eb1c2831
Branch: refs/heads/trunk
Commit: eb1c2831cdcd1b96710bdab4e4dad3e9ea48b5ab
Parents: cf94e3c 26ea0f6
Author: Aleksey Yeschenko
Authored: Thu Nov 13 01:11:09 2014 +0300
Committer: Aleksey Yeschenko
Committed: Thu Nov 13 01:11:09 2014 +0300
--
CHANGES.txt | 2 +
.../apache/cassandra/tracing/TraceKeyspace.java | 57 --
.../apache/cassandra/tracing/TraceState.java| 18 +-
.../org/apache/cassandra/tracing/Tracing.java | 63 ++--
4 files changed, 62 insertions(+), 78 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb1c2831/CHANGES.txt
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb1c2831/src/java/org/apache/cassandra/tracing/TraceKeyspace.java
--
diff --cc src/java/org/apache/cassandra/tracing/TraceKeyspace.java
index a20fadd,000..4d234bd
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/tracing/TraceKeyspace.java
+++ b/src/java/org/apache/cassandra/tracing/TraceKeyspace.java
@@@ -1,73 -1,0 +1,122 @@@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.tracing;
+
++import java.nio.ByteBuffer;
+import java.util.Arrays;
++import java.util.Date;
+import java.util.List;
++import java.util.Map;
+import java.util.concurrent.TimeUnit;
+
+import com.google.common.collect.ImmutableMap;
+
+import org.apache.cassandra.config.CFMetaData;
+import org.apache.cassandra.config.KSMetaData;
++import org.apache.cassandra.db.CFRowAdder;
++import org.apache.cassandra.db.ColumnFamily;
++import org.apache.cassandra.db.Mutation;
+import org.apache.cassandra.locator.SimpleStrategy;
++import org.apache.cassandra.utils.FBUtilities;
++import org.apache.cassandra.utils.UUIDGen;
+
+public final class TraceKeyspace
+{
+public static final String NAME = "system_traces";
+
- static final String SESSIONS_TABLE = "sessions";
- static final String EVENTS_TABLE = "events";
++private static final String SESSIONS_TABLE = "sessions";
++private static final String EVENTS_TABLE = "events";
+
+private static final int DAY = (int) TimeUnit.DAYS.toSeconds(1);
+
- static final CFMetaData SessionsTable =
++private static final CFMetaData SessionsTable =
+compile(SESSIONS_TABLE, "tracing sessions",
+"CREATE TABLE %s ("
++ "session_id uuid,"
++ "coordinator inet,"
++ "duration int,"
++ "parameters map,"
++ "request text,"
++ "started_at timestamp,"
++ "PRIMARY KEY ((session_id)))")
+.defaultTimeToLive(DAY);
+
- static final CFMetaData EventsTable =
++private static final CFMetaData EventsTable =
+compile(EVENTS_TABLE, "tracing events",
+"CREATE TABLE %s ("
++ "session_id uuid,"
++ "event_id timeuuid,"
++ "activity text,"
++ "source inet,"
++ "source_elapsed int,"
++ "thread text,"
++ "PRIMARY KEY ((session_id), event_id))")
+.defaultTimeToLive(DAY);
+
+private static CFMetaData compile(String table, String comment, String
cql)
+{
+return CFMetaData.compile(String.format(cql, table),
NAME).comment(comment);
+}
+
+public static KSMetaData definition()
[jira] [Assigned] (CASSANDRA-8265) Disable SSLv3 for POODLE
[ https://issues.apache.org/jira/browse/CASSANDRA-8265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremiah Jordan reassigned CASSANDRA-8265: -- Assignee: Jeremiah Jordan > Disable SSLv3 for POODLE > > > Key: CASSANDRA-8265 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8265 > Project: Cassandra > Issue Type: Bug >Reporter: Jeremiah Jordan >Assignee: Jeremiah Jordan > > We should probably disable SSLv3. > http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8193) Multi-DC parallel snapshot repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208773#comment-14208773 ] Jimmy Mårdell commented on CASSANDRA-8193: -- I think it's more of a performance improvement rather than a new feature. I could do the fallback, but why is it necessary? Is it a common use case to have RF=1 in a multi-DC setup and do for instance quorum queries across datacenters? It will be a bit more messy. The reason ParallelRequestCoordinator is more generic an implements IRequestCoordinator is because that's how the old RequestCoordinator was written. I did't really see why it was generic in the first place, but I kept it. I could remove the generics entirely and use InetAddress always (there are no other usages of it). Ah right, the call to completed will always be synchronized from addTree. Missed that, thanks. > Multi-DC parallel snapshot repair > - > > Key: CASSANDRA-8193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8193 > Project: Cassandra > Issue Type: Improvement >Reporter: Jimmy Mårdell >Assignee: Jimmy Mårdell >Priority: Minor > Fix For: 2.0.12 > > Attachments: cassandra-2.0-8193-1.txt > > > The current behaviour of snapshot repair is to let one node at a time > calculate a merkle tree. This is to ensure only one node at a time is doing > the expensive calculation. The drawback is that it takes even longer time to > do the merkle tree calculation. > In a multi-DC setup, I think it would make more sense to have one node in > each DC calculate the merkle tree at the same time. This would yield a > significant improvement when you have many data centers. > I'm not sure how relevant this is in 2.1, but I don't see us upgrading to 2.1 > any time soon. Unless there is an obvious drawback that I'm missing, I'd like > to implement this in the 2.0 branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v7.txt
Attached v7 (merge with trunk + merge conflicts resolved, no other changes)
> Decide how to deal with conflict between native and user-defined functions
> --
>
> Key: CASSANDRA-7813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Robert Stupp
> Labels: cql
> Fix For: 3.0
>
> Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt,
> 7813v5.txt, 7813v6.txt, 7813v7.txt
>
>
> We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
> 3.0, user will be able to define new functions. Now, there is a very high
> change that we will provide more native functions over-time (to be clear, I'm
> not particularly for adding native functions for allthethings just because we
> can, but it's clear that we should ultimately provide more than what we
> have). Which begs the question: how do we want to deal with the problem of
> adding a native function potentially breaking a previously defined
> user-defined function?
> A priori I see the following options (maybe there is more?):
> # don't do anything specific, hoping that it won't happen often and consider
> it a user problem if it does.
> # reserve a big number of names that we're hoping will cover all future need.
> # make native function and user-defined function syntactically distinct so it
> cannot happen.
> I'm not a huge fan of solution 1). Solution 2) is actually what we did for
> UDT but I think it's somewhat less practical here: there is so much types
> that it makes sense to provide natively and so it wasn't too hard to come up
> with a reasonably small list of types name to reserve just in case. This
> feels a lot harder for functions to me.
> Which leaves solution 3). Since we already have the concept of namespaces for
> functions, a simple idea would be to force user function to have namespace.
> We could even allow that namespace to be empty as long as we force the
> namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
> functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8303) Provide "strict mode" for CQL Queries
[ https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208759#comment-14208759 ] Anupam Arora commented on CASSANDRA-8303: - Agreed. Kind of hard to define expensive as it will vary with each use case. Our problem is that we have a shared infrastructure that runs multiple applications. We have had our L3 & developer folks "accidentally" run queries, while doing production triage, that had ALLOWS FILTERING, and multi-partition queries with "IN". This has caused production issues because we see a large spike in CPU on our servers and that starts to impacts every process hitting that server. The challenge is that Cassandra allows such queries, so my request is to create a "strict mode" that will make Cassandra reject such queries. Hadoop Hive provides a similar mode that disallows certain types of queries. > Provide "strict mode" for CQL Queries > - > > Key: CASSANDRA-8303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8303 > Project: Cassandra > Issue Type: Improvement >Reporter: Anupam Arora > > Please provide a "strict mode" option in cassandra that will kick out any CQL > queries that are expensive, e.g. any query with ALLOWS FILTERING, > multi-partition queries, secondary index queries, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8303) Provide "strict mode" for CQL Queries
[ https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208743#comment-14208743 ] Michael Shuler commented on CASSANDRA-8303: --- "Expensive" is subjective and relative. It's an interesting idea, but I'm not sure how judgement is passed. > Provide "strict mode" for CQL Queries > - > > Key: CASSANDRA-8303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8303 > Project: Cassandra > Issue Type: Improvement >Reporter: Anupam Arora > > Please provide a "strict mode" option in cassandra that will kick out any CQL > queries that are expensive, e.g. any query with ALLOWS FILTERING, > multi-partition queries, secondary index queries, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/2] cassandra git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt src/java/org/apache/cassandra/tracing/Tracing.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/26ea0f6d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/26ea0f6d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/26ea0f6d Branch: refs/heads/cassandra-2.1 Commit: 26ea0f6d7442760d1aeb57ce0b8ab6f86c3190a8 Parents: deff175 be79142 Author: Aleksey Yeschenko Authored: Thu Nov 13 00:34:14 2014 +0300 Committer: Aleksey Yeschenko Committed: Thu Nov 13 00:34:14 2014 +0300 -- CHANGES.txt | 2 + .../org/apache/cassandra/config/CFMetaData.java | 4 +- .../apache/cassandra/tracing/TraceState.java| 20 ++--- .../org/apache/cassandra/tracing/Tracing.java | 80 +--- 4 files changed, 36 insertions(+), 70 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/26ea0f6d/CHANGES.txt -- diff --cc CHANGES.txt index 5b63f48,47e611c..51a3ed0 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,40 -1,11 +1,42 @@@ -2.0.12: +2.1.3 + * Support for frozen collections (CASSANDRA-7859) + * Fix overflow on histogram computation (CASSANDRA-8028) + * Have paxos reuse the timestamp generation of normal queries (CASSANDRA-7801) +Merged from 2.0: + * Fix millisecond timestamps in Tracing (CASSANDRA-8297) * Include keyspace name in error message when there are insufficient live nodes to stream from (CASSANDRA-8221) * Avoid overlap in L1 when L0 contains many nonoverlapping sstables (CASSANDRA-8211) * Improve PropertyFileSnitch logging (CASSANDRA-8183) - * Abort liveRatio calculation if the memtable is flushed (CASSANDRA-8164) + ++ +2.1.2 + * (cqlsh) parse_for_table_meta errors out on queries with undefined + grammars (CASSANDRA-8262) + * (cqlsh) Fix SELECT ... TOKEN() function broken in C* 2.1.1 (CASSANDRA-8258) + * Fix Cassandra crash when running on JDK8 update 40 (CASSANDRA-8209) + * Optimize partitioner tokens (CASSANDRA-8230) + * Improve compaction of repaired/unrepaired sstables (CASSANDRA-8004) + * Make cache serializers pluggable (CASSANDRA-8096) + * Fix issues with CONTAINS (KEY) queries on secondary indexes + (CASSANDRA-8147) + * Fix read-rate tracking of sstables for some queries (CASSANDRA-8239) + * Fix default timestamp in QueryOptions (CASSANDRA-8246) + * Set socket timeout when reading remote version (CASSANDRA-8188) + * Refactor how we track live size (CASSANDRA-7852) + * Make sure unfinished compaction files are removed (CASSANDRA-8124) + * Fix shutdown when run as Windows service (CASSANDRA-8136) + * Fix DESCRIBE TABLE with custom indexes (CASSANDRA-8031) + * Fix race in RecoveryManagerTest (CASSANDRA-8176) + * Avoid IllegalArgumentException while sorting sstables in + IndexSummaryManager (CASSANDRA-8182) + * Shutdown JVM on file descriptor exhaustion (CASSANDRA-7579) + * Add 'die' policy for commit log and disk failure (CASSANDRA-7927) + * Fix installing as service on Windows (CASSANDRA-8115) + * Fix CREATE TABLE for CQL2 (CASSANDRA-8144) + * Avoid boxing in ColumnStats min/max trackers (CASSANDRA-8109) +Merged from 2.0: * Correctly handle non-text column names in cql3 (CASSANDRA-8178) * Fix deletion for indexes on primary key columns (CASSANDRA-8206) * Add 'nodetool statusgossip' (CASSANDRA-8125) http://git-wip-us.apache.org/repos/asf/cassandra/blob/26ea0f6d/src/java/org/apache/cassandra/config/CFMetaData.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/26ea0f6d/src/java/org/apache/cassandra/tracing/TraceState.java -- diff --cc src/java/org/apache/cassandra/tracing/TraceState.java index cfff295,5fec633..399b6e9 --- a/src/java/org/apache/cassandra/tracing/TraceState.java +++ b/src/java/org/apache/cassandra/tracing/TraceState.java @@@ -29,9 -28,9 +29,9 @@@ import org.slf4j.helpers.MessageFormatt import org.apache.cassandra.concurrent.Stage; import org.apache.cassandra.concurrent.StageManager; import org.apache.cassandra.config.CFMetaData; - import org.apache.cassandra.db.ArrayBackedSortedColumns; ++import org.apache.cassandra.db.CFRowAdder; import org.apache.cassandra.db.ColumnFamily; -import org.apache.cassandra.db.RowMutation; -import org.apache.cassandra.db.TreeMapBackedSortedColumns; +import org.apache.cassandra.db.Mutation; import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.cassandra.utils.FBUtilities; import org.apache.cassandra.utils.UUIDGen; @@@ -91,21 -87,21 +91,23 @@@ public class TraceStat public s
[1/2] cassandra git commit: Fix millisecond timestamps in Tracing
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 deff175a4 -> 26ea0f6d7
Fix millisecond timestamps in Tracing
patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe for
CASSANDRA-8297
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/be791422
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/be791422
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/be791422
Branch: refs/heads/cassandra-2.1
Commit: be791422972a2ee485239e3d724ffcab3d8fdace
Parents: a6802aa
Author: Aleksey Yeschenko
Authored: Wed Nov 12 23:44:00 2014 +0300
Committer: Aleksey Yeschenko
Committed: Wed Nov 12 23:46:53 2014 +0300
--
CHANGES.txt | 1 +
.../org/apache/cassandra/config/CFMetaData.java | 4 ++--
.../org/apache/cassandra/tracing/Tracing.java | 21 +---
3 files changed, 8 insertions(+), 18 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 842643c..47e611c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Fix millisecond timestamps in Tracing (CASSANDRA-8297)
* Include keyspace name in error message when there are insufficient
live nodes to stream from (CASSANDRA-8221)
* Avoid overlap in L1 when L0 contains many nonoverlapping
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 391341f..9d69710 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -217,7 +217,7 @@ public final class CFMetaData
+ "started_at
timestamp,"
+ "parameters
map,"
+ "duration int"
- + ") WITH
COMMENT='traced sessions'",
+ + ") WITH
COMMENT='traced sessions' AND default_time_to_live=86400",
Tracing.TRACE_KS);
public static final CFMetaData TraceEventsCf = compile("CREATE TABLE " +
Tracing.EVENTS_CF + " ("
@@ -228,7 +228,7 @@ public final class CFMetaData
+ "activity text,"
+ "source_elapsed
int,"
+ "PRIMARY KEY
(session_id, event_id)"
- + ")",
+ + ") WITH
default_time_to_live=86400",
Tracing.TRACE_KS);
public static final CFMetaData BatchlogCf = compile("CREATE TABLE " +
SystemKeyspace.BATCHLOG_CF + " ("
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/src/java/org/apache/cassandra/tracing/Tracing.java
--
diff --git a/src/java/org/apache/cassandra/tracing/Tracing.java
b/src/java/org/apache/cassandra/tracing/Tracing.java
index 88239be..b38dc10 100644
--- a/src/java/org/apache/cassandra/tracing/Tracing.java
+++ b/src/java/org/apache/cassandra/tracing/Tracing.java
@@ -59,15 +59,13 @@ public class Tracing
public static final String SESSIONS_CF = "sessions";
public static final String TRACE_HEADER = "TraceSession";
-private static final int TTL = 24 * 3600;
-
private static final Logger logger =
LoggerFactory.getLogger(Tracing.class);
private final InetAddress localAddress = FBUtilities.getLocalAddress();
-private final ThreadLocal state = new
ThreadLocal();
+private final ThreadLocal state = new ThreadLocal<>();
-private final ConcurrentMap sessions = new
ConcurrentHashMap();
+private final ConcurrentMap sessions = new
ConcurrentHashMap<>();
public static final Tracing instance = new Tracing();
@@ -93,16 +91,7 @@ public class Tracing
private static void addColumn(ColumnFamily cf, ByteBuffer name, ByteBuffer
value)
{
-cf.addColumn(new ExpiringColumn(name, value,
System.currentTimeMillis(), TTL));
-}
-
-public void addParameterColumns(ColumnFamily cf, Map
rawPayload)
-{
-for (Map.Entry entry : rawPayload.entrySet())
-
[jira] [Created] (CASSANDRA-8303) Provide "strict mode" for CQL Queries
Anupam Arora created CASSANDRA-8303: --- Summary: Provide "strict mode" for CQL Queries Key: CASSANDRA-8303 URL: https://issues.apache.org/jira/browse/CASSANDRA-8303 Project: Cassandra Issue Type: Improvement Reporter: Anupam Arora Please provide a "strict mode" option in cassandra that will kick out any CQL queries that are expensive, e.g. any query with ALLOWS FILTERING, multi-partition queries, secondary index queries, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Fix millisecond timestamps in Tracing
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 a6802aa47 -> be7914229
Fix millisecond timestamps in Tracing
patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe for
CASSANDRA-8297
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/be791422
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/be791422
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/be791422
Branch: refs/heads/cassandra-2.0
Commit: be791422972a2ee485239e3d724ffcab3d8fdace
Parents: a6802aa
Author: Aleksey Yeschenko
Authored: Wed Nov 12 23:44:00 2014 +0300
Committer: Aleksey Yeschenko
Committed: Wed Nov 12 23:46:53 2014 +0300
--
CHANGES.txt | 1 +
.../org/apache/cassandra/config/CFMetaData.java | 4 ++--
.../org/apache/cassandra/tracing/Tracing.java | 21 +---
3 files changed, 8 insertions(+), 18 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 842643c..47e611c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.12:
+ * Fix millisecond timestamps in Tracing (CASSANDRA-8297)
* Include keyspace name in error message when there are insufficient
live nodes to stream from (CASSANDRA-8221)
* Avoid overlap in L1 when L0 contains many nonoverlapping
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 391341f..9d69710 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -217,7 +217,7 @@ public final class CFMetaData
+ "started_at
timestamp,"
+ "parameters
map,"
+ "duration int"
- + ") WITH
COMMENT='traced sessions'",
+ + ") WITH
COMMENT='traced sessions' AND default_time_to_live=86400",
Tracing.TRACE_KS);
public static final CFMetaData TraceEventsCf = compile("CREATE TABLE " +
Tracing.EVENTS_CF + " ("
@@ -228,7 +228,7 @@ public final class CFMetaData
+ "activity text,"
+ "source_elapsed
int,"
+ "PRIMARY KEY
(session_id, event_id)"
- + ")",
+ + ") WITH
default_time_to_live=86400",
Tracing.TRACE_KS);
public static final CFMetaData BatchlogCf = compile("CREATE TABLE " +
SystemKeyspace.BATCHLOG_CF + " ("
http://git-wip-us.apache.org/repos/asf/cassandra/blob/be791422/src/java/org/apache/cassandra/tracing/Tracing.java
--
diff --git a/src/java/org/apache/cassandra/tracing/Tracing.java
b/src/java/org/apache/cassandra/tracing/Tracing.java
index 88239be..b38dc10 100644
--- a/src/java/org/apache/cassandra/tracing/Tracing.java
+++ b/src/java/org/apache/cassandra/tracing/Tracing.java
@@ -59,15 +59,13 @@ public class Tracing
public static final String SESSIONS_CF = "sessions";
public static final String TRACE_HEADER = "TraceSession";
-private static final int TTL = 24 * 3600;
-
private static final Logger logger =
LoggerFactory.getLogger(Tracing.class);
private final InetAddress localAddress = FBUtilities.getLocalAddress();
-private final ThreadLocal state = new
ThreadLocal();
+private final ThreadLocal state = new ThreadLocal<>();
-private final ConcurrentMap sessions = new
ConcurrentHashMap();
+private final ConcurrentMap sessions = new
ConcurrentHashMap<>();
public static final Tracing instance = new Tracing();
@@ -93,16 +91,7 @@ public class Tracing
private static void addColumn(ColumnFamily cf, ByteBuffer name, ByteBuffer
value)
{
-cf.addColumn(new ExpiringColumn(name, value,
System.currentTimeMillis(), TTL));
-}
-
-public void addParameterColumns(ColumnFamily cf, Map
rawPayload)
-{
-for (Map.Entry entry : rawPayload.entrySet())
-
[jira] [Commented] (CASSANDRA-8285) OOME in Cassandra 2.0.11
[
https://issues.apache.org/jira/browse/CASSANDRA-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208642#comment-14208642
]
Russ Hatch commented on CASSANDRA-8285:
---
I used MAT to have a look at the heap contents and try to figure out what's
going on. The heap appears to be dominated by a single MemTable consuming about
97% of heap. The max memtable size is definitely being exceeded. So something
quirky with flushing seems like a good suspect.
Here's the startup message acknowledging the max size (presumably defaulted to
1/4 heap by not being set):
{noformat}
INFO [main] 2014-11-10 17:09:29,348 DatabaseDescriptor.java (line 268) Global
memtable threshold is enabled at 253MB
{noformat}
Due to dropped messages and full gc's StatusLogger was dumping some (maybe)
useful information to the logs that shows some blocked FlushWriter threads --
I'm not sure whether this is routine or not, might be worth reviewing. Here we
see the FlushWriter 'All Time Blocked' threads value spike suddenly, followed
by a large increase in pending compactions (if I'm interpreting the logs
correctly):
{noformat}
ActivePendingCompleted Blocked All
Time Blocked
INFO [ScheduledTasks:1] 2014-11-11 08:21:07,549 StatusLogger.java (line 70)
FlushWriter 0 0 4993 0
1
INFO [ScheduledTasks:1] 2014-11-11 08:21:07,636 StatusLogger.java (line 70)
CompactionExecutor1 6 4639 0
0
INFO [ScheduledTasks:1] 2014-11-11 08:21:07,636 StatusLogger.java (line 79)
CompactionManager 1 8
INFO [ScheduledTasks:1] 2014-11-12 09:57:10,590 StatusLogger.java (line 70)
FlushWriter 0 0111 0
28
INFO [ScheduledTasks:1] 2014-11-12 09:57:10,719 StatusLogger.java (line 70)
CompactionExecutor119 26 0
0
INFO [ScheduledTasks:1] 2014-11-12 09:57:10,720 StatusLogger.java (line 79)
CompactionManager 121
INFO [ScheduledTasks:1] 2014-11-12 09:57:24,648 StatusLogger.java (line 70)
FlushWriter 0 0111 0
28
{noformat}
So it seems basically an unflushed memtable is consuming excessive heap and
causing the constant full GC's and the eventual OOM. Now the question is why is
the memtable not being flushed?
> OOME in Cassandra 2.0.11
>
>
> Key: CASSANDRA-8285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8285
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.11 + java-driver 2.0.8-SNAPSHOT
> Cassandra 2.0.11 + ruby-driver 1.0-beta
>Reporter: Pierre Laporte
>Assignee: Aleksey Yeschenko
> Attachments: OOME_node_system.log, gc.log.gz,
> heap-usage-after-gc-zoom.png, heap-usage-after-gc.png
>
>
> We ran drivers 3-days endurance tests against Cassandra 2.0.11 and C* crashed
> with an OOME. This happened both with ruby-driver 1.0-beta and java-driver
> 2.0.8-snapshot.
> Attached are :
> | OOME_node_system.log | The system.log of one Cassandra node that crashed |
> | gc.log.gz | The GC log on the same node |
> | heap-usage-after-gc.png | The heap occupancy evolution after every GC cycle
> |
> | heap-usage-after-gc-zoom.png | A focus on when things start to go wrong |
> Workload :
> Our test executes 5 CQL statements (select, insert, select, delete, select)
> for a given unique id, during 3 days, using multiple threads. There is not
> change in the workload during the test.
> Symptoms :
> In the attached log, it seems something starts in Cassandra between
> 2014-11-06 10:29:22 and 2014-11-06 10:45:32. This causes an allocation that
> fills the heap. We eventually get stuck in a Full GC storm and get an OOME
> in the logs.
> I have run the java-driver tests against Cassandra 1.2.19 and 2.1.1. The
> error does not occur. It seems specific to 2.0.11.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8299) cassandra-stress unique keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-8299: -- Assignee: Tyler Hobbs > cassandra-stress unique keys > > > Key: CASSANDRA-8299 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8299 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Centos 6.5 Cassandra version 2.1.1 >Reporter: Edgardo Vega >Assignee: Tyler Hobbs > > In the old stress tool you could use -n 1 and get 1 unique keys in > the keyspace. > In the new stress tool there doesn't seem to be a way to do this. For example > if I have the following definition: > table_definition: | > CREATE TABLE table( > key uuid PRIMARY KEY, > col1 text, > col2 text, > col3 text > ) WITH comment='A table' > ### Column Distribution Specifications ### > columnspec: > - name: key > size: fixed(36) > population: uniform(1..100B) > - name: col1 > size: fixed(100) > - name: col2 > size: fixed(100) > - name: col3 > size: fixed(100) > and then run > cassandra-stress user n=1 profile=stress.yaml ops\(insert=1\) > If you look at the keyspace was only 59000 keys. The new tool needs to be > able to generated unique ids. In our tested we want to see how the number of > keys effects the cluster when doing queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8298) cassandra-stress legacy
[ https://issues.apache.org/jira/browse/CASSANDRA-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-8298: -- Assignee: Tyler Hobbs > cassandra-stress legacy > > > Key: CASSANDRA-8298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8298 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Centos 6.5 Cassandra 2.1.1 >Reporter: Edgardo Vega >Assignee: Tyler Hobbs > > Running cassandra-stress legacy failed immediately with a error. > Running in legacy support mode. Translating command to: > stress write n=100 -col n=fixed(5) size=fixed(34) data=repeat(1) -rate > threads=50 -log interval=10 -mode thrift > Invalid parameter data=repeat(1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8296) Can't add new node to a Cluster due to invalid gossip generation
[
https://issues.apache.org/jira/browse/CASSANDRA-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208596#comment-14208596
]
Brandon Williams commented on CASSANDRA-8296:
-
What is odd to me here is the local gen of 3... I can't imagine a scenario
where that's possible. Generations are either set to zero when loading saved
states, or the node will set it to the current time at startup, so 3 shouldn't
happen.
> Can't add new node to a Cluster due to invalid gossip generation
>
>
> Key: CASSANDRA-8296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8296
> Project: Cassandra
> Issue Type: Bug
> Environment: Debian Wheezy
> Cassandra 2.1.1
>Reporter: Rafał Furmański
>Assignee: Jason Brown
>
> Hi all! I'm unable to add new node to an existing Cassandra cluster. I'm
> using GossipingPropertyFileSnitch and after starting cassandra I get
> following errors on other nodes:
> {code}
> WARN [GossipStage:2] 2014-11-12 09:38:43,297 Gossiper.java:993 - received an
> invalid gossip generation for peer /10.210.3.230; local generation = 3,
> received generation = 1415785003
> {code}
> New node's IP is 10.210.3.230. I can't see this IP in {code}nodetool
> status{code}
> Any ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8302) Filtering for CONTAINS (KEY) on frozen collection clustering columns within a partition does not work
Tyler Hobbs created CASSANDRA-8302:
--
Summary: Filtering for CONTAINS (KEY) on frozen collection
clustering columns within a partition does not work
Key: CASSANDRA-8302
URL: https://issues.apache.org/jira/browse/CASSANDRA-8302
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Fix For: 2.1.3
Create a table like this:
{noformat}
CREATE TABLE foo (
a int,
b int,
c frozen>
d int,
PRIMARY KEY (a, b, c, d)
)
{noformat}
and add an index on it:
{noformat}
CREATE INDEX ON foo(b)
{noformat}
A query across all partitions will work correctly:
{noformat}
cqlsh:ks1> insert into foo (a, b, c, d) VALUES (0, 0, {1, 2}, 0);
cqlsh:ks1> SELECT * FROM foo WHERE b=0 AND c CONTAINS 2 and d=0 ALLOW FILTERING;
a | b | c | d
---+---++---
0 | 0 | {1, 2} | 0
(1 rows)
{noformat}
But if the query is restricted to a single partition, it is considered invalid
(and the error message isn't great):
{noformat}
cqlsh:ks1> SELECT * FROM foo WHERE a=0 AND b=0 AND c CONTAINS 2 and d=0 ALLOW
FILTERING;
code=2200 [Invalid query] message="No secondary indexes on the restricted
columns support the provided operators: "
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8296) Can't add new node to a Cluster due to invalid gossip generation
[
https://issues.apache.org/jira/browse/CASSANDRA-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208540#comment-14208540
]
Jason Brown commented on CASSANDRA-8296:
Also, do you get the same message (with the same "local generation" value) on
the other nodes?
> Can't add new node to a Cluster due to invalid gossip generation
>
>
> Key: CASSANDRA-8296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8296
> Project: Cassandra
> Issue Type: Bug
> Environment: Debian Wheezy
> Cassandra 2.1.1
>Reporter: Rafał Furmański
>Assignee: Jason Brown
>
> Hi all! I'm unable to add new node to an existing Cassandra cluster. I'm
> using GossipingPropertyFileSnitch and after starting cassandra I get
> following errors on other nodes:
> {code}
> WARN [GossipStage:2] 2014-11-12 09:38:43,297 Gossiper.java:993 - received an
> invalid gossip generation for peer /10.210.3.230; local generation = 3,
> received generation = 1415785003
> {code}
> New node's IP is 10.210.3.230. I can't see this IP in {code}nodetool
> status{code}
> Any ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8295) Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
[
https://issues.apache.org/jira/browse/CASSANDRA-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208530#comment-14208530
]
Jonathan Ellis commented on CASSANDRA-8295:
---
All the 1 settings there default to 2000. The write timeout in particular
is what's killing you.
> Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
> -
>
> Key: CASSANDRA-8295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8295
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: DSE 4.5.3 Cassandra 2.0.11.82
>Reporter: Jose Martinez Poblete
> Attachments: alln01-ats-cas3.cassandra.yaml, output.tgz, system.tgz,
> system.tgz.1, system.tgz.2, system.tgz.3
>
>
> Customer runs a 3 node cluster
> Their dataset is less than 1Tb and during data load, one of the nodes enter a
> GC death spiral:
> {noformat}
> INFO [ScheduledTasks:1] 2014-11-07 23:31:08,094 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 3348 ms for 2 collections, 1658268944 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,486 GCInspector.java (line 116)
> GC for ParNew: 442 ms for 2 collections, 6079570032 used; max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,487 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 7351 ms for 2 collections, 6084678280 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:01,836 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 603 ms for 1 collections, 7132546096 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:09,626 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 761 ms for 1 collections, 7286946984 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:15,265 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 703 ms for 1 collections, 7251213520 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:25,027 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 1205 ms for 1 collections, 6507586104 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:41,374 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 13835 ms for 3 collections, 6514187192 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:54,137 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 6834 ms for 2 collections, 6521656200 used; max
> is 8375238656
> ...
> INFO [ScheduledTasks:1] 2014-11-08 12:13:11,086 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 43967 ms for 2 collections, 8368777672 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:14,151 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 63968 ms for 3 collections, 8369623824 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:55,643 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 41307 ms for 2 collections, 8370115376 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:20:06,197 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 309634 ms for 15 collections, 8374994928 used;
> max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 13:07:33,617 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 2681100 ms for 143 collections, 8347631560 used;
> max is 8375238656
> {noformat}
> Their application waits 1 minute before a retry when a timeout is returned
> This is what we find on their heapdumps:
> {noformat}
> Class Name
>
>
>| Shallow Heap
> | Retained Heap | Percentage
> -
> org.apache.cassandra.db.Memtable @ 0x773f52f80
>
>
>| 72
> | 8,086,073,504 | 96.66%
> |- java.util.concurrent.ConcurrentSkipListMap @ 0x724508fe8
>
>
>
[jira] [Created] (CASSANDRA-8301) Create a tool that given a bunch of sstables creates a "decent" sstable leveling
Marcus Eriksson created CASSANDRA-8301: -- Summary: Create a tool that given a bunch of sstables creates a "decent" sstable leveling Key: CASSANDRA-8301 URL: https://issues.apache.org/jira/browse/CASSANDRA-8301 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson In old versions of cassandra (i.e. not trunk/3.0), when bootstrapping a new node, you will end up with a ton of files in L0 and it might be extremely painful to get LCS to compact into a new leveling We could probably exploit the fact that we have many non-overlapping sstables in L0, and offline-bump those sstables into higher levels. It does not need to be perfect, just get the majority of the data into L1+ without creating overlaps. So, suggestion is to create an offline tool that looks at the range each sstable covers and tries to bump it as high as possible in the leveling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8296) Can't add new node to a Cluster due to invalid gossip generation
[
https://issues.apache.org/jira/browse/CASSANDRA-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208523#comment-14208523
]
Jason Brown commented on CASSANDRA-8296:
Can you run {code}nodetool gossipinfo{code} from both the new node a random
existing node, and post the output? Also, how are you bring the new node into
the cluster (what steps do you do)? Just want to rule out anything out of the
ordinary.
FWIW, I just launched a local 3-node cluster (via ccm) on my local linux
install, and then added a fourth node without a problem - the generation of the
new node was within expectations. I used GossipingPropertyFileSnitch, as well.
> Can't add new node to a Cluster due to invalid gossip generation
>
>
> Key: CASSANDRA-8296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8296
> Project: Cassandra
> Issue Type: Bug
> Environment: Debian Wheezy
> Cassandra 2.1.1
>Reporter: Rafał Furmański
>Assignee: Jason Brown
>
> Hi all! I'm unable to add new node to an existing Cassandra cluster. I'm
> using GossipingPropertyFileSnitch and after starting cassandra I get
> following errors on other nodes:
> {code}
> WARN [GossipStage:2] 2014-11-12 09:38:43,297 Gossiper.java:993 - received an
> invalid gossip generation for peer /10.210.3.230; local generation = 3,
> received generation = 1415785003
> {code}
> New node's IP is 10.210.3.230. I can't see this IP in {code}nodetool
> status{code}
> Any ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8285) OOME in Cassandra 2.0.11
[ https://issues.apache.org/jira/browse/CASSANDRA-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-8285: - Assignee: Aleksey Yeschenko (was: Russ Hatch) > OOME in Cassandra 2.0.11 > > > Key: CASSANDRA-8285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8285 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 2.0.11 + java-driver 2.0.8-SNAPSHOT > Cassandra 2.0.11 + ruby-driver 1.0-beta >Reporter: Pierre Laporte >Assignee: Aleksey Yeschenko > Attachments: OOME_node_system.log, gc.log.gz, > heap-usage-after-gc-zoom.png, heap-usage-after-gc.png > > > We ran drivers 3-days endurance tests against Cassandra 2.0.11 and C* crashed > with an OOME. This happened both with ruby-driver 1.0-beta and java-driver > 2.0.8-snapshot. > Attached are : > | OOME_node_system.log | The system.log of one Cassandra node that crashed | > | gc.log.gz | The GC log on the same node | > | heap-usage-after-gc.png | The heap occupancy evolution after every GC cycle > | > | heap-usage-after-gc-zoom.png | A focus on when things start to go wrong | > Workload : > Our test executes 5 CQL statements (select, insert, select, delete, select) > for a given unique id, during 3 days, using multiple threads. There is not > change in the workload during the test. > Symptoms : > In the attached log, it seems something starts in Cassandra between > 2014-11-06 10:29:22 and 2014-11-06 10:45:32. This causes an allocation that > fills the heap. We eventually get stuck in a Full GC storm and get an OOME > in the logs. > I have run the java-driver tests against Cassandra 1.2.19 and 2.1.1. The > error does not occur. It seems specific to 2.0.11. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8297) Milliseconds since epoch used for tracing tables
[ https://issues.apache.org/jira/browse/CASSANDRA-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208511#comment-14208511 ] Sam Tunnicliffe commented on CASSANDRA-8297: +1 > Milliseconds since epoch used for tracing tables > > > Key: CASSANDRA-8297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8297 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 2.0.12, 2.1.3 > > Attachments: 8297.txt > > > Tracing tables seem to be the last place we are still accidentally using > milliseconds for timestamps (vs. microseconds). This should be fixed for > consistency sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8290) archiving commitlogs after restart fails
[
https://issues.apache.org/jira/browse/CASSANDRA-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8290:
---
Attachment: 8290.txt
> archiving commitlogs after restart fails
> -
>
> Key: CASSANDRA-8290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8290
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.11
> Debian wheezy
>Reporter: Manuel Lausch
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Attachments: 8290.txt
>
>
> After update to Cassandra 2.0.11 Cassandra mostly fails during startup while
> archiving commitlogs
> see logfile:
> {noformat}
> RROR [main] 2014-11-03 13:08:59,388 CassandraDaemon.java (line 513) Exception
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:158)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:124)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:336)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:145)
> ... 4 more
> Caused by: java.lang.RuntimeException: java.io.IOException: Exception while
> executing the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Exception while executing the command:
> /bin/ln /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at org.apache.cassandra.utils.FBUtilities.exec(FBUtilities.java:604)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.exec(CommitLogArchiver.java:197)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.access$100(CommitLogArchiver.java:44)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver$1.runMayThrow(CommitLogArchiver.java:132)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ... 5 more
> ERROR [commitlog_archiver:1] 2014-11-03 13:08:59,388 CassandraDaemon.java
> (line 199) Exception in thread Thread[commitlog_archiver:1,5,main]
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at com.google.common.base.Throwables.propagate(Throwables
[jira] [Commented] (CASSANDRA-8290) archiving commitlogs after restart fails
[
https://issues.apache.org/jira/browse/CASSANDRA-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208487#comment-14208487
]
Sam Tunnicliffe commented on CASSANDRA-8290:
The specific problem here is that we pre-emptively archive segments once we
know they're not going to receive any further mutations (i.e. they're full).
However, the segment may not actually be discarded or recycled immediately as
it can still contain mutations for unflushed column families. If the server is
stopped while we're in this state, the original segment file will remain in the
commitlog directory. When the server is restarted, it tries to archive any
pre-existing segment files (CASSANDRA-6904), but in this case the target
already exists, which leads to the reported error.
We could help this somewhat by moving the archival to the point where the
segment is recycled or discarded, shortening the window in which we have
archived, but not active files present (of course, it wouldn't completely close
that window).
However, there's a bigger issue here which is that due to recycling, CL
segments are not really immutable and so hardlinking probably isn't the right
way to archive them. I would modify the command you're using to copy the files
to the archive location instead.
I noticed we use {{ln}} in the example command, so I've attached a patch that
changes that to {{cp}}
> archiving commitlogs after restart fails
> -
>
> Key: CASSANDRA-8290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8290
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.11
> Debian wheezy
>Reporter: Manuel Lausch
>Assignee: Sam Tunnicliffe
>Priority: Minor
>
> After update to Cassandra 2.0.11 Cassandra mostly fails during startup while
> archiving commitlogs
> see logfile:
> {noformat}
> RROR [main] 2014-11-03 13:08:59,388 CassandraDaemon.java (line 513) Exception
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:158)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:124)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:336)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:145)
> ... 4 more
> Caused by: java.lang.RuntimeException: java.io.IOException: Exception while
> executing the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Exception while executing the command:
> /bin/ln /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command ou
[jira] [Assigned] (CASSANDRA-8296) Can't add new node to a Cluster due to invalid gossip generation
[
https://issues.apache.org/jira/browse/CASSANDRA-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Brown reassigned CASSANDRA-8296:
--
Assignee: Jason Brown
> Can't add new node to a Cluster due to invalid gossip generation
>
>
> Key: CASSANDRA-8296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8296
> Project: Cassandra
> Issue Type: Bug
> Environment: Debian Wheezy
> Cassandra 2.1.1
>Reporter: Rafał Furmański
>Assignee: Jason Brown
>
> Hi all! I'm unable to add new node to an existing Cassandra cluster. I'm
> using GossipingPropertyFileSnitch and after starting cassandra I get
> following errors on other nodes:
> {code}
> WARN [GossipStage:2] 2014-11-12 09:38:43,297 Gossiper.java:993 - received an
> invalid gossip generation for peer /10.210.3.230; local generation = 3,
> received generation = 1415785003
> {code}
> New node's IP is 10.210.3.230. I can't see this IP in {code}nodetool
> status{code}
> Any ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8248) Possible memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar reassigned CASSANDRA-8248:
--
Assignee: Shawn Kumar
> Possible memory leak
> -
>
> Key: CASSANDRA-8248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8248
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alexander Sterligov
>Assignee: Shawn Kumar
> Attachments: thread_dump
>
>
> Sometimes during repair cassandra starts to consume more memory than expected.
> Total amount of data on node is about 20GB.
> Size of the data directory is 66GC because of snapshots.
> Top reports:
> {quote}
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 15724 loadbase 20 0 493g 55g 44g S 28 44.2 4043:24 java
> {quote}
> At the /proc/15724/maps there are a lot of deleted file maps
> {quote}
> 7f63a6102000-7f63a6332000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6332000-7f63a6562000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6562000-7f63a6792000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6792000-7f63a69c2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a69c2000-7f63a6bf2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6bf2000-7f63a6e22000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a6e22000-7f63a7052000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7052000-7f63a7282000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7282000-7f63a74b2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a74b2000-7f63a76e2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a76e2000-7f63a7912000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7912000-7f63a7b42000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7b42000-7f63a7d72000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7d72000-7f63a7fa2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a7fa2000-7f63a81d2000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a81d2000-7f63a8402000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a8402000-7f63a8622000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a8622000-7f63a8842000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/iss-feedback_history-tmplink-ka-328671-Index.db
> (deleted)
> 7f63a8842000-7f63a8a62000 r--s 08:21 9442763
> /ssd/cassandra/data/iss/feedback_history-d32bc7e048c011e49b989bc3e8a5a440/
[jira] [Commented] (CASSANDRA-8287) Row Level Isolation is violated by read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208423#comment-14208423 ] sankalp kohli commented on CASSANDRA-8287: -- I agree this is a known limitation. I am fine closing this as "later" if no one could come up with a solution :) > Row Level Isolation is violated by read repair > -- > > Key: CASSANDRA-8287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8287 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: sankalp kohli >Priority: Minor > > In 1.1, row level isolation was added. As per the blog post > http://www.datastax.com/dev/blog/row-level-isolation > "Cassandra guarantees that the changes to login and password are either both > applied or none are." > This is not true with background read repair. Consider this as given in the > blog post. > You run > UPDATE Users > SET login='eric22' AND password='f3g$dq!' > WHERE key='550e8400-e29b-41d4-a716-44665544' > There are 3 machines A,B and C and replication is RF=3 > 1) Machine A did not get this update as it was down and past hint window. > 2) Machine A comes online. > 3) You now only read the password. > 4) password is now read repaired on A. > SO on machine A, password = f3g$dq! and login is still old -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-4476) Support 2ndary index queries with only inequality clauses (LT, LTE, GT, GTE)
[ https://issues.apache.org/jira/browse/CASSANDRA-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-4476: -- Reviewer: Sylvain Lebresne > Support 2ndary index queries with only inequality clauses (LT, LTE, GT, GTE) > > > Key: CASSANDRA-4476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4476 > Project: Cassandra > Issue Type: Improvement > Components: API, Core >Reporter: Sylvain Lebresne >Assignee: Oded Peer >Priority: Minor > Labels: cql > Fix For: 3.0 > > Attachments: cassandra-trunk-4476.patch > > > Currently, a query that uses 2ndary indexes must have at least one EQ clause > (on an indexed column). Given that indexed CFs are local (and use > LocalPartitioner that order the row by the type of the indexed column), we > should extend 2ndary indexes to allow querying indexed columns even when no > EQ clause is provided. > As far as I can tell, the main problem to solve for this is to update > KeysSearcher.highestSelectivityPredicate(). I.e. how do we estimate the > selectivity of non-EQ clauses? I note however that if we can do that estimate > reasonably accurately, this might provide better performance even for index > queries that both EQ and non-EQ clauses, because some non-EQ clauses may have > a much better selectivity than EQ ones (say you index both the user country > and birth date, for SELECT * FROM users WHERE country = 'US' AND birthdate > > 'Jan 2009' AND birtdate < 'July 2009', you'd better use the birthdate index > first). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8122) Undeclare throwable exception while executing 'nodetool netstats localhost'
[
https://issues.apache.org/jira/browse/CASSANDRA-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-8122:
--
Assignee: Carl Yeksigian
> Undeclare throwable exception while executing 'nodetool netstats localhost'
> ---
>
> Key: CASSANDRA-8122
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8122
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra: 2.0.9
>Reporter: Vishal Mehta
>Assignee: Carl Yeksigian
>Priority: Minor
> Attachments: CASSANDRA-8122-1.patch, CASSANDRA-8122-2.1.patch,
> CASSANDRA-8122.patch
>
>
> *Steps*
> # Stop cassandra service
> # Check netstats of nodetool using 'nodetool netstats localhost'
> # Start cassandra service
> # Again check netstats of nodetool using 'nodetool netstats localhost'
> *Expected output*
> Mode: STARTING
> Not sending any streams. (End of output - no further exceptions)
> *Observed output*
> {noformat}
> nodetool netstats localhost
> Mode: STARTING
> Not sending any streams.
> Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
> at com.sun.proxy.$Proxy6.getReadRepairAttempted(Unknown Source)
> at
> org.apache.cassandra.tools.NodeProbe.getReadRepairAttempted(NodeProbe.java:897)
> at
> org.apache.cassandra.tools.NodeCmd.printNetworkStats(NodeCmd.java:726)
> at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:1281)
> Caused by: javax.management.InstanceNotFoundException:
> org.apache.cassandra.db:type=StorageProxy
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1464)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at
> javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:657)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160)
> at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
> at
> javax.management.remote.rmi.RMIConnectionImpl_Stub.getAttribute(Unknown
> Source)
> at
> javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getAttribute(RMIConnector.java:902)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:267)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[ https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-7386: -- Assignee: Robert Stupp (was: Alan Boudreault) > JBOD threshold to prevent unbalanced disk utilization > - > > Key: CASSANDRA-7386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7386 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Assignee: Robert Stupp >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, > mean-writevalue-7disks.png, patch_2_1_branch_proto.diff, > sstable-count-second-run.png > > > Currently the pick the disks are picked first by number of current tasks, > then by free space. This helps with performance but can lead to large > differences in utilization in some (unlikely but possible) scenarios. Ive > seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and > STCS (although my suspicion is that STCS makes it worse since harder to be > balanced). > I purpose the algorithm change a little to have some maximum range of > utilization where it will pick by free space over load (acknowledging it can > be slower). So if a disk A is 30% full and disk B is 5% full it will never > pick A over B until it balances out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[ https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208344#comment-14208344 ] Jonathan Ellis commented on CASSANDRA-7386: --- We have three related problems. One is that the existing design is bad at balancing space used (and as posted initially, I'm okay with this to a degree), a more serious one is that post-CASSANDRA-5605 we can actually run out of space because of this, and finally space-used is actually the wrong thing to optimize for balancing. Starting with the last: ultimately, we want to optimize for balanced reads across the disks with enough space. We shouldn't include writes in the metrics because writes are transient. But trying to balance based on target disk readMeter is probably no more useful than disk space; we would need to take hotness of the source sstables into consideration as well, and compact cold sstables to disks with high activity and hot ones to disks with low activity. This is outside the scope of this ticket. So, if balancing by disk space is the best we can do, here is an optimal approach: # Compute the total free disk space T as the sum of each disk's free space D # For each disk, assign it D/T of the new sstables. (Weighted random may be easiest.) To ensure we never accidentally assign an sstable to a disk that doesn't have room for it, we should also estimate space to be used and restrict our candidates to disks that have room for it. Basically, revert CASSANDRA-5605. But, we don't want to go back to the bad old days of being too pessimistic. So our fallback is, if no disk has space for worst-case estimate, pick the disk with the most free space. > JBOD threshold to prevent unbalanced disk utilization > - > > Key: CASSANDRA-7386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7386 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Assignee: Alan Boudreault >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, > mean-writevalue-7disks.png, patch_2_1_branch_proto.diff, > sstable-count-second-run.png > > > Currently the pick the disks are picked first by number of current tasks, > then by free space. This helps with performance but can lead to large > differences in utilization in some (unlikely but possible) scenarios. Ive > seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and > STCS (although my suspicion is that STCS makes it worse since harder to be > balanced). > I purpose the algorithm change a little to have some maximum range of > utilization where it will pick by free space over load (acknowledging it can > be slower). So if a disk A is 30% full and disk B is 5% full it will never > pick A over B until it balances out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/2] cassandra git commit: Fix regression in HadoopCompat from CASSANDRA-7579
Repository: cassandra
Updated Branches:
refs/heads/trunk 611d1baec -> cf94e3c31
Fix regression in HadoopCompat from CASSANDRA-7579
Patch by jmckenzie; reviewed by bwilliams for CASSANDRA-8292
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/deff175a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/deff175a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/deff175a
Branch: refs/heads/trunk
Commit: deff175a4e8f65fc6e09dc96e07a4d3fd16d8090
Parents: c80d2d3
Author: Joshua McKenzie
Authored: Wed Nov 12 11:45:46 2014 -0600
Committer: Joshua McKenzie
Committed: Wed Nov 12 11:45:46 2014 -0600
--
src/java/org/apache/cassandra/hadoop/HadoopCompat.java | 2 --
1 file changed, 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/deff175a/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
b/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
index bfc4ff6..f2f7033 100644
--- a/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
+++ b/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
@@ -36,7 +36,6 @@ import org.apache.hadoop.mapreduce.StatusReporter;
import org.apache.hadoop.mapreduce.TaskAttemptContext;
import org.apache.hadoop.mapreduce.TaskAttemptID;
import org.apache.hadoop.mapreduce.TaskInputOutputContext;
-import org.apache.cassandra.utils.JVMStabilityInspector;
/*
* This is based on ContextFactory.java from hadoop-2.0.x sources.
@@ -132,7 +131,6 @@ public class HadoopCompat {
get_counter = Class.forName(PACKAGE +
".TaskAttemptContext").getMethod("getCounter", String.class,
String.class);
} catch (Exception e) {
-JVMStabilityInspector.inspectThrowable(e);
get_counter = Class.forName(PACKAGE +
".TaskInputOutputContext").getMethod("getCounter",
String.class, String.class);
}
[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/cf94e3c3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cf94e3c3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cf94e3c3 Branch: refs/heads/trunk Commit: cf94e3c318c98c7f5fa5bfdc03b8c86d1bc464b2 Parents: 611d1ba deff175 Author: Joshua McKenzie Authored: Wed Nov 12 11:48:45 2014 -0600 Committer: Joshua McKenzie Committed: Wed Nov 12 11:48:45 2014 -0600 -- src/java/org/apache/cassandra/hadoop/HadoopCompat.java | 2 -- 1 file changed, 2 deletions(-) --
cassandra git commit: Fix regression in HadoopCompat from CASSANDRA-7579
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 c80d2d3a4 -> deff175a4
Fix regression in HadoopCompat from CASSANDRA-7579
Patch by jmckenzie; reviewed by bwilliams for CASSANDRA-8292
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/deff175a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/deff175a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/deff175a
Branch: refs/heads/cassandra-2.1
Commit: deff175a4e8f65fc6e09dc96e07a4d3fd16d8090
Parents: c80d2d3
Author: Joshua McKenzie
Authored: Wed Nov 12 11:45:46 2014 -0600
Committer: Joshua McKenzie
Committed: Wed Nov 12 11:45:46 2014 -0600
--
src/java/org/apache/cassandra/hadoop/HadoopCompat.java | 2 --
1 file changed, 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/deff175a/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
--
diff --git a/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
b/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
index bfc4ff6..f2f7033 100644
--- a/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
+++ b/src/java/org/apache/cassandra/hadoop/HadoopCompat.java
@@ -36,7 +36,6 @@ import org.apache.hadoop.mapreduce.StatusReporter;
import org.apache.hadoop.mapreduce.TaskAttemptContext;
import org.apache.hadoop.mapreduce.TaskAttemptID;
import org.apache.hadoop.mapreduce.TaskInputOutputContext;
-import org.apache.cassandra.utils.JVMStabilityInspector;
/*
* This is based on ContextFactory.java from hadoop-2.0.x sources.
@@ -132,7 +131,6 @@ public class HadoopCompat {
get_counter = Class.forName(PACKAGE +
".TaskAttemptContext").getMethod("getCounter", String.class,
String.class);
} catch (Exception e) {
-JVMStabilityInspector.inspectThrowable(e);
get_counter = Class.forName(PACKAGE +
".TaskInputOutputContext").getMethod("getCounter",
String.class, String.class);
}
[jira] [Created] (CASSANDRA-8300) cassandra-stress insert documentation
Edgardo Vega created CASSANDRA-8300: --- Summary: cassandra-stress insert documentation Key: CASSANDRA-8300 URL: https://issues.apache.org/jira/browse/CASSANDRA-8300 Project: Cassandra Issue Type: Improvement Components: Tools Environment: Centos 6.5 Cassandra 2.1.1 Reporter: Edgardo Vega The help documentation for the would benefit greatly from some additional documentation. It would be very nice to have some example on how to do some common operations such as I would like inserts to be done in batches of 1000. It would also be nice to have some practical uses of the options and how they effect each other. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8298) cassandra-stress legacy
[ https://issues.apache.org/jira/browse/CASSANDRA-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edgardo Vega updated CASSANDRA-8298: Environment: Centos 6.5 Cassandra 2.1.1 (was: Centos 6.5) Fix Version/s: (was: 2.1.1) > cassandra-stress legacy > > > Key: CASSANDRA-8298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8298 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Centos 6.5 Cassandra 2.1.1 >Reporter: Edgardo Vega > > Running cassandra-stress legacy failed immediately with a error. > Running in legacy support mode. Translating command to: > stress write n=100 -col n=fixed(5) size=fixed(34) data=repeat(1) -rate > threads=50 -log interval=10 -mode thrift > Invalid parameter data=repeat(1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8299) cassandra-stress unique keys
Edgardo Vega created CASSANDRA-8299: --- Summary: cassandra-stress unique keys Key: CASSANDRA-8299 URL: https://issues.apache.org/jira/browse/CASSANDRA-8299 Project: Cassandra Issue Type: Bug Components: Tools Environment: Centos 6.5 Cassandra version 2.1.1 Reporter: Edgardo Vega In the old stress tool you could use -n 1 and get 1 unique keys in the keyspace. In the new stress tool there doesn't seem to be a way to do this. For example if I have the following definition: table_definition: | CREATE TABLE table( key uuid PRIMARY KEY, col1 text, col2 text, col3 text ) WITH comment='A table' ### Column Distribution Specifications ### columnspec: - name: key size: fixed(36) population: uniform(1..100B) - name: col1 size: fixed(100) - name: col2 size: fixed(100) - name: col3 size: fixed(100) and then run cassandra-stress user n=1 profile=stress.yaml ops\(insert=1\) If you look at the keyspace was only 59000 keys. The new tool needs to be able to generated unique ids. In our tested we want to see how the number of keys effects the cluster when doing queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8298) cassandra-stress legacy
Edgardo Vega created CASSANDRA-8298: --- Summary: cassandra-stress legacy Key: CASSANDRA-8298 URL: https://issues.apache.org/jira/browse/CASSANDRA-8298 Project: Cassandra Issue Type: Bug Components: Tools Environment: Centos 6.5 Reporter: Edgardo Vega Fix For: 2.1.1 Running cassandra-stress legacy failed immediately with a error. Running in legacy support mode. Translating command to: stress write n=100 -col n=fixed(5) size=fixed(34) data=repeat(1) -rate threads=50 -log interval=10 -mode thrift Invalid parameter data=repeat(1) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7124) Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
[
https://issues.apache.org/jira/browse/CASSANDRA-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208213#comment-14208213
]
Yuki Morishita commented on CASSANDRA-7124:
---
[~rnamboodiri] You have to change server side operation to asynchronous
operation. Currently CompactionManager#parallelAllSSTableOperation blocks
cleanup/scrub/upgrade to be completed.
So steps are:
1. Make CompactionManager#parallelAllSSTableOperation asynchronous by returning
Future.
2. Add JMX notification to be sent from StorageService
3. Add NodeProbe codes (like you do in the patch) to listen to those
notifications
> Use JMX Notifications to Indicate Success/Failure of Long-Running Operations
>
>
> Key: CASSANDRA-7124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7124
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
> Attachments: cassandra-trunk-temp-7124.txt
>
>
> If {{nodetool cleanup}} or some other long-running operation takes too long
> to complete, you'll see an error like the one in CASSANDRA-2126, so you can't
> tell if the operation completed successfully or not. CASSANDRA-4767 fixed
> this for repairs with JMX notifications. We should do something similar for
> nodetool cleanup, compact, decommission, move, relocate, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8295) Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
[
https://issues.apache.org/jira/browse/CASSANDRA-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208209#comment-14208209
]
Jose Martinez Poblete commented on CASSANDRA-8295:
--
[~jbellis] Looking at the C* yaml file, seems range_request_timeout_in_ms was
changed to 10X
We will set back to 1
{noformat}
read_request_timeout_in_ms: 1
range_request_timeout_in_ms: 10 <<
write_request_timeout_in_ms: 1
cas_contention_timeout_in_ms: 1000
truncate_request_timeout_in_ms: 6
request_timeout_in_ms: 1
{noformat}
> Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
> -
>
> Key: CASSANDRA-8295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8295
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: DSE 4.5.3 Cassandra 2.0.11.82
>Reporter: Jose Martinez Poblete
> Attachments: alln01-ats-cas3.cassandra.yaml, output.tgz, system.tgz,
> system.tgz.1, system.tgz.2, system.tgz.3
>
>
> Customer runs a 3 node cluster
> Their dataset is less than 1Tb and during data load, one of the nodes enter a
> GC death spiral:
> {noformat}
> INFO [ScheduledTasks:1] 2014-11-07 23:31:08,094 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 3348 ms for 2 collections, 1658268944 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,486 GCInspector.java (line 116)
> GC for ParNew: 442 ms for 2 collections, 6079570032 used; max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,487 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 7351 ms for 2 collections, 6084678280 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:01,836 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 603 ms for 1 collections, 7132546096 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:09,626 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 761 ms for 1 collections, 7286946984 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:15,265 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 703 ms for 1 collections, 7251213520 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:25,027 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 1205 ms for 1 collections, 6507586104 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:41,374 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 13835 ms for 3 collections, 6514187192 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:54,137 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 6834 ms for 2 collections, 6521656200 used; max
> is 8375238656
> ...
> INFO [ScheduledTasks:1] 2014-11-08 12:13:11,086 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 43967 ms for 2 collections, 8368777672 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:14,151 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 63968 ms for 3 collections, 8369623824 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:55,643 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 41307 ms for 2 collections, 8370115376 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:20:06,197 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 309634 ms for 15 collections, 8374994928 used;
> max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 13:07:33,617 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 2681100 ms for 143 collections, 8347631560 used;
> max is 8375238656
> {noformat}
> Their application waits 1 minute before a retry when a timeout is returned
> This is what we find on their heapdumps:
> {noformat}
> Class Name
>
>
>| Shallow Heap
> | Retained Heap | Percentage
> -
> org.apache.cassandra.db.Memtable @ 0x773f52f80
>
>
>| 72
> | 8,086
[jira] [Commented] (CASSANDRA-8285) OOME in Cassandra 2.0.11
[
https://issues.apache.org/jira/browse/CASSANDRA-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208169#comment-14208169
]
Pierre Laporte commented on CASSANDRA-8285:
---
[~jbellis] Please find a new gc log, system log and heap dump
[here|https://drive.google.com/a/datastax.com/folderview?id=0BxvGkaXP3ayeNV83Nm1nSUNEcDQ&usp=sharing]
Those 3 files come from the same instance that crashed after a couple of hours.
The heap dump was triggered by {{-XX:+HeapDumpOnOutOfMemoryError}}
Hope that helps
> OOME in Cassandra 2.0.11
>
>
> Key: CASSANDRA-8285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8285
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.11 + java-driver 2.0.8-SNAPSHOT
> Cassandra 2.0.11 + ruby-driver 1.0-beta
>Reporter: Pierre Laporte
>Assignee: Russ Hatch
> Attachments: OOME_node_system.log, gc.log.gz,
> heap-usage-after-gc-zoom.png, heap-usage-after-gc.png
>
>
> We ran drivers 3-days endurance tests against Cassandra 2.0.11 and C* crashed
> with an OOME. This happened both with ruby-driver 1.0-beta and java-driver
> 2.0.8-snapshot.
> Attached are :
> | OOME_node_system.log | The system.log of one Cassandra node that crashed |
> | gc.log.gz | The GC log on the same node |
> | heap-usage-after-gc.png | The heap occupancy evolution after every GC cycle
> |
> | heap-usage-after-gc-zoom.png | A focus on when things start to go wrong |
> Workload :
> Our test executes 5 CQL statements (select, insert, select, delete, select)
> for a given unique id, during 3 days, using multiple threads. There is not
> change in the workload during the test.
> Symptoms :
> In the attached log, it seems something starts in Cassandra between
> 2014-11-06 10:29:22 and 2014-11-06 10:45:32. This causes an allocation that
> fills the heap. We eventually get stuck in a Full GC storm and get an OOME
> in the logs.
> I have run the java-driver tests against Cassandra 1.2.19 and 2.1.1. The
> error does not occur. It seems specific to 2.0.11.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8238) NPE in SizeTieredCompactionStrategy.filterColdSSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208161#comment-14208161
]
Tyler Hobbs commented on CASSANDRA-8238:
Okay, +1 on committing that for now.
> NPE in SizeTieredCompactionStrategy.filterColdSSTables
> --
>
> Key: CASSANDRA-8238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8238
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Marcus Eriksson
> Fix For: 2.1.3
>
> Attachments: 0001-assert-that-readMeter-is-not-null.patch
>
>
> {noformat}
> ERROR [CompactionExecutor:15] 2014-10-31 15:28:32,318
> CassandraDaemon.java:153 - Exception in thread
> Thread[CompactionExecutor:15,1,main]
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.filterColdSSTables(SizeTieredCompactionStrategy.java:181)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:83)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:267)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:226)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_72]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_72]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_72]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_72]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_72]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7949) LCS compaction low performance, many pending compactions, nodes are almost idle
[
https://issues.apache.org/jira/browse/CASSANDRA-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208154#comment-14208154
]
Nikolai Grigoriev commented on CASSANDRA-7949:
--
I had to rebuild one of the nodes in that test cluster. After bootstrapping it
I have checked the results - I had over 6,5K pending compactions and many large
sstables (between few Gb and 40-60Gb). I knew that under traffic this will
*never* return to reasonable number of pending compactions.
I have decided to give it another try, enable the option from CASSANDRA-6621
and re-bootstrap. This time I did not end up with huge sstables but, I think,
it will also never recover. This is, essentially, what the node does most of
the time:
{code}
pending tasks: 7217
compaction typekeyspace table completed
total unit progress
Compaction myks mytable1 5434997373
10667184206 bytes50.95%
Compaction myksmytable2 1080506914
7466286503 bytes14.47%
Active compaction remaining time : 0h00m09s
{code}
while:
{code}
# nodetool cfstats myks.mytable1
Keyspace: myks
Read Count: 49783
Read Latency: 38.612470602414476 ms.
Write Count: 521971
Write Latency: 1.3617571608384373 ms.
Pending Tasks: 0
Table: mytable1
SSTable count: 7893
SSTables in each level: [7828/4, 10, 56, 0, 0, 0, 0, 0, 0]
Space used (live), bytes: 1181508730955
Space used (total), bytes: 1181509085659
SSTable Compression Ratio: 0.3068450302663634
Number of keys (estimate): 28180352
Memtable cell count: 153554
Memtable data size, bytes: 41190431
Memtable switch count: 178
Local read count: 49826
Local read latency: 38.886 ms
Local write count: 522464
Local write latency: 1.392 ms
Pending tasks: 0
Bloom filter false positives: 11802553
Bloom filter false ratio: 0.98767
Bloom filter space used, bytes: 17686928
Compacted partition minimum bytes: 104
Compacted partition maximum bytes: 3379391
Compacted partition mean bytes: 142171
Average live cells per slice (last five minutes): 537.5
Average tombstones per slice (last five minutes): 0.0
{code}
By the way, this is the picture from another node that functions normally:
{code}
# nodetool cfstats myks.mytable1
Keyspace: myks
Read Count: 4638154
Read Latency: 20.784106776316612 ms.
Write Count: 15067667
Write Latency: 1.7291775639188205 ms.
Pending Tasks: 0
Table: mytable1
SSTable count: 4561
SSTables in each level: [37/4, 15/10, 106/100, 1053/1000, 3350,
0, 0, 0, 0]
Space used (live), bytes: 1129716897255
Space used (total), bytes: 1129752918759
SSTable Compression Ratio: 0.33488717551698993
Number of keys (estimate): 25036672
Memtable cell count: 334212
Memtable data size, bytes: 115610737
Memtable switch count: 4476
Local read count: 4638155
Local read latency: 20.784 ms
Local write count: 15067679
Local write latency: 1.729 ms
Pending tasks: 0
Bloom filter false positives: 104377
Bloom filter false ratio: 0.59542
Bloom filter space used, bytes: 20319608
Compacted partition minimum bytes: 104
Compacted partition maximum bytes: 3379391
Compacted partition mean bytes: 152368
Average live cells per slice (last five minutes): 529.5
Average tombstones per slice (last five minutes): 0.0
{code}
So, not only the streaming has created an excessive amount of sstables, the
compactions are not advancing at all. In fact, the number of pending
compactions grows slowly on that (first) node. New L0 sstables get added
because the write activity is taking place.
Just a simple math. If I take the compaction throughput of the node when it
uses only one thread and compare it to my write rate I think the latter is like
4x the former. Under this conditions this node will never recover - while
having plenty of resources and very fast I/O.
> LCS compaction low performance, many pending compactions, nodes are almost
> idle
> ---
>
> Key: CASSANDRA-7949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-79
[jira] [Commented] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[
https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208141#comment-14208141
]
Robert Stupp commented on CASSANDRA-7386:
-
Not really.
It basically calculates the "value" or a drive using {{free-space-precentage
divided by drive-usage-rate}} (rate is basically the current # of read+write
requests)
which is intended to mean that
* drives with more free space have a higher chance to get new sstables
* drives with low access rate have a higher chance to get new sstables
or vice versa
* "hammered" drives are unlikely to get new data
* full drives are unlikely to get new data
> JBOD threshold to prevent unbalanced disk utilization
> -
>
> Key: CASSANDRA-7386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Chris Lohfink
>Assignee: Alan Boudreault
>Priority: Minor
> Fix For: 2.1.3
>
> Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods,
> mean-writevalue-7disks.png, patch_2_1_branch_proto.diff,
> sstable-count-second-run.png
>
>
> Currently the pick the disks are picked first by number of current tasks,
> then by free space. This helps with performance but can lead to large
> differences in utilization in some (unlikely but possible) scenarios. Ive
> seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and
> STCS (although my suspicion is that STCS makes it worse since harder to be
> balanced).
> I purpose the algorithm change a little to have some maximum range of
> utilization where it will pick by free space over load (acknowledging it can
> be slower). So if a disk A is 30% full and disk B is 5% full it will never
> pick A over B until it balances out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[
https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208119#comment-14208119
]
J.B. Langston edited comment on CASSANDRA-7386 at 11/12/14 3:31 PM:
I've seen a lot of users hitting this issue lately, so the sooner we can get a
patch the better. This also needs to be back ported to 2.0 if at all possible.
In several cases I've seen severe imbalances like the ones described where
there are some drives completely full and others at 10-20% utilization.
Here are a couple of stack traces. It happens both during flushes and
compactions.
{code}
ERROR [FlushWriter:6241] 2014-09-07 08:27:35,298 CassandraDaemon.java (line
198) Exception in thread Thread[FlushWriter:6241,5,main]
FSWriteError in
/data6/system/compactions_in_progress/system-compactions_in_progress-tmp-jb-8222-Index.db
at
org.apache.cassandra.io.util.SequentialWriter.flushData(SequentialWriter.java:267)
at
org.apache.cassandra.io.util.SequentialWriter.flushInternal(SequentialWriter.java:219)
at
org.apache.cassandra.io.util.SequentialWriter.syncInternal(SequentialWriter.java:191)
at
org.apache.cassandra.io.util.SequentialWriter.close(SequentialWriter.java:381)
at
org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:481)
at
org.apache.cassandra.io.util.FileUtils.closeQuietly(FileUtils.java:212)
at
org.apache.cassandra.io.sstable.SSTableWriter.abort(SSTableWriter.java:301)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:417)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:350)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.io.IOException: No space left on device
at java.io.RandomAccessFile.writeBytes0(Native Method)
at java.io.RandomAccessFile.writeBytes(RandomAccessFile.java:520)
at java.io.RandomAccessFile.write(RandomAccessFile.java:550)
at
org.apache.cassandra.io.util.SequentialWriter.flushData(SequentialWriter.java:263)
... 13 more
ERROR [CompactionExecutor:9166] 2014-09-06 16:09:14,786 CassandraDaemon.java
(line 198) Exception in thread Thread[CompactionExecutor:9166,1,main]
FSWriteError in /data6/keyspace_1/data/keyspace_1-data-tmp-jb-13599-Filter.db
at
org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:475)
at
org.apache.cassandra.io.util.FileUtils.closeQuietly(FileUtils.java:212)
at
org.apache.cassandra.io.sstable.SSTableWriter.abort(SSTableWriter.java:301)
at
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:209)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
at
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:197)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.io.IOException: No space left on device
at java.io.FileOutputStream.write(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:295)
at java.io.DataOutputStream.writeInt(DataOutputStream.java:197)
at
org.apache.cassandra.utils.BloomFilterSerializer.serialize(BloomFilterSerializer.java:34)
at
org.apache.cassandra.utils.Murmur3BloomFilter$Murmur3BloomFilterSerializer.serialize(Murmur3BloomFilter.java:44)
at
org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:41)
at
org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:468)
... 13 more
{code}
was (Author: jblangs...@datastax.com):
I've seen a lot of users hitting this issue lately, so the sooner we can get a
patch the better. This also needs to be back ported to 2.0 if at all possible.
In several cases
[jira] [Commented] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[ https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208119#comment-14208119 ] J.B. Langston commented on CASSANDRA-7386: -- I've seen a lot of users hitting this issue lately, so the sooner we can get a patch the better. This also needs to be back ported to 2.0 if at all possible. In several cases I've seen severe imbalances like the ones described where there are some drives completely full and others at 10-20% utilization. > JBOD threshold to prevent unbalanced disk utilization > - > > Key: CASSANDRA-7386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7386 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Assignee: Alan Boudreault >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, > mean-writevalue-7disks.png, patch_2_1_branch_proto.diff, > sstable-count-second-run.png > > > Currently the pick the disks are picked first by number of current tasks, > then by free space. This helps with performance but can lead to large > differences in utilization in some (unlikely but possible) scenarios. Ive > seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and > STCS (although my suspicion is that STCS makes it worse since harder to be > balanced). > I purpose the algorithm change a little to have some maximum range of > utilization where it will pick by free space over load (acknowledging it can > be slower). So if a disk A is 30% full and disk B is 5% full it will never > pick A over B until it balances out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7386) JBOD threshold to prevent unbalanced disk utilization
[ https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208104#comment-14208104 ] Jonathan Ellis commented on CASSANDRA-7386: --- bq. The data directory with the highest "write value" is chosen for new sstables. Write value" is calculated using the formula freeRatio / weightedRate That doesn't sound right. So the busier the drive is, the more likely we'll add more sstables to it? We want to put new sstables on un-busy drives so they hopefully become busier. > JBOD threshold to prevent unbalanced disk utilization > - > > Key: CASSANDRA-7386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7386 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink >Assignee: Alan Boudreault >Priority: Minor > Fix For: 2.1.3 > > Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, > mean-writevalue-7disks.png, patch_2_1_branch_proto.diff, > sstable-count-second-run.png > > > Currently the pick the disks are picked first by number of current tasks, > then by free space. This helps with performance but can lead to large > differences in utilization in some (unlikely but possible) scenarios. Ive > seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and > STCS (although my suspicion is that STCS makes it worse since harder to be > balanced). > I purpose the algorithm change a little to have some maximum range of > utilization where it will pick by free space over load (acknowledging it can > be slower). So if a disk A is 30% full and disk B is 5% full it will never > pick A over B until it balances out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8295) Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
[
https://issues.apache.org/jira/browse/CASSANDRA-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208102#comment-14208102
]
Jose Martinez Poblete commented on CASSANDRA-8295:
--
Can't do JBOD right now as per CASSANDRA-7386 but will try RAID0
> Cassandra runs OOM @ java.util.concurrent.ConcurrentSkipListMap$HeadIndex
> -
>
> Key: CASSANDRA-8295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8295
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: DSE 4.5.3 Cassandra 2.0.11.82
>Reporter: Jose Martinez Poblete
> Attachments: alln01-ats-cas3.cassandra.yaml, output.tgz, system.tgz,
> system.tgz.1, system.tgz.2, system.tgz.3
>
>
> Customer runs a 3 node cluster
> Their dataset is less than 1Tb and during data load, one of the nodes enter a
> GC death spiral:
> {noformat}
> INFO [ScheduledTasks:1] 2014-11-07 23:31:08,094 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 3348 ms for 2 collections, 1658268944 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,486 GCInspector.java (line 116)
> GC for ParNew: 442 ms for 2 collections, 6079570032 used; max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:40:58,487 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 7351 ms for 2 collections, 6084678280 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:01,836 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 603 ms for 1 collections, 7132546096 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:09,626 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 761 ms for 1 collections, 7286946984 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:15,265 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 703 ms for 1 collections, 7251213520 used; max is
> 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:25,027 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 1205 ms for 1 collections, 6507586104 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:41,374 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 13835 ms for 3 collections, 6514187192 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-07 23:41:54,137 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 6834 ms for 2 collections, 6521656200 used; max
> is 8375238656
> ...
> INFO [ScheduledTasks:1] 2014-11-08 12:13:11,086 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 43967 ms for 2 collections, 8368777672 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:14,151 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 63968 ms for 3 collections, 8369623824 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:14:55,643 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 41307 ms for 2 collections, 8370115376 used; max
> is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 12:20:06,197 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 309634 ms for 15 collections, 8374994928 used;
> max is 8375238656
> INFO [ScheduledTasks:1] 2014-11-08 13:07:33,617 GCInspector.java (line 116)
> GC for ConcurrentMarkSweep: 2681100 ms for 143 collections, 8347631560 used;
> max is 8375238656
> {noformat}
> Their application waits 1 minute before a retry when a timeout is returned
> This is what we find on their heapdumps:
> {noformat}
> Class Name
>
>
>| Shallow Heap
> | Retained Heap | Percentage
> -
> org.apache.cassandra.db.Memtable @ 0x773f52f80
>
>
>| 72
> | 8,086,073,504 | 96.66%
> |- java.util.concurrent.ConcurrentSkipListMap @ 0x724508fe8
>
>
>
[jira] [Commented] (CASSANDRA-8238) NPE in SizeTieredCompactionStrategy.filterColdSSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208085#comment-14208085
]
Marcus Eriksson commented on CASSANDRA-8238:
[~thobbs] yeah that was my intention. If you agree this is a good idea, I'll
add your text on commit
> NPE in SizeTieredCompactionStrategy.filterColdSSTables
> --
>
> Key: CASSANDRA-8238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8238
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Marcus Eriksson
> Fix For: 2.1.3
>
> Attachments: 0001-assert-that-readMeter-is-not-null.patch
>
>
> {noformat}
> ERROR [CompactionExecutor:15] 2014-10-31 15:28:32,318
> CassandraDaemon.java:153 - Exception in thread
> Thread[CompactionExecutor:15,1,main]
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.filterColdSSTables(SizeTieredCompactionStrategy.java:181)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundSSTables(SizeTieredCompactionStrategy.java:83)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getNextBackgroundTask(SizeTieredCompactionStrategy.java:267)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:226)
> ~[apache-cassandra-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_72]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_72]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_72]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_72]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_72]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8297) Milliseconds since epoch used for tracing tables
[ https://issues.apache.org/jira/browse/CASSANDRA-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8297: - Attachment: 8297.txt > Milliseconds since epoch used for tracing tables > > > Key: CASSANDRA-8297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8297 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 2.0.12, 2.1.3 > > Attachments: 8297.txt > > > Tracing tables seem to be the last place we are still accidentally using > milliseconds for timestamps (vs. microseconds). This should be fixed for > consistency sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8261) Clean up schema metadata classes
[ https://issues.apache.org/jira/browse/CASSANDRA-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207979#comment-14207979 ] Aleksey Yeschenko commented on CASSANDRA-8261: -- Fair enough. I was going to create a separate ticket just for 2.0 and 2.1, but you are right - fixing it in trunk doesn't belong here, either. Pulled it, and create a separate CASSANDRA-8297 ticket. Thanks. Committed. > Clean up schema metadata classes > > > Key: CASSANDRA-8261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8261 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0 > > Attachments: 8261-isolate-hadcoded-system-tables.txt, > 8261-isolate-thrift-code.txt > > > While working on CASSANDRA-6717, I've made some general cleanup changes to > schema metadata classes - distracted from the core purpose. Also, being > distracted from it by other things, every time I come back to it gives me a > bit of a rebase hell. > Thus I'm isolating those changes into a separate issue here, hoping to commit > them one by one, before I go back and finalize CASSANDRA-6717. > The changes include: > - moving all the toThrift/fromThrift conversion code to ThriftConversion, > where it belongs > - moving the complied system CFMetaData objects away from CFMetaData (to > SystemKeyspace and TracesKeyspace) > - isolating legacy toSchema/fromSchema code into a separate class > (LegacySchemaTables - former DefsTables) > - refactoring CFMetaData/KSMetaData fields to match CQL CREATE TABLE syntax, > and encapsulating more things in > CompactionOptions/CompressionOptions/ReplicationOptions classes > - moving the definition classes to the new 'schema' package -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/2] cassandra git commit: Cleanup and move hardcoded system tables away from CFMetaData
Cleanup and move hardcoded system tables away from CFMetaData patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for CASSANDRA-8261 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/611d1bae Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/611d1bae Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/611d1bae Branch: refs/heads/trunk Commit: 611d1baecc448cde9f4e359e639287fed6f8e357 Parents: f096eb6 Author: Aleksey Yeschenko Authored: Wed Nov 12 15:16:15 2014 +0300 Committer: Aleksey Yeschenko Committed: Wed Nov 12 15:16:15 2014 +0300 -- .../apache/cassandra/cache/AutoSavingCache.java | 6 +- .../org/apache/cassandra/config/CFMetaData.java | 240 + .../cassandra/config/ColumnDefinition.java | 10 +- .../cassandra/config/DatabaseDescriptor.java| 14 +- .../org/apache/cassandra/config/KSMetaData.java | 54 +-- .../org/apache/cassandra/config/Schema.java | 25 +- .../cassandra/config/TriggerDefinition.java | 10 +- .../org/apache/cassandra/config/UTMetaData.java | 14 +- .../apache/cassandra/cql3/QueryProcessor.java | 3 +- .../cassandra/cql3/functions/Functions.java | 3 +- .../cassandra/cql3/functions/UDFunction.java| 15 +- .../cql3/statements/AlterKeyspaceStatement.java | 4 +- .../apache/cassandra/db/AtomicBTreeColumns.java | 2 +- .../apache/cassandra/db/BatchlogManager.java| 23 +- .../org/apache/cassandra/db/DefsTables.java | 31 +- .../cassandra/db/HintedHandOffManager.java | 25 +- src/java/org/apache/cassandra/db/Keyspace.java | 11 +- src/java/org/apache/cassandra/db/Memtable.java | 2 +- .../org/apache/cassandra/db/SystemKeyspace.java | 482 ++- .../io/sstable/format/SSTableReader.java| 2 +- .../cassandra/service/CassandraDaemon.java | 4 +- .../apache/cassandra/service/ClientState.java | 11 +- .../cassandra/service/MigrationManager.java | 4 +- .../apache/cassandra/service/StorageProxy.java | 10 +- .../cassandra/service/StorageService.java | 25 +- .../cassandra/thrift/ThriftValidation.java | 2 +- .../org/apache/cassandra/tools/BulkLoader.java | 11 +- .../org/apache/cassandra/tools/NodeTool.java| 6 +- .../apache/cassandra/tracing/TraceKeyspace.java | 73 +++ .../apache/cassandra/tracing/TraceState.java| 4 +- .../org/apache/cassandra/tracing/Tracing.java | 26 +- .../apache/cassandra/config/CFMetaDataTest.java | 4 +- .../cassandra/db/BatchlogManagerTest.java | 4 +- .../apache/cassandra/db/HintedHandOffTest.java | 8 +- .../cassandra/db/RecoveryManager2Test.java | 2 +- .../service/StorageServiceServerTest.java | 3 +- 36 files changed, 599 insertions(+), 574 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/611d1bae/src/java/org/apache/cassandra/cache/AutoSavingCache.java -- diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java b/src/java/org/apache/cassandra/cache/AutoSavingCache.java index 4aeb822..9a79e38 100644 --- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java +++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java @@ -30,12 +30,12 @@ import org.slf4j.LoggerFactory; import org.apache.cassandra.config.CFMetaData; import org.apache.cassandra.config.DatabaseDescriptor; import org.apache.cassandra.config.Schema; +import org.apache.cassandra.db.ColumnFamilyStore; +import org.apache.cassandra.db.SystemKeyspace; import org.apache.cassandra.db.compaction.CompactionInfo; import org.apache.cassandra.db.compaction.CompactionManager; import org.apache.cassandra.db.compaction.OperationType; import org.apache.cassandra.db.marshal.BytesType; -import org.apache.cassandra.db.ColumnFamilyStore; -import org.apache.cassandra.db.Keyspace; import org.apache.cassandra.io.FSWriteError; import org.apache.cassandra.io.util.*; import org.apache.cassandra.service.CacheService; @@ -198,7 +198,7 @@ public class AutoSavingCache extends InstrumentingCachehttp://git-wip-us.apache.org/repos/asf/cassandra/blob/611d1bae/src/java/org/apache/cassandra/config/CFMetaData.java -- diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java b/src/java/org/apache/cassandra/config/CFMetaData.java index a8d528e..14271c0 100644 --- a/src/java/org/apache/cassandra/config/CFMetaData.java +++ b/src/java/org/apache/cassandra/config/CFMetaData.java @@ -50,7 +50,6 @@ import org.apache.cassandra.io.compress.CompressionParameters; import org.apache.cassandra.io.compress.LZ4Compressor; import org.apache.cassandra.io.sstable.format.Version; import org.apache.cassandra.io.util.FileDataInput; -import org.apache.cassa
[1/2] cassandra git commit: Cleanup and move hardcoded system tables away from CFMetaData
Repository: cassandra
Updated Branches:
refs/heads/trunk f096eb69d -> 611d1baec
http://git-wip-us.apache.org/repos/asf/cassandra/blob/611d1bae/src/java/org/apache/cassandra/db/SystemKeyspace.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemKeyspace.java
b/src/java/org/apache/cassandra/db/SystemKeyspace.java
index 4b18f7f..49c1502 100644
--- a/src/java/org/apache/cassandra/db/SystemKeyspace.java
+++ b/src/java/org/apache/cassandra/db/SystemKeyspace.java
@@ -22,6 +22,7 @@ import java.io.IOException;
import java.net.InetAddress;
import java.nio.ByteBuffer;
import java.util.*;
+import java.util.concurrent.TimeUnit;
import javax.management.openmbean.*;
import com.google.common.base.Function;
@@ -29,7 +30,6 @@ import com.google.common.collect.HashMultimap;
import com.google.common.collect.Iterables;
import com.google.common.collect.SetMultimap;
import com.google.common.collect.Sets;
-import org.apache.cassandra.io.sstable.format.SSTableReader;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -43,14 +43,17 @@ import org.apache.cassandra.cql3.UntypedResultSet;
import org.apache.cassandra.db.columniterator.IdentityQueryFilter;
import org.apache.cassandra.db.compaction.CompactionHistoryTabularData;
import org.apache.cassandra.db.commitlog.ReplayPosition;
+import org.apache.cassandra.db.compaction.LeveledCompactionStrategy;
import org.apache.cassandra.db.composites.Composite;
import org.apache.cassandra.db.filter.QueryFilter;
import org.apache.cassandra.db.marshal.*;
import org.apache.cassandra.dht.Range;
import org.apache.cassandra.dht.Token;
import org.apache.cassandra.exceptions.ConfigurationException;
+import org.apache.cassandra.io.sstable.format.SSTableReader;
import org.apache.cassandra.io.util.DataOutputBuffer;
import org.apache.cassandra.locator.IEndpointSnitch;
+import org.apache.cassandra.locator.LocalStrategy;
import org.apache.cassandra.metrics.RestorableMeter;
import org.apache.cassandra.service.StorageService;
import org.apache.cassandra.service.paxos.Commit;
@@ -62,39 +65,292 @@ import org.apache.cassandra.utils.*;
import static org.apache.cassandra.cql3.QueryProcessor.executeInternal;
import static org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal;
-public class SystemKeyspace
+public final class SystemKeyspace
{
private static final Logger logger =
LoggerFactory.getLogger(SystemKeyspace.class);
-// see CFMetaData for schema definitions
-public static final String PEERS_CF = "peers";
-public static final String PEER_EVENTS_CF = "peer_events";
-public static final String LOCAL_CF = "local";
-public static final String INDEX_CF = "IndexInfo";
-public static final String HINTS_CF = "hints";
-public static final String RANGE_XFERS_CF = "range_xfers";
-public static final String BATCHLOG_CF = "batchlog";
-// see layout description in the DefsTables class header
-public static final String SCHEMA_KEYSPACES_CF = "schema_keyspaces";
-public static final String SCHEMA_COLUMNFAMILIES_CF =
"schema_columnfamilies";
-public static final String SCHEMA_COLUMNS_CF = "schema_columns";
-public static final String SCHEMA_TRIGGERS_CF = "schema_triggers";
-public static final String SCHEMA_USER_TYPES_CF = "schema_usertypes";
-public static final String SCHEMA_FUNCTIONS_CF = "schema_functions";
-public static final String COMPACTION_LOG = "compactions_in_progress";
-public static final String PAXOS_CF = "paxos";
-public static final String SSTABLE_ACTIVITY_CF = "sstable_activity";
-public static final String COMPACTION_HISTORY_CF = "compaction_history";
+public static final String NAME = "system";
+
+public static final String SCHEMA_KEYSPACES_TABLE = "schema_keyspaces";
+public static final String SCHEMA_COLUMNFAMILIES_TABLE =
"schema_columnfamilies";
+public static final String SCHEMA_COLUMNS_TABLE = "schema_columns";
+public static final String SCHEMA_TRIGGERS_TABLE = "schema_triggers";
+public static final String SCHEMA_USER_TYPES_TABLE = "schema_usertypes";
+public static final String SCHEMA_FUNCTIONS_TABLE = "schema_functions";
+
+public static final String BUILT_INDEXES_TABLE = "IndexInfo";
+public static final String HINTS_TABLE = "hints";
+public static final String BATCHLOG_TABLE = "batchlog";
+public static final String PAXOS_TABLE = "paxos";
+public static final String LOCAL_TABLE = "local";
+public static final String PEERS_TABLE = "peers";
+public static final String PEER_EVENTS_TABLE = "peer_events";
+public static final String RANGE_XFERS_TABLE = "range_xfers";
+public static final String COMPACTION_LOG_TABLE =
"compactions_in_progress";
+public static final String COMPACTION_HISTORY_TABLE = "compaction_history";
+public static final String SSTABLE_ACTIVITY_TABLE = "sstable_activity";
+
+public static final Li
[jira] [Created] (CASSANDRA-8297) Milliseconds since epoch used for tracing tables
Aleksey Yeschenko created CASSANDRA-8297: Summary: Milliseconds since epoch used for tracing tables Key: CASSANDRA-8297 URL: https://issues.apache.org/jira/browse/CASSANDRA-8297 Project: Cassandra Issue Type: Bug Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Priority: Minor Fix For: 2.0.12, 2.1.3 Tracing tables seem to be the last place we are still accidentally using milliseconds for timestamps (vs. microseconds). This should be fixed for consistency sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8290) archiving commitlogs after restart fails
[
https://issues.apache.org/jira/browse/CASSANDRA-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207955#comment-14207955
]
Sam Tunnicliffe commented on CASSANDRA-8290:
Yes, this is caused by CASSANDRA-6904. The dtests around archiving use {{cp}}
rather than {{ln}} so didn't hit this. I'll take a look.
> archiving commitlogs after restart fails
> -
>
> Key: CASSANDRA-8290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8290
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.11
> Debian wheezy
>Reporter: Manuel Lausch
>Assignee: Sam Tunnicliffe
>Priority: Minor
>
> After update to Cassandra 2.0.11 Cassandra mostly fails during startup while
> archiving commitlogs
> see logfile:
> {noformat}
> RROR [main] 2014-11-03 13:08:59,388 CassandraDaemon.java (line 513) Exception
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:158)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:124)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:336)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:145)
> ... 4 more
> Caused by: java.lang.RuntimeException: java.io.IOException: Exception while
> executing the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Exception while executing the command:
> /bin/ln /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at org.apache.cassandra.utils.FBUtilities.exec(FBUtilities.java:604)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.exec(CommitLogArchiver.java:197)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.access$100(CommitLogArchiver.java:44)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver$1.runMayThrow(CommitLogArchiver.java:132)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ... 5 more
> ERROR [commitlog_archiver:1] 2014-11-03 13:08:59,388 CassandraDaemon.java
> (line 199) Exception in thread Thread[commitlog_archiver:1,5,main]
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/va
[jira] [Commented] (CASSANDRA-8261) Clean up schema metadata classes
[ https://issues.apache.org/jira/browse/CASSANDRA-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207929#comment-14207929 ] Sylvain Lebresne commented on CASSANDRA-8261: - Looks good overall, though it moves the timestamp from milliseconds to microseconds for tracing, which while a good thing per-se doesn't feel like something that should be sneaked in a big refactoring patch. So I'd have a minor preference for pulling that part in a separate ticket, but +1 otherwise. > Clean up schema metadata classes > > > Key: CASSANDRA-8261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8261 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0 > > Attachments: 8261-isolate-hadcoded-system-tables.txt, > 8261-isolate-thrift-code.txt > > > While working on CASSANDRA-6717, I've made some general cleanup changes to > schema metadata classes - distracted from the core purpose. Also, being > distracted from it by other things, every time I come back to it gives me a > bit of a rebase hell. > Thus I'm isolating those changes into a separate issue here, hoping to commit > them one by one, before I go back and finalize CASSANDRA-6717. > The changes include: > - moving all the toThrift/fromThrift conversion code to ThriftConversion, > where it belongs > - moving the complied system CFMetaData objects away from CFMetaData (to > SystemKeyspace and TracesKeyspace) > - isolating legacy toSchema/fromSchema code into a separate class > (LegacySchemaTables - former DefsTables) > - refactoring CFMetaData/KSMetaData fields to match CQL CREATE TABLE syntax, > and encapsulating more things in > CompactionOptions/CompressionOptions/ReplicationOptions classes > - moving the definition classes to the new 'schema' package -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8290) archiving commitlogs after restart fails
[
https://issues.apache.org/jira/browse/CASSANDRA-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207918#comment-14207918
]
Manuel Lausch edited comment on CASSANDRA-8290 at 11/12/14 10:42 AM:
-
The Upgrade was quite easy. Stopping Cassandra via init-script, Upgrade the
Package, starting the cassandra via init-script
The Problem occured not only while upgradeing. Yesterday I instelled OS-Updates
and rebootet the Nodes. After the reboot I run in this problem too. If I
disable gossip, the clientports and flush the memtable via nodetool bevor
stopping the Node all will work fine.
As far as I see archived commitlogs are not deleted in the commitlog dir. After
startup all commitlogs will be archived but the links were already created
before the shutdown of the cassandra happend.
PS: In 2.0.10 restarting of cassandra did not fail. This is new in 2.0.11
was (Author: mlausch):
The Upgrade was quite easy. Stopping Cassandra via init-script, Upgrade the
Package, starting the cassandra via init-script
The Problem occured not only while upgradeing. Yesterday I instelled OS-Updates
and rebootet the Nodes. After the reboot I run in this problem too. If I
disable gossip, the clientports and flush the memtable via nodetool bevor
stopping the Node all will work fine.
As far as I see archived commitlogs are not deleted in the commitlog dir. After
startup all commitlogs will be archived but the links were already created
before the shutdown of the cassandra happend.
> archiving commitlogs after restart fails
> -
>
> Key: CASSANDRA-8290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8290
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.11
> Debian wheezy
>Reporter: Manuel Lausch
>Assignee: Sam Tunnicliffe
>Priority: Minor
>
> After update to Cassandra 2.0.11 Cassandra mostly fails during startup while
> archiving commitlogs
> see logfile:
> {noformat}
> RROR [main] 2014-11-03 13:08:59,388 CassandraDaemon.java (line 513) Exception
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:158)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:124)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:336)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:145)
> ... 4 more
> Caused by: java.lang.RuntimeException: java.io.IOException: Exception while
> executing the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Exception while executing the command:
> /bin/ln /var/lib/cassandra/co
[jira] [Commented] (CASSANDRA-8290) archiving commitlogs after restart fails
[
https://issues.apache.org/jira/browse/CASSANDRA-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207918#comment-14207918
]
Manuel Lausch commented on CASSANDRA-8290:
--
The Upgrade was quite easy. Stopping Cassandra via init-script, Upgrade the
Package, starting the cassandra via init-script
The Problem occured not only while upgradeing. Yesterday I instelled OS-Updates
and rebootet the Nodes. After the reboot I run in this problem too. If I
disable gossip, the clientports and flush the memtable via nodetool bevor
stopping the Node all will work fine.
As far as I see archived commitlogs are not deleted in the commitlog dir. After
startup all commitlogs will be archived but the links were already created
before the shutdown of the cassandra happend.
> archiving commitlogs after restart fails
> -
>
> Key: CASSANDRA-8290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8290
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.11
> Debian wheezy
>Reporter: Manuel Lausch
>Assignee: Sam Tunnicliffe
>Priority: Minor
>
> After update to Cassandra 2.0.11 Cassandra mostly fails during startup while
> archiving commitlogs
> see logfile:
> {noformat}
> RROR [main] 2014-11-03 13:08:59,388 CassandraDaemon.java (line 513) Exception
> encountered during startup
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:158)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:124)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:336)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: java.io.IOException: Exception while executing
> the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.maybeWaitForArchiving(CommitLogArchiver.java:145)
> ... 4 more
> Caused by: java.lang.RuntimeException: java.io.IOException: Exception while
> executing the command: /bin/ln
> /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Exception while executing the command:
> /bin/ln /var/lib/cassandra/commitlog/CommitLog-3-1413451666161.log
> /var/lib/cassandra/archive/CommitLog-3-1413451666161.log, command error Code:
> 1, command output: /bin/ln: failed to create hard link
> `/var/lib/cassandra/archive/CommitLog-3-1413451666161.log': File exists
> at org.apache.cassandra.utils.FBUtilities.exec(FBUtilities.java:604)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.exec(CommitLogArchiver.java:197)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver.access$100(CommitLogArchiver.java:44)
> at
> org.apache.cassandra.db.commitlog.CommitLogArchiver$1.runMayThrow(CommitLogArchiver.java:132)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ... 5 m
[jira] [Commented] (CASSANDRA-8287) Row Level Isolation is violated by read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207875#comment-14207875 ] Sylvain Lebresne commented on CASSANDRA-8287: - You're right, read repair can screw up isolation. That said, the example above is actually not affected currently because CQL always read full CQL rows and thus the step 3) above (you now only read the password) actually don't happen internally. Granted, it's due to an inefficiency that we want to fix, so it's still something to consider. Anyway, that's a problem at the partition level, and I have no clue how to fix that efficiently. That said, and unless someone has a brilliant idea, I'd be fine with keeping it a know limitation at the partition level. Keeping it working at the CQL row level is probably more important however. > Row Level Isolation is violated by read repair > -- > > Key: CASSANDRA-8287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8287 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: sankalp kohli >Assignee: Sylvain Lebresne >Priority: Minor > > In 1.1, row level isolation was added. As per the blog post > http://www.datastax.com/dev/blog/row-level-isolation > "Cassandra guarantees that the changes to login and password are either both > applied or none are." > This is not true with background read repair. Consider this as given in the > blog post. > You run > UPDATE Users > SET login='eric22' AND password='f3g$dq!' > WHERE key='550e8400-e29b-41d4-a716-44665544' > There are 3 machines A,B and C and replication is RF=3 > 1) Machine A did not get this update as it was down and past hint window. > 2) Machine A comes online. > 3) You now only read the password. > 4) password is now read repaired on A. > SO on machine A, password = f3g$dq! and login is still old -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8287) Row Level Isolation is violated by read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-8287: Assignee: (was: Sylvain Lebresne) > Row Level Isolation is violated by read repair > -- > > Key: CASSANDRA-8287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8287 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: sankalp kohli >Priority: Minor > > In 1.1, row level isolation was added. As per the blog post > http://www.datastax.com/dev/blog/row-level-isolation > "Cassandra guarantees that the changes to login and password are either both > applied or none are." > This is not true with background read repair. Consider this as given in the > blog post. > You run > UPDATE Users > SET login='eric22' AND password='f3g$dq!' > WHERE key='550e8400-e29b-41d4-a716-44665544' > There are 3 machines A,B and C and replication is RF=3 > 1) Machine A did not get this update as it was down and past hint window. > 2) Machine A comes online. > 3) You now only read the password. > 4) password is now read repaired on A. > SO on machine A, password = f3g$dq! and login is still old -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8296) Can't add new node to a Cluster due to invalid gossip generation
Rafał Furmański created CASSANDRA-8296:
--
Summary: Can't add new node to a Cluster due to invalid gossip
generation
Key: CASSANDRA-8296
URL: https://issues.apache.org/jira/browse/CASSANDRA-8296
Project: Cassandra
Issue Type: Bug
Environment: Debian Wheezy
Cassandra 2.1.1
Reporter: Rafał Furmański
Hi all! I'm unable to add new node to an existing Cassandra cluster. I'm using
GossipingPropertyFileSnitch and after starting cassandra I get following errors
on other nodes:
{code}
WARN [GossipStage:2] 2014-11-12 09:38:43,297 Gossiper.java:993 - received an
invalid gossip generation for peer /10.210.3.230; local generation = 3,
received generation = 1415785003
{code}
New node's IP is 10.210.3.230. I can't see this IP in {code}nodetool
status{code}
Any ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8012) cqlsh "DESCRIBE KEYSPACES;" returns empty after upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207860#comment-14207860
]
Rafał Furmański commented on CASSANDRA-8012:
I have exact same issue in cassandra v. 2.1.1
{code}
root@db1:~# cqlsh 10.210.3.221 --debug
Using CQL driver:
Connected to Production Cluster at 10.210.3.221:9042.
[cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
cqlsh> DESCRIBE keyspaces;
cqlsh> DESCRIBE keyspace sync;
Traceback (most recent call last):
File "/usr/bin/cqlsh", line 861, in onecmd
self.handle_statement(st, statementtext)
File "/usr/bin/cqlsh", line 899, in handle_statement
return custom_handler(parsed)
File "/usr/bin/cqlsh", line 1265, in do_describe
self.describe_keyspace(ksname)
File "/usr/bin/cqlsh", line 1137, in describe_keyspace
self.print_recreate_keyspace(self.get_keyspace_meta(ksname), sys.stdout)
File "/usr/bin/cqlsh", line 699, in get_keyspace_meta
raise KeyspaceNotFound('Keyspace %r not found.' % ksname)
KeyspaceNotFound: Keyspace 'sync' not found.
cqlsh> use sync;
cqlsh:sync>
{code}
Any ideas how to fix this? Attaching cluster info:
{code}
root@db1:~# nodetool describecluster
Cluster Information:
Name: Production Cluster
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
f8040381-4d5b-38da-9eda-5fd96474694a: [10.210.3.160,
10.210.3.224, 10.210.3.221, 10.195.15.163, 10.195.15.162]
{code}
> cqlsh "DESCRIBE KEYSPACES;" returns empty after upgrade
> ---
>
> Key: CASSANDRA-8012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8012
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: cassandra 2.1.0
>Reporter: Shawn Zhou
>Assignee: Tyler Hobbs
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.3
>
>
> after upgrade from 2.0.7 to 2.1.0
> run cqlsh "DESCRIBE KEYSPACES;" returns empty result;
> query individual table does return data;
> See below:
> {noformat}
> [root@dc1-stg-cassandra-08 cassandra]# cqlsh
> dc1-stg-cassandra-08.dc01.revsci.net -k as_user_segment
> Connected to Stage Cluster at dc1-stg-cassandra-08.dc01.revsci.net:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> Use HELP for help.
> cqlsh:as_user_segment> DESCRIBE KEYSPACES;
>
> cqlsh:as_user_segment> select * from user_segments_blob where id =
> '8e6090087fc1a7591a99dc4cb744ac43';
> id | segments
> --+
> 8e6090087fc1a7591a99dc4cb744ac43 |
> 0x9416b015911d3b0e211aee227216ab1cdf0f4204
> (1 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
