[1/2] git commit: Make StreamSession#closeSession() idempotent
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 1c33ea367 - e398c6bb8
Make StreamSession#closeSession() idempotent
Patch by JoshuaMcKenzie; reviewed by marcuse for CASSANDRA-7262
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/709b9fc3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/709b9fc3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/709b9fc3
Branch: refs/heads/cassandra-2.1
Commit: 709b9fc319f669ee07338a842f36a9d77e8c46a1
Parents: e68ac31
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Jun 2 08:53:32 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Jun 2 08:58:11 2014 +0200
--
CHANGES.txt | 1 +
.../cassandra/streaming/StreamSession.java | 32
2 files changed, 20 insertions(+), 13 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/709b9fc3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d1d1030..bc95a8d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
* Add authentication support to shuffle (CASSANDRA-6484)
* Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325)
+ * Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
Merged from 1.2:
* Fix availability validation for LOCAL_ONE CL (CASSANDRA-7319)
* Use LOCAL_ONE for non-superuser auth queries (CASSANDRA-7328)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/709b9fc3/src/java/org/apache/cassandra/streaming/StreamSession.java
--
diff --git a/src/java/org/apache/cassandra/streaming/StreamSession.java
b/src/java/org/apache/cassandra/streaming/StreamSession.java
index 30e3fa2..79ad487 100644
--- a/src/java/org/apache/cassandra/streaming/StreamSession.java
+++ b/src/java/org/apache/cassandra/streaming/StreamSession.java
@@ -21,6 +21,7 @@ import java.io.IOException;
import java.net.InetAddress;
import java.util.*;
import java.util.concurrent.*;
+import java.util.concurrent.atomic.AtomicBoolean;
import com.google.common.collect.*;
import org.slf4j.Logger;
@@ -132,6 +133,8 @@ public class StreamSession implements
IEndpointStateChangeSubscriber, IFailureDe
private int retries;
+private AtomicBoolean isAborted = new AtomicBoolean(false);
+
public static enum State
{
INITIALIZED,
@@ -329,23 +332,26 @@ public class StreamSession implements
IEndpointStateChangeSubscriber, IFailureDe
}
}
-private void closeSession(State finalState)
+private synchronized void closeSession(State finalState)
{
-state(finalState);
-
-if (finalState == State.FAILED)
+if (isAborted.compareAndSet(false, true))
{
-for (StreamTask task : Iterables.concat(receivers.values(),
transfers.values()))
-task.abort();
-}
+state(finalState);
-// Note that we shouldn't block on this close because this method is
called on the handler
-// incoming thread (so we would deadlock).
-handler.close();
+if (finalState == State.FAILED)
+{
+for (StreamTask task : Iterables.concat(receivers.values(),
transfers.values()))
+task.abort();
+}
+
+// Note that we shouldn't block on this close because this method
is called on the handler
+// incoming thread (so we would deadlock).
+handler.close();
-Gossiper.instance.unregister(this);
-FailureDetector.instance.unregisterFailureDetectionEventListener(this);
-streamResult.handleSessionComplete(this);
+Gossiper.instance.unregister(this);
+
FailureDetector.instance.unregisterFailureDetectionEventListener(this);
+streamResult.handleSessionComplete(this);
+}
}
/**
git commit: Make StreamSession#closeSession() idempotent
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 e68ac31f3 - 709b9fc31
Make StreamSession#closeSession() idempotent
Patch by JoshuaMcKenzie; reviewed by marcuse for CASSANDRA-7262
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/709b9fc3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/709b9fc3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/709b9fc3
Branch: refs/heads/cassandra-2.0
Commit: 709b9fc319f669ee07338a842f36a9d77e8c46a1
Parents: e68ac31
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Jun 2 08:53:32 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Jun 2 08:58:11 2014 +0200
--
CHANGES.txt | 1 +
.../cassandra/streaming/StreamSession.java | 32
2 files changed, 20 insertions(+), 13 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/709b9fc3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d1d1030..bc95a8d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
* Add authentication support to shuffle (CASSANDRA-6484)
* Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325)
+ * Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
Merged from 1.2:
* Fix availability validation for LOCAL_ONE CL (CASSANDRA-7319)
* Use LOCAL_ONE for non-superuser auth queries (CASSANDRA-7328)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/709b9fc3/src/java/org/apache/cassandra/streaming/StreamSession.java
--
diff --git a/src/java/org/apache/cassandra/streaming/StreamSession.java
b/src/java/org/apache/cassandra/streaming/StreamSession.java
index 30e3fa2..79ad487 100644
--- a/src/java/org/apache/cassandra/streaming/StreamSession.java
+++ b/src/java/org/apache/cassandra/streaming/StreamSession.java
@@ -21,6 +21,7 @@ import java.io.IOException;
import java.net.InetAddress;
import java.util.*;
import java.util.concurrent.*;
+import java.util.concurrent.atomic.AtomicBoolean;
import com.google.common.collect.*;
import org.slf4j.Logger;
@@ -132,6 +133,8 @@ public class StreamSession implements
IEndpointStateChangeSubscriber, IFailureDe
private int retries;
+private AtomicBoolean isAborted = new AtomicBoolean(false);
+
public static enum State
{
INITIALIZED,
@@ -329,23 +332,26 @@ public class StreamSession implements
IEndpointStateChangeSubscriber, IFailureDe
}
}
-private void closeSession(State finalState)
+private synchronized void closeSession(State finalState)
{
-state(finalState);
-
-if (finalState == State.FAILED)
+if (isAborted.compareAndSet(false, true))
{
-for (StreamTask task : Iterables.concat(receivers.values(),
transfers.values()))
-task.abort();
-}
+state(finalState);
-// Note that we shouldn't block on this close because this method is
called on the handler
-// incoming thread (so we would deadlock).
-handler.close();
+if (finalState == State.FAILED)
+{
+for (StreamTask task : Iterables.concat(receivers.values(),
transfers.values()))
+task.abort();
+}
+
+// Note that we shouldn't block on this close because this method
is called on the handler
+// incoming thread (so we would deadlock).
+handler.close();
-Gossiper.instance.unregister(this);
-FailureDetector.instance.unregisterFailureDetectionEventListener(this);
-streamResult.handleSessionComplete(this);
+Gossiper.instance.unregister(this);
+
FailureDetector.instance.unregisterFailureDetectionEventListener(this);
+streamResult.handleSessionComplete(this);
+}
}
/**
[2/3] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e398c6bb Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e398c6bb Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e398c6bb Branch: refs/heads/trunk Commit: e398c6bb89d4463e251434650e92f1c464fe9b40 Parents: 1c33ea3 709b9fc Author: Marcus Eriksson marc...@apache.org Authored: Mon Jun 2 08:59:50 2014 +0200 Committer: Marcus Eriksson marc...@apache.org Committed: Mon Jun 2 08:59:50 2014 +0200 -- CHANGES.txt | 1 + .../cassandra/streaming/StreamSession.java | 32 2 files changed, 20 insertions(+), 13 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e398c6bb/CHANGES.txt -- diff --cc CHANGES.txt index af4da65,bc95a8d..c7c6877 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,8 -1,18 +1,9 @@@ -2.0.9 +2.1.0 + * Upgrade to Pig 0.12.1 (CASSANDRA-6556) +Merged from 2.0: * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323) - * Add conditional CREATE/DROP USER support (CASSANDRA-7264) - * Swap local and global default read repair chances (CASSANDRA-7320) - * Add missing iso8601 patterns for date strings (CASSANDRA-6973) - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875) - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274) - * Copy compaction options to make sure they are reloaded (CASSANDRA-7290) - * Add option to do more aggressive tombstone compactions (CASSANDRA-6563) - * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288) - * Add authentication support to shuffle (CASSANDRA-6484) - * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325) + * Make StreamSession#closeSession() idempotent (CASSANDRA-7262) Merged from 1.2: - * Fix availability validation for LOCAL_ONE CL (CASSANDRA-7319) * Use LOCAL_ONE for non-superuser auth queries (CASSANDRA-7328) http://git-wip-us.apache.org/repos/asf/cassandra/blob/e398c6bb/src/java/org/apache/cassandra/streaming/StreamSession.java --
[1/3] git commit: Make StreamSession#closeSession() idempotent
Repository: cassandra
Updated Branches:
refs/heads/trunk 953a3729f - d66022392
Make StreamSession#closeSession() idempotent
Patch by JoshuaMcKenzie; reviewed by marcuse for CASSANDRA-7262
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/709b9fc3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/709b9fc3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/709b9fc3
Branch: refs/heads/trunk
Commit: 709b9fc319f669ee07338a842f36a9d77e8c46a1
Parents: e68ac31
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Jun 2 08:53:32 2014 +0200
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Jun 2 08:58:11 2014 +0200
--
CHANGES.txt | 1 +
.../cassandra/streaming/StreamSession.java | 32
2 files changed, 20 insertions(+), 13 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/709b9fc3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d1d1030..bc95a8d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* Don't try to compact already-compacting files in HHOM (CASSANDRA-7288)
* Add authentication support to shuffle (CASSANDRA-6484)
* Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325)
+ * Make StreamSession#closeSession() idempotent (CASSANDRA-7262)
Merged from 1.2:
* Fix availability validation for LOCAL_ONE CL (CASSANDRA-7319)
* Use LOCAL_ONE for non-superuser auth queries (CASSANDRA-7328)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/709b9fc3/src/java/org/apache/cassandra/streaming/StreamSession.java
--
diff --git a/src/java/org/apache/cassandra/streaming/StreamSession.java
b/src/java/org/apache/cassandra/streaming/StreamSession.java
index 30e3fa2..79ad487 100644
--- a/src/java/org/apache/cassandra/streaming/StreamSession.java
+++ b/src/java/org/apache/cassandra/streaming/StreamSession.java
@@ -21,6 +21,7 @@ import java.io.IOException;
import java.net.InetAddress;
import java.util.*;
import java.util.concurrent.*;
+import java.util.concurrent.atomic.AtomicBoolean;
import com.google.common.collect.*;
import org.slf4j.Logger;
@@ -132,6 +133,8 @@ public class StreamSession implements
IEndpointStateChangeSubscriber, IFailureDe
private int retries;
+private AtomicBoolean isAborted = new AtomicBoolean(false);
+
public static enum State
{
INITIALIZED,
@@ -329,23 +332,26 @@ public class StreamSession implements
IEndpointStateChangeSubscriber, IFailureDe
}
}
-private void closeSession(State finalState)
+private synchronized void closeSession(State finalState)
{
-state(finalState);
-
-if (finalState == State.FAILED)
+if (isAborted.compareAndSet(false, true))
{
-for (StreamTask task : Iterables.concat(receivers.values(),
transfers.values()))
-task.abort();
-}
+state(finalState);
-// Note that we shouldn't block on this close because this method is
called on the handler
-// incoming thread (so we would deadlock).
-handler.close();
+if (finalState == State.FAILED)
+{
+for (StreamTask task : Iterables.concat(receivers.values(),
transfers.values()))
+task.abort();
+}
+
+// Note that we shouldn't block on this close because this method
is called on the handler
+// incoming thread (so we would deadlock).
+handler.close();
-Gossiper.instance.unregister(this);
-FailureDetector.instance.unregisterFailureDetectionEventListener(this);
-streamResult.handleSessionComplete(this);
+Gossiper.instance.unregister(this);
+
FailureDetector.instance.unregisterFailureDetectionEventListener(this);
+streamResult.handleSessionComplete(this);
+}
}
/**
[3/3] 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/d6602239 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d6602239 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d6602239 Branch: refs/heads/trunk Commit: d66022392f4cd4b8ef840adbef4ec6733ec4a51e Parents: 953a372 e398c6b Author: Marcus Eriksson marc...@apache.org Authored: Mon Jun 2 09:00:03 2014 +0200 Committer: Marcus Eriksson marc...@apache.org Committed: Mon Jun 2 09:00:03 2014 +0200 -- CHANGES.txt | 1 + .../cassandra/streaming/StreamSession.java | 32 2 files changed, 20 insertions(+), 13 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/d6602239/CHANGES.txt --
[2/2] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e398c6bb Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e398c6bb Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e398c6bb Branch: refs/heads/cassandra-2.1 Commit: e398c6bb89d4463e251434650e92f1c464fe9b40 Parents: 1c33ea3 709b9fc Author: Marcus Eriksson marc...@apache.org Authored: Mon Jun 2 08:59:50 2014 +0200 Committer: Marcus Eriksson marc...@apache.org Committed: Mon Jun 2 08:59:50 2014 +0200 -- CHANGES.txt | 1 + .../cassandra/streaming/StreamSession.java | 32 2 files changed, 20 insertions(+), 13 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e398c6bb/CHANGES.txt -- diff --cc CHANGES.txt index af4da65,bc95a8d..c7c6877 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,8 -1,18 +1,9 @@@ -2.0.9 +2.1.0 + * Upgrade to Pig 0.12.1 (CASSANDRA-6556) +Merged from 2.0: * Fix NPE in StreamTransferTask.createMessageForRetry() (CASSANDRA-7323) - * Add conditional CREATE/DROP USER support (CASSANDRA-7264) - * Swap local and global default read repair chances (CASSANDRA-7320) - * Add missing iso8601 patterns for date strings (CASSANDRA-6973) - * Support selecting multiple rows in a partition using IN (CASSANDRA-6875) - * cqlsh: always emphasize the partition key in DESC output (CASSANDRA-7274) - * Copy compaction options to make sure they are reloaded (CASSANDRA-7290) - * Add option to do more aggressive tombstone compactions (CASSANDRA-6563) - * Don't try to compact already-compacting files in HHOM (CASSANDRA-7288) - * Add authentication support to shuffle (CASSANDRA-6484) - * Cqlsh counts non-empty lines for Blank lines warning (CASSANDRA-7325) + * Make StreamSession#closeSession() idempotent (CASSANDRA-7262) Merged from 1.2: - * Fix availability validation for LOCAL_ONE CL (CASSANDRA-7319) * Use LOCAL_ONE for non-superuser auth queries (CASSANDRA-7328) http://git-wip-us.apache.org/repos/asf/cassandra/blob/e398c6bb/src/java/org/apache/cassandra/streaming/StreamSession.java --
[jira] [Updated] (CASSANDRA-7330) Infinite loop in StreamReader.read during exception condition while running repair
[
https://issues.apache.org/jira/browse/CASSANDRA-7330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-7330:
---
Reviewer: Marcus Eriksson
Infinite loop in StreamReader.read during exception condition while running
repair
--
Key: CASSANDRA-7330
URL: https://issues.apache.org/jira/browse/CASSANDRA-7330
Project: Cassandra
Issue Type: Bug
Environment: 2.0.8+
Reporter: Joshua McKenzie
Assignee: Joshua McKenzie
Priority: Minor
Labels: Core
Fix For: 2.0.9
Attachments: 7330_v1.txt
InputStream.skip is returning -1 during exception conditions which leads the
following logic to infinite loop:
{code:title=loop}
protected void drain(InputStream dis, long bytesRead) throws IOException
{
long toSkip = totalSize() - bytesRead;
toSkip = toSkip - dis.skip(toSkip);
while (toSkip 0)
toSkip = toSkip - dis.skip(toSkip);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7330) Infinite loop in StreamReader.read during exception condition while running repair
[
https://issues.apache.org/jira/browse/CASSANDRA-7330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015218#comment-14015218
]
Marcus Eriksson commented on CASSANDRA-7330:
patch looks good to me, but lets wait with committing until we have the AE
figured out
Infinite loop in StreamReader.read during exception condition while running
repair
--
Key: CASSANDRA-7330
URL: https://issues.apache.org/jira/browse/CASSANDRA-7330
Project: Cassandra
Issue Type: Bug
Environment: 2.0.8+
Reporter: Joshua McKenzie
Assignee: Joshua McKenzie
Priority: Minor
Labels: Core
Fix For: 2.0.9
Attachments: 7330_v1.txt
InputStream.skip is returning -1 during exception conditions which leads the
following logic to infinite loop:
{code:title=loop}
protected void drain(InputStream dis, long bytesRead) throws IOException
{
long toSkip = totalSize() - bytesRead;
toSkip = toSkip - dis.skip(toSkip);
while (toSkip 0)
toSkip = toSkip - dis.skip(toSkip);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
buildbot success in ASF Buildbot on cassandra-trunk
The Buildbot has detected a restored build on builder cassandra-trunk while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/276 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch trunk] d66022392f4cd4b8ef840adbef4ec6733ec4a51e Blamelist: Marcus Eriksson marc...@apache.org Build succeeded! sincerely, -The Buildbot
[jira] [Created] (CASSANDRA-7337) Protocol batches wrongly ignores conditions
Sylvain Lebresne created CASSANDRA-7337: --- Summary: Protocol batches wrongly ignores conditions Key: CASSANDRA-7337 URL: https://issues.apache.org/jira/browse/CASSANDRA-7337 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 2.0.9 When using protocol batches, we ignore the fact that statements may have conditions and subsequently call the wrong code path. The batches ends up being executed has if there was no conditions (but the ResultSet is empty which should make it clear something is wrong). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7337) Protocol batches wrongly ignores conditions
[ https://issues.apache.org/jira/browse/CASSANDRA-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7337: Attachment: 7337.txt Simple patch attached. Protocol batches wrongly ignores conditions --- Key: CASSANDRA-7337 URL: https://issues.apache.org/jira/browse/CASSANDRA-7337 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 2.0.9 Attachments: 7337.txt When using protocol batches, we ignore the fact that statements may have conditions and subsequently call the wrong code path. The batches ends up being executed has if there was no conditions (but the ResultSet is empty which should make it clear something is wrong). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7305) CQL3, Static columns not returning rows if values are not set
[ https://issues.apache.org/jira/browse/CASSANDRA-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-7305: Fix Version/s: 2.0.9 CQL3, Static columns not returning rows if values are not set - Key: CASSANDRA-7305 URL: https://issues.apache.org/jira/browse/CASSANDRA-7305 Project: Cassandra Issue Type: Bug Components: Core Reporter: Patrick Callaghan Assignee: Sylvain Lebresne Fix For: 2.0.9 Just a quick note on static columns, if you create some cql rows using clustered columns and don't provide a value for a static column, then selecting the row key with the (null) static column won't return any rows. create table statictest( a int, b text static, c text, PRIMARY KEY (a, c)); insert into statictest (a, c) values (1, 'test'); select a,b from statictest; (0 rows) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-3569) Failure detector downs should not break streams
[
https://issues.apache.org/jira/browse/CASSANDRA-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015351#comment-14015351
]
Marcus Eriksson commented on CASSANDRA-3569:
yes, it all seems to work now, very cool
I'll commit all 3 patches once CASSANDRA-7330 has been fixed
Failure detector downs should not break streams
---
Key: CASSANDRA-3569
URL: https://issues.apache.org/jira/browse/CASSANDRA-3569
Project: Cassandra
Issue Type: New Feature
Reporter: Peter Schuller
Assignee: Joshua McKenzie
Fix For: 2.1.1
Attachments: 3569-2.0.txt, 3569_v1.txt
CASSANDRA-2433 introduced this behavior just to get repairs to don't sit
there waiting forever. In my opinion the correct fix to that problem is to
use TCP keep alive. Unfortunately the TCP keep alive period is insanely high
by default on a modern Linux, so just doing that is not entirely good either.
But using the failure detector seems non-sensicle to me. We have a
communication method which is the TCP transport, that we know is used for
long-running processes that you don't want to incorrectly be killed for no
good reason, and we are using a failure detector tuned to detecting when not
to send real-time sensitive request to nodes in order to actively kill a
working connection.
So, rather than add complexity with protocol based ping/pongs and such, I
propose that we simply just use TCP keep alive for streaming connections and
instruct operators of production clusters to tweak
net.ipv4.tcp_keepalive_{probes,intvl} as appropriate (or whatever equivalent
on their OS).
I can submit the patch. Awaiting opinions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7338) CFS.getRangeSlice should update latency metrics
Sam Tunnicliffe created CASSANDRA-7338: -- Summary: CFS.getRangeSlice should update latency metrics Key: CASSANDRA-7338 URL: https://issues.apache.org/jira/browse/CASSANDRA-7338 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Trivial Fix For: 2.0.9 CFS.getRangeSlice doesn't update the CF readLatency metric in the same way as CFS.getColumnFamily does. I may be missing something, but I couldn't see a good reason why this wasn't already the case as without it, SELECT * FROM t WHERE x=y results in the read metrics being incremented, but SELECT * FROM t doesn't. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7338) CFS.getRangeSlice should update latency metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-7338: --- Attachment: CASSANDRA-7338.txt CFS.getRangeSlice should update latency metrics --- Key: CASSANDRA-7338 URL: https://issues.apache.org/jira/browse/CASSANDRA-7338 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Trivial Fix For: 2.0.9 Attachments: CASSANDRA-7338.txt CFS.getRangeSlice doesn't update the CF readLatency metric in the same way as CFS.getColumnFamily does. I may be missing something, but I couldn't see a good reason why this wasn't already the case as without it, SELECT * FROM t WHERE x=y results in the read metrics being incremented, but SELECT * FROM t doesn't. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7339) Allow custom callbacks to be specified for write operations
[ https://issues.apache.org/jira/browse/CASSANDRA-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-7339: --- Attachment: CASSANDRA-7339.txt Allow custom callbacks to be specified for write operations --- Key: CASSANDRA-7339 URL: https://issues.apache.org/jira/browse/CASSANDRA-7339 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Minor Fix For: 2.0.9 Attachments: CASSANDRA-7339.txt For testing/debugging/monitoring purposes it can be useful to perform some additional processing when remote writes are performed in StorageProxy. The fact that C* already uses a callback mechanism here is almost ideal, except for the lack of a way to supply custom callbacks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7339) Allow custom callbacks to be specified for write operations
Sam Tunnicliffe created CASSANDRA-7339: -- Summary: Allow custom callbacks to be specified for write operations Key: CASSANDRA-7339 URL: https://issues.apache.org/jira/browse/CASSANDRA-7339 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Minor Fix For: 2.0.9 Attachments: CASSANDRA-7339.txt For testing/debugging/monitoring purposes it can be useful to perform some additional processing when remote writes are performed in StorageProxy. The fact that C* already uses a callback mechanism here is almost ideal, except for the lack of a way to supply custom callbacks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7338) CFS.getRangeSlice should update latency metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015365#comment-14015365 ] Benedict commented on CASSANDRA-7338: - These are not equivalent operations? I'm not convinced we should be mixing statistics for them, as the currently measured requests should all be comparable in latency (give or take), whereas a range scan is necessarily a much more (and arbitrarily) expensive operation. They're tracked at the ClientRequestMetrics level in StorageProxy under rangeMetrics CFS.getRangeSlice should update latency metrics --- Key: CASSANDRA-7338 URL: https://issues.apache.org/jira/browse/CASSANDRA-7338 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Trivial Fix For: 2.0.9 Attachments: CASSANDRA-7338.txt CFS.getRangeSlice doesn't update the CF readLatency metric in the same way as CFS.getColumnFamily does. I may be missing something, but I couldn't see a good reason why this wasn't already the case as without it, SELECT * FROM t WHERE x=y results in the read metrics being incremented, but SELECT * FROM t doesn't. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7338) CFS.getRangeSlice should update latency metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015386#comment-14015386 ] Sam Tunnicliffe commented on CASSANDRA-7338: Fair point about them being different operations not not mixing the metrics for the two. What I'm looking for though are the latency stats for reading range slices from sstables as measured at the replica, not the coordinator so ClientRequestMetrics isn't what I'm after. Perhaps we could add an additional rangeMetrics field to ColumnFamilyMetrics, so that it mirrors StorageProxy (i.e. distinct metrics for read/write/range)? CFS.getRangeSlice should update latency metrics --- Key: CASSANDRA-7338 URL: https://issues.apache.org/jira/browse/CASSANDRA-7338 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Trivial Fix For: 2.0.9 Attachments: CASSANDRA-7338.txt CFS.getRangeSlice doesn't update the CF readLatency metric in the same way as CFS.getColumnFamily does. I may be missing something, but I couldn't see a good reason why this wasn't already the case as without it, SELECT * FROM t WHERE x=y results in the read metrics being incremented, but SELECT * FROM t doesn't. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7338) CFS.getRangeSlice should update latency metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015391#comment-14015391 ] Aleksey Yeschenko commented on CASSANDRA-7338: -- A new metric WFM. CFS.getRangeSlice should update latency metrics --- Key: CASSANDRA-7338 URL: https://issues.apache.org/jira/browse/CASSANDRA-7338 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Trivial Fix For: 2.0.9 Attachments: CASSANDRA-7338.txt CFS.getRangeSlice doesn't update the CF readLatency metric in the same way as CFS.getColumnFamily does. I may be missing something, but I couldn't see a good reason why this wasn't already the case as without it, SELECT * FROM t WHERE x=y results in the read metrics being incremented, but SELECT * FROM t doesn't. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7286) Exception: NPE
[ https://issues.apache.org/jira/browse/CASSANDRA-7286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015403#comment-14015403 ] Julien Anguenot edited comment on CASSANDRA-7286 at 6/2/14 2:05 PM: Exception still happening with 2.0.8 consistently across all nodes of the cluster. Let me know if you need more information. was (Author: anguenot): Exception still happening with 2.0.8 consistently across all nodes of the cluster. Let me know wh Exception: NPE --- Key: CASSANDRA-7286 URL: https://issues.apache.org/jira/browse/CASSANDRA-7286 Project: Cassandra Issue Type: Bug Reporter: Julien Anguenot Attachments: npe_cassandra_2_0_8.txt, readstage_npe.txt Sometimes Cassandra nodes (in a multi datacenter deployment) are throwing NPE (see attached stack trace) Let me know what additional information I could provide. Thank you. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-3569) Failure detector downs should not break streams
[
https://issues.apache.org/jira/browse/CASSANDRA-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015060#comment-14015060
]
Joshua McKenzie edited comment on CASSANDRA-3569 at 6/2/14 2:13 PM:
[~krummas]: 3569_v1.txt w/CASSANDRA-7329 and CASSANDRA-7330 applied looks like
its testing out cleanly for the problem conditions you brought up on my
configuration. The only outstanding issue I know of is the new AE (edit: not
NPE) that I'll be addressing via CASSANDRA-7330 - let me know how the tests
look for you using iptables w/those 3 patches applied.
was (Author: joshuamckenzie):
[~krummas]: 3569_v1.txt w/CASSANDRA-7329 and CASSANDRA-7330 applied looks like
its testing out cleanly for the problem conditions you brought up on my
configuration. The only outstanding issue I know of is the new NPE that I'll
be addressing via CASSANDRA-7330 - let me know how the tests look for you using
iptables w/those 3 patches applied.
Failure detector downs should not break streams
---
Key: CASSANDRA-3569
URL: https://issues.apache.org/jira/browse/CASSANDRA-3569
Project: Cassandra
Issue Type: New Feature
Reporter: Peter Schuller
Assignee: Joshua McKenzie
Fix For: 2.1.1
Attachments: 3569-2.0.txt, 3569_v1.txt
CASSANDRA-2433 introduced this behavior just to get repairs to don't sit
there waiting forever. In my opinion the correct fix to that problem is to
use TCP keep alive. Unfortunately the TCP keep alive period is insanely high
by default on a modern Linux, so just doing that is not entirely good either.
But using the failure detector seems non-sensicle to me. We have a
communication method which is the TCP transport, that we know is used for
long-running processes that you don't want to incorrectly be killed for no
good reason, and we are using a failure detector tuned to detecting when not
to send real-time sensitive request to nodes in order to actively kill a
working connection.
So, rather than add complexity with protocol based ping/pongs and such, I
propose that we simply just use TCP keep alive for streaming connections and
instruct operators of production clusters to tweak
net.ipv4.tcp_keepalive_{probes,intvl} as appropriate (or whatever equivalent
on their OS).
I can submit the patch. Awaiting opinions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7338) CFS.getRangeSlice should update latency metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-7338: --- Attachment: CASSANDRA-7338-v2.txt Attached v2 which adds a new LatencyMetric to ColumnFamilyMetrics for local range slices. CFS.getRangeSlice should update latency metrics --- Key: CASSANDRA-7338 URL: https://issues.apache.org/jira/browse/CASSANDRA-7338 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Priority: Trivial Fix For: 2.0.9 Attachments: CASSANDRA-7338-v2.txt, CASSANDRA-7338.txt CFS.getRangeSlice doesn't update the CF readLatency metric in the same way as CFS.getColumnFamily does. I may be missing something, but I couldn't see a good reason why this wasn't already the case as without it, SELECT * FROM t WHERE x=y results in the read metrics being incremented, but SELECT * FROM t doesn't. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7337) Protocol batches wrongly ignores conditions
[ https://issues.apache.org/jira/browse/CASSANDRA-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-7337: - Reviewer: Aleksey Yeschenko Protocol batches wrongly ignores conditions --- Key: CASSANDRA-7337 URL: https://issues.apache.org/jira/browse/CASSANDRA-7337 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 2.0.9 Attachments: 7337.txt When using protocol batches, we ignore the fact that statements may have conditions and subsequently call the wrong code path. The batches ends up being executed has if there was no conditions (but the ResultSet is empty which should make it clear something is wrong). -- This message was sent by Atlassian JIRA (v6.2#6252)
Git Push Summary
Repository: cassandra Updated Tags: refs/tags/2.1.0-rc1-tentative [deleted] c108ce5bf
Git Push Summary
Repository: cassandra Updated Tags: refs/tags/cassandra-2.1.0-rc1 [created] 8634f4520
svn commit: r1599264 - in /cassandra/site: publish/download/index.html src/settings.py
Author: slebresne Date: Mon Jun 2 16:47:47 2014 New Revision: 1599264 URL: http://svn.apache.org/r1599264 Log: Update website for 2.1.0-rc1 release Modified: cassandra/site/publish/download/index.html cassandra/site/src/settings.py Modified: cassandra/site/publish/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1599264r1=1599263r2=1599264view=diff == --- cassandra/site/publish/download/index.html (original) +++ cassandra/site/publish/download/index.html Mon Jun 2 16:47:47 2014 @@ -98,16 +98,16 @@ h2 class=hdrDevelopment Cassandra Server Releases (not production ready)/h2 p - The latest development release is 2.1.0-beta2 (released on - 2014-05-05). + The latest development release is 2.1.0-rc1 (released on + 2014-06-02). /p ul li -a class=filename href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.1.0/apache-cassandra-2.1.0-beta2-bin.tar.gz;apache-cassandra-2.1.0-beta2-bin.tar.gz/a -[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-beta2-bin.tar.gz.asc;PGP/a] -[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-beta2-bin.tar.gz.md5;MD5/a] -[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-beta2-bin.tar.gz.sha1;SHA1/a] +a class=filename href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.1.0/apache-cassandra-2.1.0-rc1-bin.tar.gz;apache-cassandra-2.1.0-rc1-bin.tar.gz/a +[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-rc1-bin.tar.gz.asc;PGP/a] +[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-rc1-bin.tar.gz.md5;MD5/a] +[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-rc1-bin.tar.gz.sha1;SHA1/a] /li /ul @@ -186,10 +186,10 @@ li -a class=filename href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.1.0/apache-cassandra-2.1.0-beta2-src.tar.gz;apache-cassandra-2.1.0-beta2-src.tar.gz/a -[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-beta2-src.tar.gz.asc;PGP/a] -[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-beta2-src.tar.gz.md5;MD5/a] -[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-beta2-src.tar.gz.sha1;SHA1/a] +a class=filename href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.1.0/apache-cassandra-2.1.0-rc1-src.tar.gz;apache-cassandra-2.1.0-rc1-src.tar.gz/a +[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-rc1-src.tar.gz.asc;PGP/a] +[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-rc1-src.tar.gz.md5;MD5/a] +[a href=http://www.apache.org/dist/cassandra/2.1.0/apache-cassandra-2.1.0-rc1-src.tar.gz.sha1;SHA1/a] /li /ul Modified: cassandra/site/src/settings.py URL: http://svn.apache.org/viewvc/cassandra/site/src/settings.py?rev=1599264r1=1599263r2=1599264view=diff == --- cassandra/site/src/settings.py (original) +++ cassandra/site/src/settings.py Mon Jun 2 16:47:47 2014 @@ -100,8 +100,8 @@ class CassandraDef(object): veryoldstable_exists = True stable_version = '2.0.8' stable_release_date = '2014-05-29' -devel_version = '2.1.0-beta2' -devel_release_date = '2014-05-05' +devel_version = '2.1.0-rc1' +devel_release_date = '2014-06-02' devel_exists = True _apache_base_url = 'http://www.apache.org' _svn_base_url = 'https://svn.apache.org/repos/asf'
[jira] [Commented] (CASSANDRA-7337) Protocol batches wrongly ignores conditions
[ https://issues.apache.org/jira/browse/CASSANDRA-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015544#comment-14015544 ] Aleksey Yeschenko commented on CASSANDRA-7337: -- +1 Protocol batches wrongly ignores conditions --- Key: CASSANDRA-7337 URL: https://issues.apache.org/jira/browse/CASSANDRA-7337 Project: Cassandra Issue Type: Bug Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 2.0.9 Attachments: 7337.txt When using protocol batches, we ignore the fact that statements may have conditions and subsequently call the wrong code path. The batches ends up being executed has if there was no conditions (but the ResultSet is empty which should make it clear something is wrong). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7334) RecoveryManagerTest times out on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015679#comment-14015679
]
Ala' Alkhaldi commented on CASSANDRA-7334:
--
This failure is caused by the issue reported in
[CASSANDRA-4337|https://issues.apache.org/jira/browse/CASSANDRA-4337]
RecoveryManagerTest times out on Windows
Key: CASSANDRA-7334
URL: https://issues.apache.org/jira/browse/CASSANDRA-7334
Project: Cassandra
Issue Type: Sub-task
Reporter: Joshua McKenzie
Assignee: Ala' Alkhaldi
Priority: Minor
Labels: Windows
Fix For: 3.0
Takes 11 seconds on a slow linux vm to pass, times out on Windows.
{code:title=timeout message}
[junit] Testcase:
org.apache.cassandra.db.RecoveryManagerTest:testRecoverCounter: Caused an
ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
[junit]
[junit] Test org.apache.cassandra.db.RecoveryManagerTest FAILED (timeout)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7340) CqlRecordWriter doesn't have user/password authentication
Alex Liu created CASSANDRA-7340: --- Summary: CqlRecordWriter doesn't have user/password authentication Key: CASSANDRA-7340 URL: https://issues.apache.org/jira/browse/CASSANDRA-7340 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Alex Liu Assignee: Alex Liu Fix For: 2.0.9 CqlRecordWriter doesn't create Cassandra client based on cassandra.output.keyspace.username and cassandra.output.keyspace.passwd setting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3
[ https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7245: -- Attachment: netty-all-4.0.19.Final.jar Out-of-Order keys with stress + CQL3 Key: CASSANDRA-7245 URL: https://issues.apache.org/jira/browse/CASSANDRA-7245 Project: Cassandra Issue Type: Bug Components: Core Reporter: Pavel Yaskevich Assignee: T Jake Luciani Fix For: 2.1.0 Attachments: 7245-v2.txt, 7245.txt, netty-all-4.0.19.Final.jar We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 and found following problem almost in every SSTable generated (~200 GB of data and 821 SSTables). We set up they keys to be 10 bytes in size (default) and population between 1 and 6. Once I ran 'sstablekeys' on the generated SSTable files I got following exceptions: _There is a problem with sorting of normal looking keys:_ 30303039443538353645 30303039443745364242 java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, *30303039443745364242*) DecoratedKey(-1767746583617597213, *30303039443437454333*) 0a30303033343933 3734441388343933 java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, *3734441388343933*) DecoratedKey(-7565486415339257200, *30303033344639443137*) 30303033354244363031 30303033354133423742 java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, *30303033354133423742*) DecoratedKey(-7838239767410066684, *30303033354145344534*) 30303034313442354137 3034313635363334 java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, *3034313635363334*) DecoratedKey(-9106177395653818217, *3030303431444238*) 30303035373044373435 30303035373044334631 java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, *30303035373044334631*) DecoratedKey(-4296696226469000945, *30303035373132364138*) _And completely different ones:_ 30303041333745373543 7cd045c59a90d7587d8d java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, *7cd045c59a90d7587d8d*) DecoratedKey(-5146766422778260690, *30303041333943303232*) 3030303332314144 30303033323346343932 java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, *30303033323346343932*) DecoratedKey(5233296131921119414, *53d83e0012287e03*) 30303034314531374431 3806734b256c27e41ec2 java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, *3806734b256c27e41ec2*) DecoratedKey(-8072288379146044663, *30303034314136413343*) _And sometimes there is no problem at all:_ 30303033353144463637 002a31b3b31a1c2f 5d616dd38211ebb5d6ec 444236451388 1388138844463744 30303033353143394343 It's worth to mention that we have got 22 timeout exceptions but number of out-of-order keys is much larger than that. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3
[ https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7245: -- Attachment: 7245v3.txt v3 passes my cluster tests for counters/non-counters. I still need to test with triggers and batch inserts though. Could you test this version [~jasobrown] with the attached netty jar? Out-of-Order keys with stress + CQL3 Key: CASSANDRA-7245 URL: https://issues.apache.org/jira/browse/CASSANDRA-7245 Project: Cassandra Issue Type: Bug Components: Core Reporter: Pavel Yaskevich Assignee: T Jake Luciani Fix For: 2.1.0 Attachments: 7245-v2.txt, 7245.txt, 7245v3.txt, netty-all-4.0.19.Final.jar We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 and found following problem almost in every SSTable generated (~200 GB of data and 821 SSTables). We set up they keys to be 10 bytes in size (default) and population between 1 and 6. Once I ran 'sstablekeys' on the generated SSTable files I got following exceptions: _There is a problem with sorting of normal looking keys:_ 30303039443538353645 30303039443745364242 java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, *30303039443745364242*) DecoratedKey(-1767746583617597213, *30303039443437454333*) 0a30303033343933 3734441388343933 java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, *3734441388343933*) DecoratedKey(-7565486415339257200, *30303033344639443137*) 30303033354244363031 30303033354133423742 java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, *30303033354133423742*) DecoratedKey(-7838239767410066684, *30303033354145344534*) 30303034313442354137 3034313635363334 java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, *3034313635363334*) DecoratedKey(-9106177395653818217, *3030303431444238*) 30303035373044373435 30303035373044334631 java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, *30303035373044334631*) DecoratedKey(-4296696226469000945, *30303035373132364138*) _And completely different ones:_ 30303041333745373543 7cd045c59a90d7587d8d java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, *7cd045c59a90d7587d8d*) DecoratedKey(-5146766422778260690, *30303041333943303232*) 3030303332314144 30303033323346343932 java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, *30303033323346343932*) DecoratedKey(5233296131921119414, *53d83e0012287e03*) 30303034314531374431 3806734b256c27e41ec2 java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, *3806734b256c27e41ec2*) DecoratedKey(-8072288379146044663, *30303034314136413343*) _And sometimes there is no problem at all:_ 30303033353144463637 002a31b3b31a1c2f 5d616dd38211ebb5d6ec 444236451388 1388138844463744 30303033353143394343 It's worth to mention that we have got 22 timeout exceptions but number of out-of-order keys is much larger than that. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7334) RecoveryManagerTest times out on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015679#comment-14015679
]
Ala' Alkhaldi edited comment on CASSANDRA-7334 at 6/2/14 9:11 PM:
--
I reproduced the failure on my Windows 7 machine. After checking system.log I
found the following IOException:
{code:title=File-rename exception}
ERROR [COMMIT-LOG-ALLOCATOR] 2014-06-02 14:00:28,319 Caller+0at
org.apache.cassandra.SchemaLoader$1.uncaughtException(SchemaLoader.java:64)
- Fatal exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main]
org.apache.cassandra.io.FSWriteError: java.io.IOException: Rename from
build\test\cassandra\commitlog\CommitLog-4-1401742823192.log to 1401742823195
failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:178)
~[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManager$4.call(CommitLogSegmentManager.java:363)
~[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManager$4.call(CommitLogSegmentManager.java:360)
~[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:148)
~[main/:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
~[main/:na]
at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_55]
Caused by: java.io.IOException: Rename from
build\test\cassandra\commitlog\CommitLog-4-1401742823192.log to 1401742823195
failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:150)
~[main/:na]
... 5 common frames omitted
{code}
Checking previous JIRA issues, I came accros
[CASSANDRA-4337|https://issues.apache.org/jira/browse/CASSANDRA-4337] which
looks similar to this issue.
I suspect that the test does not close the mmaped buffer for the renamed file.
was (Author: ala.alkhaldi):
This failure is caused by the issue reported in
[CASSANDRA-4337|https://issues.apache.org/jira/browse/CASSANDRA-4337]
RecoveryManagerTest times out on Windows
Key: CASSANDRA-7334
URL: https://issues.apache.org/jira/browse/CASSANDRA-7334
Project: Cassandra
Issue Type: Sub-task
Reporter: Joshua McKenzie
Assignee: Ala' Alkhaldi
Priority: Minor
Labels: Windows
Fix For: 3.0
Takes 11 seconds on a slow linux vm to pass, times out on Windows.
{code:title=timeout message}
[junit] Testcase:
org.apache.cassandra.db.RecoveryManagerTest:testRecoverCounter: Caused an
ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
[junit]
[junit] Test org.apache.cassandra.db.RecoveryManagerTest FAILED (timeout)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7334) RecoveryManagerTest times out on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015912#comment-14015912
]
Joshua McKenzie commented on CASSANDRA-7334:
Unit tests aren't generating a system.log for me, and an exception like that
should bubble up and report on the test failure to stdout/stderr. Maybe try
dumping a jstack every second against the running process and/or profiling the
running test (with something like jvisualvm) to try and get a clear picture of
where the test is spinning? Looks like it's pegging out a cpu during the test
so it's definitely busy doing something.
RecoveryManagerTest times out on Windows
Key: CASSANDRA-7334
URL: https://issues.apache.org/jira/browse/CASSANDRA-7334
Project: Cassandra
Issue Type: Sub-task
Reporter: Joshua McKenzie
Assignee: Ala' Alkhaldi
Priority: Minor
Labels: Windows
Fix For: 3.0
Takes 11 seconds on a slow linux vm to pass, times out on Windows.
{code:title=timeout message}
[junit] Testcase:
org.apache.cassandra.db.RecoveryManagerTest:testRecoverCounter: Caused an
ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
[junit]
[junit] Test org.apache.cassandra.db.RecoveryManagerTest FAILED (timeout)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-6788) Race condition silently kills thrift server
[ https://issues.apache.org/jira/browse/CASSANDRA-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-6788: Fix Version/s: 1.2.17 Race condition silently kills thrift server --- Key: CASSANDRA-6788 URL: https://issues.apache.org/jira/browse/CASSANDRA-6788 Project: Cassandra Issue Type: Bug Reporter: Christian Rolf Assignee: Christian Rolf Fix For: 1.2.17, 2.0.7, 2.1 beta2 Attachments: 6788-v2.txt, 6788-v3.txt, 6793-v3-rebased.txt, race_patch.diff There's a race condition in CustomTThreadPoolServer that can cause the thrift server to silently stop listening for connections. It happens when the executor service throws a RejectedExecutionException, which is not caught. Silent in the sense that OpsCenter doesn't notice any problem since JMX is still running fine. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7341) Emit a metric if there is contention in CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-7341: - Summary: Emit a metric if there is contention in CAS (was: Emit a metric if there is content in CAS) Emit a metric if there is contention in CAS --- Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Bug Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor This will be helpful to have this metric. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7341) Emit a metric if there is content in CAS
sankalp kohli created CASSANDRA-7341: Summary: Emit a metric if there is content in CAS Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Bug Reporter: sankalp kohli Priority: Minor This will be helpful to have this metric. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-7341) Emit a metric if there is content in CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli reassigned CASSANDRA-7341: Assignee: sankalp kohli Emit a metric if there is content in CAS Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Bug Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor This will be helpful to have this metric. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6539) Track metrics at a keyspace level as well as column family level
[ https://issues.apache.org/jira/browse/CASSANDRA-6539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-6539: Fix Version/s: 2.1.0 2.0.9 1.2.17 Track metrics at a keyspace level as well as column family level Key: CASSANDRA-6539 URL: https://issues.apache.org/jira/browse/CASSANDRA-6539 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Assignee: Brandon Williams Priority: Minor Labels: lhf Fix For: 1.2.17, 2.0.9, 2.1.0 Attachments: 6539-1.2.txt, 6539-2.0.txt It would be useful to be able to see aggregated metrics (write/read count/latency) at a keyspace level as well as at the individual column family level. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6926) StorageService exposes two different objects for probability tracing
[
https://issues.apache.org/jira/browse/CASSANDRA-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-6926:
---
Labels: lhf (was: )
StorageService exposes two different objects for probability tracing
Key: CASSANDRA-6926
URL: https://issues.apache.org/jira/browse/CASSANDRA-6926
Project: Cassandra
Issue Type: Bug
Reporter: Nicolas Favre-Felix
Priority: Minor
Labels: lhf
StorageServiceMBean exposes the tracing probability using two different
methods:
{code}
public void setTraceProbability(double probability);
public double getTracingProbability();
{code}
In a JMX explorer like JConsole, two objects are presented: one called
TraceProbability and the other called TracingProbability. One is read-only,
the other write-only; this is a bit confusing.
It is possible to have a single object there by having the same suffix for
both the getter and setter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CASSANDRA-6428) Use 4 bytes to encode collection size in next native protocol version
[
https://issues.apache.org/jira/browse/CASSANDRA-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura resolved CASSANDRA-6428.
Resolution: Duplicate
Use 4 bytes to encode collection size in next native protocol version
-
Key: CASSANDRA-6428
URL: https://issues.apache.org/jira/browse/CASSANDRA-6428
Project: Cassandra
Issue Type: Bug
Reporter: Jan Chochol
We are trying to use Cassandra CQL3 collections (sets and maps) for
denormalizing data.
Problem is, when size of these collections go above some limit. We found that
current limitation is 64k - 1 (65535) items in collection.
We found that there is inconsistency in CQL binary protocol (all current
available versions).
In protocol (for set) there are these fields:
{noformat}
[value size: int] [items count: short] [items] ...
{noformat}
One example in our case (collection with 65536 elements):
{noformat}
00 21 ff ee 00 00 00 20 30 30 30 30 35 63 38 69 65 33 67 37 73 61 ...
{noformat}
So decode {{value size}} is 1245166 bytes and {{items count}} is 0.
This is wrong - you can not have collection with 0 items occupying more than
1MB.
I understand that in unsigned short you can not have more than 65535, but I
do not understand why there is such limitation in protocol, when all data are
currently sent.
In this case we have several possibilities:
* ignore {{items count}} field and read all bytes specified in {{value size}}
** there is problem that we can not be sure, that this behaviour will be kept
over for future versions of Cassandra, as it is quite strange
* refactor our code to use only small collections (this seems quite odd, as
Cassandra has no problems with wide rows)
* do not use collections, and fall-back to net wide rows
* wait for change in protocol for removing unnecessary limitation
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7340) CqlRecordWriter doesn't have user/password authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-7340: Attachment: 7340.txt CqlRecordWriter doesn't have user/password authentication - Key: CASSANDRA-7340 URL: https://issues.apache.org/jira/browse/CASSANDRA-7340 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Alex Liu Assignee: Alex Liu Fix For: 2.0.9 Attachments: 7340.txt CqlRecordWriter doesn't create Cassandra client based on cassandra.output.keyspace.username and cassandra.output.keyspace.passwd setting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7340) CqlRecordWriter doesn't have user/password authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-7340: Attachment: (was: 7340.tx) CqlRecordWriter doesn't have user/password authentication - Key: CASSANDRA-7340 URL: https://issues.apache.org/jira/browse/CASSANDRA-7340 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Alex Liu Assignee: Alex Liu Fix For: 2.0.9 Attachments: 7340.txt CqlRecordWriter doesn't create Cassandra client based on cassandra.output.keyspace.username and cassandra.output.keyspace.passwd setting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7340) CqlRecordWriter doesn't have user/password authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-7340: Attachment: 7340.tx CqlRecordWriter doesn't have user/password authentication - Key: CASSANDRA-7340 URL: https://issues.apache.org/jira/browse/CASSANDRA-7340 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Alex Liu Assignee: Alex Liu Fix For: 2.0.9 Attachments: 7340.txt CqlRecordWriter doesn't create Cassandra client based on cassandra.output.keyspace.username and cassandra.output.keyspace.passwd setting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7340) CqlRecordWriter doesn't have user/password authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-7340: Attachment: 7340.txt CqlRecordWriter doesn't have user/password authentication - Key: CASSANDRA-7340 URL: https://issues.apache.org/jira/browse/CASSANDRA-7340 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Alex Liu Assignee: Alex Liu Fix For: 2.0.9 Attachments: 7340.txt CqlRecordWriter doesn't create Cassandra client based on cassandra.output.keyspace.username and cassandra.output.keyspace.passwd setting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7340) CqlRecordWriter doesn't have user/password authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-7340: Attachment: (was: 7340.txt) CqlRecordWriter doesn't have user/password authentication - Key: CASSANDRA-7340 URL: https://issues.apache.org/jira/browse/CASSANDRA-7340 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Alex Liu Assignee: Alex Liu Fix For: 2.0.9 Attachments: 7340.txt CqlRecordWriter doesn't create Cassandra client based on cassandra.output.keyspace.username and cassandra.output.keyspace.passwd setting. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7341) Emit a metric related to CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-7341: - Summary: Emit a metric related to CAS (was: Emit a metric if there is contention in CAS) Emit a metric related to CAS Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Bug Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor This will be helpful to have this metric. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-7341: - Description: We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. (was: This will be helpful to have this metric. ) Summary: Emit metrics related to CAS/Paxos (was: Emit a metric related to CAS) Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Bug Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3
[ https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015969#comment-14015969 ] Jason Brown commented on CASSANDRA-7245: will give it a shot this afternoon - thanks! Out-of-Order keys with stress + CQL3 Key: CASSANDRA-7245 URL: https://issues.apache.org/jira/browse/CASSANDRA-7245 Project: Cassandra Issue Type: Bug Components: Core Reporter: Pavel Yaskevich Assignee: T Jake Luciani Fix For: 2.1.0 Attachments: 7245-v2.txt, 7245.txt, 7245v3.txt, netty-all-4.0.19.Final.jar We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 and found following problem almost in every SSTable generated (~200 GB of data and 821 SSTables). We set up they keys to be 10 bytes in size (default) and population between 1 and 6. Once I ran 'sstablekeys' on the generated SSTable files I got following exceptions: _There is a problem with sorting of normal looking keys:_ 30303039443538353645 30303039443745364242 java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, *30303039443745364242*) DecoratedKey(-1767746583617597213, *30303039443437454333*) 0a30303033343933 3734441388343933 java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, *3734441388343933*) DecoratedKey(-7565486415339257200, *30303033344639443137*) 30303033354244363031 30303033354133423742 java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, *30303033354133423742*) DecoratedKey(-7838239767410066684, *30303033354145344534*) 30303034313442354137 3034313635363334 java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, *3034313635363334*) DecoratedKey(-9106177395653818217, *3030303431444238*) 30303035373044373435 30303035373044334631 java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, *30303035373044334631*) DecoratedKey(-4296696226469000945, *30303035373132364138*) _And completely different ones:_ 30303041333745373543 7cd045c59a90d7587d8d java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, *7cd045c59a90d7587d8d*) DecoratedKey(-5146766422778260690, *30303041333943303232*) 3030303332314144 30303033323346343932 java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, *30303033323346343932*) DecoratedKey(5233296131921119414, *53d83e0012287e03*) 30303034314531374431 3806734b256c27e41ec2 java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, *3806734b256c27e41ec2*) DecoratedKey(-8072288379146044663, *30303034314136413343*) _And sometimes there is no problem at all:_ 30303033353144463637 002a31b3b31a1c2f 5d616dd38211ebb5d6ec 444236451388 1388138844463744 30303033353143394343 It's worth to mention that we have got 22 timeout exceptions but number of out-of-order keys is much larger than that. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015976#comment-14015976
]
Jason Brown commented on CASSANDRA-7245:
[~tjake] can you rebase? the v3 patch didn't apply cleanly:
{code}
$ git apply ../patches/reviews/7245v3.txt
error: patch failed: src/java/org/apache/cassandra/service/StorageProxy.java:780
error: src/java/org/apache/cassandra/service/StorageProxy.java: patch does not
apply
error: patch failed: src/java/org/apache/cassandra/transport/Frame.java:199
error: src/java/org/apache/cassandra/transport/Frame.java: patch does not apply
{code}
Out-of-Order keys with stress + CQL3
Key: CASSANDRA-7245
URL: https://issues.apache.org/jira/browse/CASSANDRA-7245
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Pavel Yaskevich
Assignee: T Jake Luciani
Fix For: 2.1.0
Attachments: 7245-v2.txt, 7245.txt, 7245v3.txt,
netty-all-4.0.19.Final.jar
We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718
and found following problem almost in every SSTable generated (~200 GB of
data and 821 SSTables).
We set up they keys to be 10 bytes in size (default) and population between 1
and 6.
Once I ran 'sstablekeys' on the generated SSTable files I got following
exceptions:
_There is a problem with sorting of normal looking keys:_
30303039443538353645
30303039443745364242
java.io.IOException: Key out of order! DecoratedKey(-217680888487824985,
*30303039443745364242*) DecoratedKey(-1767746583617597213,
*30303039443437454333*)
0a30303033343933
3734441388343933
java.io.IOException: Key out of order! DecoratedKey(5440473860101999581,
*3734441388343933*) DecoratedKey(-7565486415339257200,
*30303033344639443137*)
30303033354244363031
30303033354133423742
java.io.IOException: Key out of order! DecoratedKey(2687072396429900180,
*30303033354133423742*) DecoratedKey(-7838239767410066684,
*30303033354145344534*)
30303034313442354137
3034313635363334
java.io.IOException: Key out of order! DecoratedKey(1516003874415400462,
*3034313635363334*) DecoratedKey(-9106177395653818217,
*3030303431444238*)
30303035373044373435
30303035373044334631
java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540,
*30303035373044334631*) DecoratedKey(-4296696226469000945,
*30303035373132364138*)
_And completely different ones:_
30303041333745373543
7cd045c59a90d7587d8d
java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196,
*7cd045c59a90d7587d8d*) DecoratedKey(-5146766422778260690,
*30303041333943303232*)
3030303332314144
30303033323346343932
java.io.IOException: Key out of order! DecoratedKey(7071845511166615635,
*30303033323346343932*) DecoratedKey(5233296131921119414,
*53d83e0012287e03*)
30303034314531374431
3806734b256c27e41ec2
java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193,
*3806734b256c27e41ec2*) DecoratedKey(-8072288379146044663,
*30303034314136413343*)
_And sometimes there is no problem at all:_
30303033353144463637
002a31b3b31a1c2f
5d616dd38211ebb5d6ec
444236451388
1388138844463744
30303033353143394343
It's worth to mention that we have got 22 timeout exceptions but number of
out-of-order keys is much larger than that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7330) Infinite loop in StreamReader.read during exception condition while running repair
[
https://issues.apache.org/jira/browse/CASSANDRA-7330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015989#comment-14015989
]
Joshua McKenzie commented on CASSANDRA-7330:
After rebasing CASSANDRA-3569 to trunk and applying this patch I was unable to
reproduce the assertion; it looks like CASSANDRA-7262 cleared this problem up.
Prior to StreamSession.closeSession() being idempotent, multiple calls to
StreamReceiveTask.abort() were being processed leading to duplicate frees and
the assertion in Memory.java.
Infinite loop in StreamReader.read during exception condition while running
repair
--
Key: CASSANDRA-7330
URL: https://issues.apache.org/jira/browse/CASSANDRA-7330
Project: Cassandra
Issue Type: Bug
Environment: 2.0.8+
Reporter: Joshua McKenzie
Assignee: Joshua McKenzie
Priority: Minor
Labels: Core
Fix For: 2.0.9
Attachments: 7330_v1.txt
InputStream.skip is returning -1 during exception conditions which leads the
following logic to infinite loop:
{code:title=loop}
protected void drain(InputStream dis, long bytesRead) throws IOException
{
long toSkip = totalSize() - bytesRead;
toSkip = toSkip - dis.skip(toSkip);
while (toSkip 0)
toSkip = toSkip - dis.skip(toSkip);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7341) Emit metrics related to CAS/Paxos
[ https://issues.apache.org/jira/browse/CASSANDRA-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-7341: - Issue Type: Improvement (was: Bug) Emit metrics related to CAS/Paxos - Key: CASSANDRA-7341 URL: https://issues.apache.org/jira/browse/CASSANDRA-7341 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor We can emit metrics based on Paxos. One of them is when there is contention. I will add more metric in this JIRA if it is helpful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7342) CAS writes does not have hint functionality.
sankalp kohli created CASSANDRA-7342: Summary: CAS writes does not have hint functionality. Key: CASSANDRA-7342 URL: https://issues.apache.org/jira/browse/CASSANDRA-7342 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli When a dead node comes up, it gets the last commit but not anything which it has missed. This reduces the durability of those writes compared to other writes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6968) Reduce Unit Test Times Due to Schema Loading
[
https://issues.apache.org/jira/browse/CASSANDRA-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016051#comment-14016051
]
Benedict commented on CASSANDRA-6968:
-
This is a bit big for a patch file (469Kb!). Could we get it as a repository?
Reduce Unit Test Times Due to Schema Loading
Key: CASSANDRA-6968
URL: https://issues.apache.org/jira/browse/CASSANDRA-6968
Project: Cassandra
Issue Type: Test
Components: Tests
Reporter: Tyler Hobbs
Assignee: Lyuben Todorov
Priority: Minor
Fix For: 2.1.1
Attachments: trunk-6968-speedup-unittests.patch
Unit tests which extend SchemaLoader take about 6s longer to run than the
others, on average. We could greatly reduce the time it takes to run the
tests by improving this.
None of the tests require everything that SchemaLoader does. We should
change SchemaLoader into a set of test utilities that are run as needed in
{{\@BeforeClass}} and {{\@AfterClass}} methods. Additionally, instead of
running a full cleanup, most tests could simply use a keyspace or column
family with a unique name (class/method name or perhaps class/method name +
timestamp).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6968) Reduce Unit Test Times Due to Schema Loading
[
https://issues.apache.org/jira/browse/CASSANDRA-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016076#comment-14016076
]
Lyuben Todorov commented on CASSANDRA-6968:
---
Though It'd be simpler to just apply but it complicates review. Pushed a branch
to
[a5c4ade|https://github.com/lyubent/cassandra/commit/a5c4ade69b1bb0d2b0dd0b647c3f1c9c97ed133a].
Reduce Unit Test Times Due to Schema Loading
Key: CASSANDRA-6968
URL: https://issues.apache.org/jira/browse/CASSANDRA-6968
Project: Cassandra
Issue Type: Test
Components: Tests
Reporter: Tyler Hobbs
Assignee: Lyuben Todorov
Priority: Minor
Fix For: 2.1.1
Attachments: trunk-6968-speedup-unittests.patch
Unit tests which extend SchemaLoader take about 6s longer to run than the
others, on average. We could greatly reduce the time it takes to run the
tests by improving this.
None of the tests require everything that SchemaLoader does. We should
change SchemaLoader into a set of test utilities that are run as needed in
{{\@BeforeClass}} and {{\@AfterClass}} methods. Additionally, instead of
running a full cleanup, most tests could simply use a keyspace or column
family with a unique name (class/method name or perhaps class/method name +
timestamp).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7245) Out-of-Order keys with stress + CQL3
[ https://issues.apache.org/jira/browse/CASSANDRA-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-7245: -- Attachment: 7245v3-rebase.txt attached v3 rebase Out-of-Order keys with stress + CQL3 Key: CASSANDRA-7245 URL: https://issues.apache.org/jira/browse/CASSANDRA-7245 Project: Cassandra Issue Type: Bug Components: Core Reporter: Pavel Yaskevich Assignee: T Jake Luciani Fix For: 2.1.0 Attachments: 7245-v2.txt, 7245.txt, 7245v3-rebase.txt, 7245v3.txt, netty-all-4.0.19.Final.jar We have been generating data (stress with CQL3 prepared) for CASSANDRA-4718 and found following problem almost in every SSTable generated (~200 GB of data and 821 SSTables). We set up they keys to be 10 bytes in size (default) and population between 1 and 6. Once I ran 'sstablekeys' on the generated SSTable files I got following exceptions: _There is a problem with sorting of normal looking keys:_ 30303039443538353645 30303039443745364242 java.io.IOException: Key out of order! DecoratedKey(-217680888487824985, *30303039443745364242*) DecoratedKey(-1767746583617597213, *30303039443437454333*) 0a30303033343933 3734441388343933 java.io.IOException: Key out of order! DecoratedKey(5440473860101999581, *3734441388343933*) DecoratedKey(-7565486415339257200, *30303033344639443137*) 30303033354244363031 30303033354133423742 java.io.IOException: Key out of order! DecoratedKey(2687072396429900180, *30303033354133423742*) DecoratedKey(-7838239767410066684, *30303033354145344534*) 30303034313442354137 3034313635363334 java.io.IOException: Key out of order! DecoratedKey(1516003874415400462, *3034313635363334*) DecoratedKey(-9106177395653818217, *3030303431444238*) 30303035373044373435 30303035373044334631 java.io.IOException: Key out of order! DecoratedKey(-3645715702154616540, *30303035373044334631*) DecoratedKey(-4296696226469000945, *30303035373132364138*) _And completely different ones:_ 30303041333745373543 7cd045c59a90d7587d8d java.io.IOException: Key out of order! DecoratedKey(-3595402345023230196, *7cd045c59a90d7587d8d*) DecoratedKey(-5146766422778260690, *30303041333943303232*) 3030303332314144 30303033323346343932 java.io.IOException: Key out of order! DecoratedKey(7071845511166615635, *30303033323346343932*) DecoratedKey(5233296131921119414, *53d83e0012287e03*) 30303034314531374431 3806734b256c27e41ec2 java.io.IOException: Key out of order! DecoratedKey(-7720474642702543193, *3806734b256c27e41ec2*) DecoratedKey(-8072288379146044663, *30303034314136413343*) _And sometimes there is no problem at all:_ 30303033353144463637 002a31b3b31a1c2f 5d616dd38211ebb5d6ec 444236451388 1388138844463744 30303033353143394343 It's worth to mention that we have got 22 timeout exceptions but number of out-of-order keys is much larger than that. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7334) RecoveryManagerTest times out on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016091#comment-14016091
]
Ala' Alkhaldi commented on CASSANDRA-7334:
--
The test loops infinitely inside CommitLogSegmentManager.resetUnsafe() because
segmentManagementTasks stays nonempty.
Explanation:
# _resetUnsafe()_ clears the list of active and available sigments without
closing thier mmaped buffers.
# Then, when the CommitLog.recover() is called, it tries to recycle the
segments which leads to FSWriteError inside CommitLogSegment().
# This error is not caught in CommitLogSegmentManager() , where the tasks are
executed, which leads to existing the run loop for the manager thread. This
loop is responsible of consuming the tasks in segmentManagementTasks
# segmentManagementTasks stays nonempty and
CommitLogSegmentManager.resetUnsafe() loops infinitely when it is called in the
next time.
Solution:
Close the segments' buffers during resetUnsafe(). The batch is attached.
Notes:
# resetUnsafe() is used by multiple tests. all of them are tested to be run
successfully on Windows ( I will test them on linux later today ).
# resetUnsafe() is supposed to be used only by testing code. However, it is
used in SchemaLoader.cleanupAndLeaveDirs()
# FSWriteError thrown by CommitLogSegment() is not caught in
CommitLogSegmentManager() and many other places which led not to detect the
failure of this issue. Is this the intended behavior?
RecoveryManagerTest times out on Windows
Key: CASSANDRA-7334
URL: https://issues.apache.org/jira/browse/CASSANDRA-7334
Project: Cassandra
Issue Type: Sub-task
Reporter: Joshua McKenzie
Assignee: Ala' Alkhaldi
Priority: Minor
Labels: Windows
Fix For: 3.0
Takes 11 seconds on a slow linux vm to pass, times out on Windows.
{code:title=timeout message}
[junit] Testcase:
org.apache.cassandra.db.RecoveryManagerTest:testRecoverCounter: Caused an
ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
[junit]
[junit] Test org.apache.cassandra.db.RecoveryManagerTest FAILED (timeout)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7334) RecoveryManagerTest times out on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ala' Alkhaldi updated CASSANDRA-7334:
-
Attachment: CASSANDRA-7334.diff
Cassandra-7334 fix
RecoveryManagerTest times out on Windows
Key: CASSANDRA-7334
URL: https://issues.apache.org/jira/browse/CASSANDRA-7334
Project: Cassandra
Issue Type: Sub-task
Reporter: Joshua McKenzie
Assignee: Ala' Alkhaldi
Priority: Minor
Labels: Windows
Fix For: 3.0
Attachments: CASSANDRA-7334.diff
Takes 11 seconds on a slow linux vm to pass, times out on Windows.
{code:title=timeout message}
[junit] Testcase:
org.apache.cassandra.db.RecoveryManagerTest:testRecoverCounter: Caused an
ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
[junit]
[junit] Test org.apache.cassandra.db.RecoveryManagerTest FAILED (timeout)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7343) CAS contention back off time should be configurable
sankalp kohli created CASSANDRA-7343: Summary: CAS contention back off time should be configurable Key: CASSANDRA-7343 URL: https://issues.apache.org/jira/browse/CASSANDRA-7343 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Priority: Minor We are currently making the contention call sleep for upto 100 millis. This is not ideal for all situations specially if you are doing LOCAL_SERIAL. This value should be configurable based on CL. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Issue Comment Deleted] (CASSANDRA-7334) RecoveryManagerTest times out on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ala' Alkhaldi updated CASSANDRA-7334:
-
Comment: was deleted
(was: Cassandra-7334 fix)
RecoveryManagerTest times out on Windows
Key: CASSANDRA-7334
URL: https://issues.apache.org/jira/browse/CASSANDRA-7334
Project: Cassandra
Issue Type: Sub-task
Reporter: Joshua McKenzie
Assignee: Ala' Alkhaldi
Priority: Minor
Labels: Windows
Fix For: 3.0
Attachments: CASSANDRA-7334.diff
Takes 11 seconds on a slow linux vm to pass, times out on Windows.
{code:title=timeout message}
[junit] Testcase:
org.apache.cassandra.db.RecoveryManagerTest:testRecoverCounter: Caused an
ERROR
[junit] Timeout occurred. Please note the time in the report does not
reflect the time until the timeout.
[junit] junit.framework.AssertionFailedError: Timeout occurred. Please
note the time in the report does not reflect the time until the timeout.
[junit]
[junit]
[junit] Test org.apache.cassandra.db.RecoveryManagerTest FAILED (timeout)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CASSANDRA-7343) CAS contention back off time should be configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli reassigned CASSANDRA-7343: Assignee: sankalp kohli CAS contention back off time should be configurable Key: CASSANDRA-7343 URL: https://issues.apache.org/jira/browse/CASSANDRA-7343 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor We are currently making the contention call sleep for upto 100 millis. This is not ideal for all situations specially if you are doing LOCAL_SERIAL. This value should be configurable based on CL. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-7344) Read at SERIAL can lead to unnecessary contention
[ https://issues.apache.org/jira/browse/CASSANDRA-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli reassigned CASSANDRA-7344: Assignee: sankalp kohli Read at SERIAL can lead to unnecessary contention -- Key: CASSANDRA-7344 URL: https://issues.apache.org/jira/browse/CASSANDRA-7344 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor If two clients are doing a read at serial on the same row, it does a full prepare step to figure out whether there is any updates or cas in flight or uncompleted. This can cause contention between then leading to waste of time in retrying. One of the request will not get a promise and will need to sleep. Instead they can check whether there is anything to finish and if not continue. If there is something to be done, then they can do the full prepare. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7344) Read at SERIAL can lead to unnecessary contention
sankalp kohli created CASSANDRA-7344: Summary: Read at SERIAL can lead to unnecessary contention Key: CASSANDRA-7344 URL: https://issues.apache.org/jira/browse/CASSANDRA-7344 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Priority: Minor If two clients are doing a read at serial on the same row, it does a full prepare step to figure out whether there is any updates or cas in flight or uncompleted. This can cause contention between then leading to waste of time in retrying. One of the request will not get a promise and will need to sleep. Instead they can check whether there is anything to finish and if not continue. If there is something to be done, then they can do the full prepare. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7344) Read at SERIAL can lead to unnecessary contention
[ https://issues.apache.org/jira/browse/CASSANDRA-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016107#comment-14016107 ] sankalp kohli commented on CASSANDRA-7344: -- [~slebresne] This can be an optimization right? Read at SERIAL can lead to unnecessary contention -- Key: CASSANDRA-7344 URL: https://issues.apache.org/jira/browse/CASSANDRA-7344 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor If two clients are doing a read at serial on the same row, it does a full prepare step to figure out whether there is any updates or cas in flight or uncompleted. This can cause contention between then leading to waste of time in retrying. One of the request will not get a promise and will need to sleep. Instead they can check whether there is anything to finish and if not continue. If there is something to be done, then they can do the full prepare. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-7345) Unfinished or inflight CAS are always done at QUORUM
[ https://issues.apache.org/jira/browse/CASSANDRA-7345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli reassigned CASSANDRA-7345: Assignee: sankalp kohli Unfinished or inflight CAS are always done at QUORUM Key: CASSANDRA-7345 URL: https://issues.apache.org/jira/browse/CASSANDRA-7345 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor The problem here is that we don't know which consistency level was used to perform the operation. We might want to store this in paxos cf or use the consistency level of the current call. This is important because calls being done at LOCAL_SERIAL will become slow. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7345) Unfinished or inflight CAS are always done at QUORUM
sankalp kohli created CASSANDRA-7345: Summary: Unfinished or inflight CAS are always done at QUORUM Key: CASSANDRA-7345 URL: https://issues.apache.org/jira/browse/CASSANDRA-7345 Project: Cassandra Issue Type: Improvement Reporter: sankalp kohli Priority: Minor The problem here is that we don't know which consistency level was used to perform the operation. We might want to store this in paxos cf or use the consistency level of the current call. This is important because calls being done at LOCAL_SERIAL will become slow. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7144) CassandraDaemon RowMutation exception
[
https://issues.apache.org/jira/browse/CASSANDRA-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016182#comment-14016182
]
sankalp kohli commented on CASSANDRA-7144:
--
Another point here is that one of these assertion errors which is caused in at
OutboundTcpConnection.java:151 will cause that thread to die.
This will be very bad as it will not be recreated and it won't be able to talk
to a node which had that connection.
CassandraDaemon RowMutation exception
-
Key: CASSANDRA-7144
URL: https://issues.apache.org/jira/browse/CASSANDRA-7144
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Ubuntu 12.04 w/ Oracle JVM, 5 nodes cluster. Nodes 2GB /
2 Cores in DigitalOcean.
Reporter: Maxime Lamothe-Brassard
Assignee: Tyler Hobbs
First time reporting a bug here, apologies if I'm not posting it in the right
space.
At what seems like random interval, on random nodes in random situations I
will get the following exception. After this the hinted handoff start timing
out and the node stops participating in the cluster.
I started seeing these after switching to the Cassandra Python-Driver from
the Python-CQL driver.
{noformat}
ERROR [WRITE-/10.128.180.108] 2014-05-03 13:45:12,843 CassandraDaemon.java
(line 198) Exception in thread Thread[WRITE-/10.128.180.108,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:271)
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:259)
at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:120)
at
org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:251)
at
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:203)
at
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:151)
ERROR [WRITE-/10.128.194.70] 2014-05-03 13:45:12,843 CassandraDaemon.java
(line 198) Exception in thread Thread[WRITE-/10.128.194.70,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:271)
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:259)
at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:120)
at
org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:251)
at
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:203)
at
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:151)
ERROR [MutationStage:118] 2014-05-03 13:45:15,048 CassandraDaemon.java (line
198) Exception in thread Thread[MutationStage:118,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:271)
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:259)
at
org.apache.cassandra.utils.FBUtilities.serialize(FBUtilities.java:654)
at
org.apache.cassandra.db.HintedHandOffManager.hintFor(HintedHandOffManager.java:137)
at
org.apache.cassandra.service.StorageProxy.writeHintForMutation(StorageProxy.java:908)
at
org.apache.cassandra.service.StorageProxy$6.runMayThrow(StorageProxy.java:881)
at
org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:1981)
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)
ERROR [MutationStage:117] 2014-05-03 13:45:15,048 CassandraDaemon.java (line
198) Exception in thread Thread[MutationStage:117,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:271)
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:259)
at
org.apache.cassandra.utils.FBUtilities.serialize(FBUtilities.java:654)
at
org.apache.cassandra.db.HintedHandOffManager.hintFor(HintedHandOffManager.java:137)
at
org.apache.cassandra.service.StorageProxy.writeHintForMutation(StorageProxy.java:908)
at
org.apache.cassandra.service.StorageProxy$6.runMayThrow(StorageProxy.java:881)
at
org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:1981)
at
git commit: remove incorrect use of generics in non-generified method call
Repository: cassandra Updated Branches: refs/heads/cassandra-2.0 709b9fc31 - 62d9c4367 remove incorrect use of generics in non-generified method call Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/62d9c436 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/62d9c436 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/62d9c436 Branch: refs/heads/cassandra-2.0 Commit: 62d9c43676c5bf33d145e4d55d25ebd9bcf1caf7 Parents: 709b9fc Author: Dave Brosius dbros...@mebigfatguy.com Authored: Mon Jun 2 23:36:21 2014 -0400 Committer: Dave Brosius dbros...@mebigfatguy.com Committed: Mon Jun 2 23:36:21 2014 -0400 -- src/java/org/apache/cassandra/service/FileCacheService.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/62d9c436/src/java/org/apache/cassandra/service/FileCacheService.java -- diff --git a/src/java/org/apache/cassandra/service/FileCacheService.java b/src/java/org/apache/cassandra/service/FileCacheService.java index d22763b..faa53f0 100644 --- a/src/java/org/apache/cassandra/service/FileCacheService.java +++ b/src/java/org/apache/cassandra/service/FileCacheService.java @@ -77,7 +77,7 @@ public class FileCacheService } }; -cache = CacheBuilder.String, QueueRandomAccessReadernewBuilder() +cache = CacheBuilder.newBuilder() .expireAfterAccess(AFTER_ACCESS_EXPIRATION, TimeUnit.MILLISECONDS) .concurrencyLevel(DatabaseDescriptor.getConcurrentReaders()) .removalListener(onRemove)
[1/2] git commit: remove incorrect use of generics in non-generified method call
Repository: cassandra Updated Branches: refs/heads/cassandra-2.1 e398c6bb8 - a89951283 remove incorrect use of generics in non-generified method call Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/62d9c436 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/62d9c436 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/62d9c436 Branch: refs/heads/cassandra-2.1 Commit: 62d9c43676c5bf33d145e4d55d25ebd9bcf1caf7 Parents: 709b9fc Author: Dave Brosius dbros...@mebigfatguy.com Authored: Mon Jun 2 23:36:21 2014 -0400 Committer: Dave Brosius dbros...@mebigfatguy.com Committed: Mon Jun 2 23:36:21 2014 -0400 -- src/java/org/apache/cassandra/service/FileCacheService.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/62d9c436/src/java/org/apache/cassandra/service/FileCacheService.java -- diff --git a/src/java/org/apache/cassandra/service/FileCacheService.java b/src/java/org/apache/cassandra/service/FileCacheService.java index d22763b..faa53f0 100644 --- a/src/java/org/apache/cassandra/service/FileCacheService.java +++ b/src/java/org/apache/cassandra/service/FileCacheService.java @@ -77,7 +77,7 @@ public class FileCacheService } }; -cache = CacheBuilder.String, QueueRandomAccessReadernewBuilder() +cache = CacheBuilder.newBuilder() .expireAfterAccess(AFTER_ACCESS_EXPIRATION, TimeUnit.MILLISECONDS) .concurrencyLevel(DatabaseDescriptor.getConcurrentReaders()) .removalListener(onRemove)
[1/3] git commit: remove incorrect use of generics in non-generified method call
Repository: cassandra Updated Branches: refs/heads/trunk d66022392 - 616c019ae remove incorrect use of generics in non-generified method call Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/62d9c436 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/62d9c436 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/62d9c436 Branch: refs/heads/trunk Commit: 62d9c43676c5bf33d145e4d55d25ebd9bcf1caf7 Parents: 709b9fc Author: Dave Brosius dbros...@mebigfatguy.com Authored: Mon Jun 2 23:36:21 2014 -0400 Committer: Dave Brosius dbros...@mebigfatguy.com Committed: Mon Jun 2 23:36:21 2014 -0400 -- src/java/org/apache/cassandra/service/FileCacheService.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/62d9c436/src/java/org/apache/cassandra/service/FileCacheService.java -- diff --git a/src/java/org/apache/cassandra/service/FileCacheService.java b/src/java/org/apache/cassandra/service/FileCacheService.java index d22763b..faa53f0 100644 --- a/src/java/org/apache/cassandra/service/FileCacheService.java +++ b/src/java/org/apache/cassandra/service/FileCacheService.java @@ -77,7 +77,7 @@ public class FileCacheService } }; -cache = CacheBuilder.String, QueueRandomAccessReadernewBuilder() +cache = CacheBuilder.newBuilder() .expireAfterAccess(AFTER_ACCESS_EXPIRATION, TimeUnit.MILLISECONDS) .concurrencyLevel(DatabaseDescriptor.getConcurrentReaders()) .removalListener(onRemove)
[3/3] 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/616c019a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/616c019a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/616c019a Branch: refs/heads/trunk Commit: 616c019aea3d24ed21fcb48290cf79b7d4f60106 Parents: d660223 a899512 Author: Dave Brosius dbros...@mebigfatguy.com Authored: Mon Jun 2 23:37:28 2014 -0400 Committer: Dave Brosius dbros...@mebigfatguy.com Committed: Mon Jun 2 23:37:28 2014 -0400 -- src/java/org/apache/cassandra/service/FileCacheService.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --
[2/3] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a8995128 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a8995128 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a8995128 Branch: refs/heads/trunk Commit: a8995128374a077172eb8c57094da68ee9ff0366 Parents: e398c6b 62d9c43 Author: Dave Brosius dbros...@mebigfatguy.com Authored: Mon Jun 2 23:36:55 2014 -0400 Committer: Dave Brosius dbros...@mebigfatguy.com Committed: Mon Jun 2 23:36:55 2014 -0400 -- src/java/org/apache/cassandra/service/FileCacheService.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a8995128/src/java/org/apache/cassandra/service/FileCacheService.java --
[2/2] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a8995128 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a8995128 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a8995128 Branch: refs/heads/cassandra-2.1 Commit: a8995128374a077172eb8c57094da68ee9ff0366 Parents: e398c6b 62d9c43 Author: Dave Brosius dbros...@mebigfatguy.com Authored: Mon Jun 2 23:36:55 2014 -0400 Committer: Dave Brosius dbros...@mebigfatguy.com Committed: Mon Jun 2 23:36:55 2014 -0400 -- src/java/org/apache/cassandra/service/FileCacheService.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a8995128/src/java/org/apache/cassandra/service/FileCacheService.java --
git commit: make NoOp's constructor private as it's a singleton
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 a89951283 - 371507a12
make NoOp's constructor private as it's a singleton
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/371507a1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/371507a1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/371507a1
Branch: refs/heads/cassandra-2.1
Commit: 371507a121209ceb8d3d6774f36cbb34175d4347
Parents: a899512
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Tue Jun 3 00:01:11 2014 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Tue Jun 3 00:01:11 2014 -0400
--
src/java/org/apache/cassandra/utils/btree/UpdateFunction.java | 4
1 file changed, 4 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/371507a1/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
--
diff --git a/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
b/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
index 355028e..9f45031 100644
--- a/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
+++ b/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
@@ -52,6 +52,10 @@ public interface UpdateFunctionV extends FunctionV, V
{
return INSTANCE;
}
+
+private NoOp()
+{
+}
public V apply(V replacing, V update)
{
[1/2] git commit: make NoOp's constructor private as it's a singleton
Repository: cassandra
Updated Branches:
refs/heads/trunk 616c019ae - ac8d3c174
make NoOp's constructor private as it's a singleton
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/371507a1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/371507a1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/371507a1
Branch: refs/heads/trunk
Commit: 371507a121209ceb8d3d6774f36cbb34175d4347
Parents: a899512
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Tue Jun 3 00:01:11 2014 -0400
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Tue Jun 3 00:01:11 2014 -0400
--
src/java/org/apache/cassandra/utils/btree/UpdateFunction.java | 4
1 file changed, 4 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/371507a1/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
--
diff --git a/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
b/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
index 355028e..9f45031 100644
--- a/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
+++ b/src/java/org/apache/cassandra/utils/btree/UpdateFunction.java
@@ -52,6 +52,10 @@ public interface UpdateFunctionV extends FunctionV, V
{
return INSTANCE;
}
+
+private NoOp()
+{
+}
public V apply(V replacing, V update)
{
[2/2] 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/ac8d3c17 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ac8d3c17 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ac8d3c17 Branch: refs/heads/trunk Commit: ac8d3c174be78931d5d00c6e242eeaccc1677d47 Parents: 616c019 371507a Author: Dave Brosius dbros...@mebigfatguy.com Authored: Tue Jun 3 00:01:39 2014 -0400 Committer: Dave Brosius dbros...@mebigfatguy.com Committed: Tue Jun 3 00:01:39 2014 -0400 -- src/java/org/apache/cassandra/utils/btree/UpdateFunction.java | 4 1 file changed, 4 insertions(+) --
[jira] [Commented] (CASSANDRA-7144) CassandraDaemon RowMutation exception
[
https://issues.apache.org/jira/browse/CASSANDRA-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016199#comment-14016199
]
sankalp kohli commented on CASSANDRA-7144:
--
[~nesnub] [~jason.punyon]
Are you using CAS based inserts?
CassandraDaemon RowMutation exception
-
Key: CASSANDRA-7144
URL: https://issues.apache.org/jira/browse/CASSANDRA-7144
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Ubuntu 12.04 w/ Oracle JVM, 5 nodes cluster. Nodes 2GB /
2 Cores in DigitalOcean.
Reporter: Maxime Lamothe-Brassard
Assignee: Tyler Hobbs
First time reporting a bug here, apologies if I'm not posting it in the right
space.
At what seems like random interval, on random nodes in random situations I
will get the following exception. After this the hinted handoff start timing
out and the node stops participating in the cluster.
I started seeing these after switching to the Cassandra Python-Driver from
the Python-CQL driver.
{noformat}
ERROR [WRITE-/10.128.180.108] 2014-05-03 13:45:12,843 CassandraDaemon.java
(line 198) Exception in thread Thread[WRITE-/10.128.180.108,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:271)
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:259)
at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:120)
at
org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:251)
at
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:203)
at
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:151)
ERROR [WRITE-/10.128.194.70] 2014-05-03 13:45:12,843 CassandraDaemon.java
(line 198) Exception in thread Thread[WRITE-/10.128.194.70,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:271)
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:259)
at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:120)
at
org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:251)
at
org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:203)
at
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:151)
ERROR [MutationStage:118] 2014-05-03 13:45:15,048 CassandraDaemon.java (line
198) Exception in thread Thread[MutationStage:118,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:271)
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:259)
at
org.apache.cassandra.utils.FBUtilities.serialize(FBUtilities.java:654)
at
org.apache.cassandra.db.HintedHandOffManager.hintFor(HintedHandOffManager.java:137)
at
org.apache.cassandra.service.StorageProxy.writeHintForMutation(StorageProxy.java:908)
at
org.apache.cassandra.service.StorageProxy$6.runMayThrow(StorageProxy.java:881)
at
org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:1981)
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)
ERROR [MutationStage:117] 2014-05-03 13:45:15,048 CassandraDaemon.java (line
198) Exception in thread Thread[MutationStage:117,5,main]
java.lang.AssertionError
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:271)
at
org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:259)
at
org.apache.cassandra.utils.FBUtilities.serialize(FBUtilities.java:654)
at
org.apache.cassandra.db.HintedHandOffManager.hintFor(HintedHandOffManager.java:137)
at
org.apache.cassandra.service.StorageProxy.writeHintForMutation(StorageProxy.java:908)
at
org.apache.cassandra.service.StorageProxy$6.runMayThrow(StorageProxy.java:881)
at
org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:1981)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
