svn commit: r1565567 - in /cassandra/site: publish/download/index.html publish/index.html src/settings.py
Author: slebresne
Date: Fri Feb 7 07:57:56 2014
New Revision: 1565567
URL: http://svn.apache.org/r1565567
Log:
Update website for 1.2.15 and 2.0.5 releases
Modified:
cassandra/site/publish/download/index.html
cassandra/site/publish/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=1565567&r1=1565566&r2=1565567&view=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Fri Feb 7 07:57:56 2014
@@ -49,8 +49,8 @@
Cassandra releases include the core server, the http://wiki.apache.org/cassandra/NodeTool";>nodetool administration
command-line interface, and a development shell (http://cassandra.apache.org/doc/cql/CQL.html";>cqlsh and the
old cassandra-cli).
- The latest stable release of Apache Cassandra is 2.0.4
- (released on 2013-12-30). If you're just
+ The latest stable release of Apache Cassandra is 2.0.5
+ (released on 2013-02-07). If you're just
starting out, download this one.
@@ -59,13 +59,13 @@
http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.0.4/apache-cassandra-2.0.4-bin.tar.gz";
+
href="http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.0.5/apache-cassandra-2.0.5-bin.tar.gz";
onclick="javascript:
pageTracker._trackPageview('/clicks/binary_download');">
- apache-cassandra-2.0.4-bin.tar.gz
+ apache-cassandra-2.0.5-bin.tar.gz
-[http://www.apache.org/dist/cassandra/2.0.4/apache-cassandra-2.0.4-bin.tar.gz.asc";>PGP]
-[http://www.apache.org/dist/cassandra/2.0.4/apache-cassandra-2.0.4-bin.tar.gz.md5";>MD5]
-[http://www.apache.org/dist/cassandra/2.0.4/apache-cassandra-2.0.4-bin.tar.gz.sha1";>SHA1]
+[http://www.apache.org/dist/cassandra/2.0.5/apache-cassandra-2.0.5-bin.tar.gz.asc";>PGP]
+[http://www.apache.org/dist/cassandra/2.0.5/apache-cassandra-2.0.5-bin.tar.gz.md5";>MD5]
+[http://www.apache.org/dist/cassandra/2.0.5/apache-cassandra-2.0.5-bin.tar.gz.sha1";>SHA1]
http://wiki.apache.org/cassandra/DebianPackaging";>Debian
installation instructions
@@ -102,16 +102,16 @@
Previous stable branches of Cassandra continue to see periodic maintenance
for some time after a new major release is made. The lastest release on the
- 1.2 branch is 1.2.14 (released on
- 2013-02-03).
+ 1.2 branch is 1.2.15 (released on
+ 2013-02-07).
-http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.14/apache-cassandra-1.2.14-bin.tar.gz";>apache-cassandra-1.2.14-bin.tar.gz
-[http://www.apache.org/dist/cassandra/1.2.14/apache-cassandra-1.2.14-bin.tar.gz.asc";>PGP]
-[http://www.apache.org/dist/cassandra/1.2.14/apache-cassandra-1.2.14-bin.tar.gz.md5";>MD5]
-[http://www.apache.org/dist/cassandra/1.2.14/apache-cassandra-1.2.14-bin.tar.gz.sha1";>SHA1]
+http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.15/apache-cassandra-1.2.15-bin.tar.gz";>apache-cassandra-1.2.15-bin.tar.gz
+[http://www.apache.org/dist/cassandra/1.2.15/apache-cassandra-1.2.15-bin.tar.gz.asc";>PGP]
+[http://www.apache.org/dist/cassandra/1.2.15/apache-cassandra-1.2.15-bin.tar.gz.md5";>MD5]
+[http://www.apache.org/dist/cassandra/1.2.15/apache-cassandra-1.2.15-bin.tar.gz.sha1";>SHA1]
@@ -144,20 +144,20 @@
http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.0.4/apache-cassandra-2.0.4-src.tar.gz";
+
href="http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.0.5/apache-cassandra-2.0.5-src.tar.gz";
onclick="javascript:
pageTracker._trackPageview('/clicks/source_download');">
- apache-cassandra-2.0.4-src.tar.gz
+ apache-cassandra-2.0.5-src.tar.gz
-[http://www.apache.org/dist/cassandra/2.0.4/apache-cassandra-2.0.4-src.tar.gz.asc";>PGP]
-[http://www.apache.org/dist/cassandra/2.0.4/apache-cassandra-2.0.4-src.tar.gz.md5";>MD5]
-[http://www.apache.org/dist/cassandra/2.0.4/apache-cassandra-2.0.4-src.tar.gz.sha1";>SHA1]
+[http://www.apache.org/dist/cassandra/2.0.5/apache-cassandra-2.0.5-src.tar.gz.asc";>PGP]
+[http://www.apache.org/dist/cassandra/2.0.5/apache-cassandra-2.0.5-src.tar.gz.md5";>MD5]
+[http://www.apache.org/dist/cassandra/2.0.5/apache-cassandra-2.0.5-src.tar.gz.sha1";>SHA1]
-http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.14/apache-cassandra-1.2.14-src.tar.gz";>apache-cassandra-1.2.14-src.tar.gz
-[http://www.apache.org/dist/cassandra/1.2.14/apache-cassandra-1.2.14-src.tar.gz.asc";>PGP]
-[http://www.apache.org/dist/cassandra/1.2.14/apache-cassandra-1.2.14-src.tar.gz.md5";>MD5]
-[http://www.apache.org/dist/cassandra/1.2.14/apache-cassandra-1.2.14-src.tar.gz.sha1";>SHA1]
+http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.2.15/apache-cassandra-1.2.15-src.tar.gz";>apache-cassand
Git Push Summary
Updated Tags: refs/tags/cassandra-1.2.15 [created] de8662f75
Git Push Summary
Updated Tags: refs/tags/1.2.15-tentative [deleted] 178e086f1
Git Push Summary
Updated Tags: refs/tags/2.0.5-tentative [deleted] 29670eb66
Git Push Summary
Updated Tags: refs/tags/cassandra-2.0.5 [created] 71c4e4a02
[jira] [Created] (CASSANDRA-6672) Support for Microsecond Resolution Time UUIDs in CQL3
Drew Kutcharian created CASSANDRA-6672: -- Summary: Support for Microsecond Resolution Time UUIDs in CQL3 Key: CASSANDRA-6672 URL: https://issues.apache.org/jira/browse/CASSANDRA-6672 Project: Cassandra Issue Type: Wish Components: Core Reporter: Drew Kutcharian Currently CQL3 supports time uuid based functions (now, unixtimestampof, dateof, ...) that deal with millisecond resolution time uuids. I think it will be a good idea to have the microsecond resolution version of those functions. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6657) Log the newsize value alongside the heap size at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-6657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894233#comment-13894233 ] Lyuben Todorov commented on CASSANDRA-6657: --- +1 > Log the newsize value alongside the heap size at startup > > > Key: CASSANDRA-6657 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6657 > Project: Cassandra > Issue Type: Wish > Components: Core >Reporter: Jeremy Hanna >Assignee: Brandon Williams >Priority: Trivial > Fix For: 2.0.6 > > Attachments: 6657.txt > > > It would be nice to have the newsize value logged alongside the heap size at > startup to more easily track down problems. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6622) Streaming session failures during node replace of same address
[
https://issues.apache.org/jira/browse/CASSANDRA-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ravi Prasad updated CASSANDRA-6622:
---
Summary: Streaming session failures during node replace of same address
(was: Streaming session failures during node replace using replace_address)
> Streaming session failures during node replace of same address
> --
>
> Key: CASSANDRA-6622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6622
> Project: Cassandra
> Issue Type: Bug
> Environment: RHEL6, cassandra-2.0.4
>Reporter: Ravi Prasad
>Assignee: Brandon Williams
> Attachments: 0001-don-t-signal-restart-of-dead-states.txt,
> 6622-2.0.txt, logs.tgz
>
>
> When using replace_address, Gossiper ApplicationState is set to hibernate,
> which is a down state. We are seeing that the peer nodes are seeing streaming
> plan request even before the Gossiper on them marks the replacing node as
> dead. As a result, streaming on peer nodes convicts the replacing node by
> closing the stream handler.
> I think, making the StorageService thread on the replacing node, sleep for
> BROADCAST_INTERVAL before bootstrapping, would avoid this scenario.
> Relevant logs from peer node (see that the Gossiper on peer node mark the
> replacing node as down, 2 secs after the streaming init request):
> {noformat}
> INFO [STREAM-INIT-/x.x.x.x:46436] 2014-01-26 20:42:24,388
> StreamResultFuture.java (line 116) [Stream
> #5c6cd940-86ca-11e3-90a0-411b913c0e88] Received streaming plan for Bootstrap
>
> INFO [GossipTasks:1] 2014-01-26 20:42:25,240 StreamResultFuture.java (line
> 181) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Session with /x.x.x.x is
> complete
> WARN [GossipTasks:1] 2014-01-26 20:42:25,240 StreamResultFuture.java (line
> 210) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Stream failed
> INFO [GossipStage:1] 2014-01-26 20:42:25,242 Gossiper.java (line 850)
> InetAddress /x.x.x.x is now DOWN
> ERROR [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,766 StreamSession.java (line
> 410) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Streaming error occurred
> java.lang.RuntimeException: Outgoing stream handler has been closed
> at
> org.apache.cassandra.streaming.ConnectionHandler.sendMessage(ConnectionHandler.java:175)
> at
> org.apache.cassandra.streaming.StreamSession.prepare(StreamSession.java:436)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:358)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:293)
> at java.lang.Thread.run(Thread.java:722)
> INFO [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,768 StreamResultFuture.java
> (line 181) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Session with
> /x.x.x.x is complete
> WARN [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,768 StreamResultFuture.java
> (line 210) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Stream failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (CASSANDRA-6622) Streaming session failures during node replace using replace_address
[
https://issues.apache.org/jira/browse/CASSANDRA-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894191#comment-13894191
]
Ravi Prasad edited comment on CASSANDRA-6622 at 2/7/14 5:23 AM:
bq. Can you try the patch from CASSANDRA-6658?
Didn't help. What i'm seeing is, the other nodes in the ring take around 2-3
seconds for PHI on the replacing node to drop below convict threshold. But,
they also receive the stream plan from the replacing node with in 2 seconds of
starting of replacing node.
was (Author: ravilr):
bq. Can you try the patch from CASSANDRA-6658?
Didn't help. What i'm seeing is, the other nodes in the ring take around 2-3
seconds for PHI on the replacing node to drop below convict threshold. But,
they also receive the stream plan from the replacing node with in 2 seconds of
starting of replacing node. I think this would affect normal bootstrap also,
but there we sleep for RING_DELAY already.
> Streaming session failures during node replace using replace_address
>
>
> Key: CASSANDRA-6622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6622
> Project: Cassandra
> Issue Type: Bug
> Environment: RHEL6, cassandra-2.0.4
>Reporter: Ravi Prasad
>Assignee: Brandon Williams
> Attachments: 0001-don-t-signal-restart-of-dead-states.txt,
> 6622-2.0.txt, logs.tgz
>
>
> When using replace_address, Gossiper ApplicationState is set to hibernate,
> which is a down state. We are seeing that the peer nodes are seeing streaming
> plan request even before the Gossiper on them marks the replacing node as
> dead. As a result, streaming on peer nodes convicts the replacing node by
> closing the stream handler.
> I think, making the StorageService thread on the replacing node, sleep for
> BROADCAST_INTERVAL before bootstrapping, would avoid this scenario.
> Relevant logs from peer node (see that the Gossiper on peer node mark the
> replacing node as down, 2 secs after the streaming init request):
> {noformat}
> INFO [STREAM-INIT-/x.x.x.x:46436] 2014-01-26 20:42:24,388
> StreamResultFuture.java (line 116) [Stream
> #5c6cd940-86ca-11e3-90a0-411b913c0e88] Received streaming plan for Bootstrap
>
> INFO [GossipTasks:1] 2014-01-26 20:42:25,240 StreamResultFuture.java (line
> 181) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Session with /x.x.x.x is
> complete
> WARN [GossipTasks:1] 2014-01-26 20:42:25,240 StreamResultFuture.java (line
> 210) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Stream failed
> INFO [GossipStage:1] 2014-01-26 20:42:25,242 Gossiper.java (line 850)
> InetAddress /x.x.x.x is now DOWN
> ERROR [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,766 StreamSession.java (line
> 410) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Streaming error occurred
> java.lang.RuntimeException: Outgoing stream handler has been closed
> at
> org.apache.cassandra.streaming.ConnectionHandler.sendMessage(ConnectionHandler.java:175)
> at
> org.apache.cassandra.streaming.StreamSession.prepare(StreamSession.java:436)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:358)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:293)
> at java.lang.Thread.run(Thread.java:722)
> INFO [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,768 StreamResultFuture.java
> (line 181) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Session with
> /x.x.x.x is complete
> WARN [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,768 StreamResultFuture.java
> (line 210) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Stream failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
git commit: Don't swallow useful exceptions. patch by Ding Yuan; reviewed by Mikhail Stepura for CASSANDRA-6656
Updated Branches:
refs/heads/trunk c3670e4f8 -> 7a3e697d8
Don't swallow useful exceptions.
patch by Ding Yuan; reviewed by Mikhail Stepura for CASSANDRA-6656
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7a3e697d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7a3e697d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7a3e697d
Branch: refs/heads/trunk
Commit: 7a3e697d836ca6fd7f41215678c977cb48a2ce1f
Parents: c3670e4
Author: Ding Yuan
Authored: Thu Feb 6 19:28:36 2014 -0800
Committer: Mikhail Stepura
Committed: Thu Feb 6 20:58:58 2014 -0800
--
.../db/marshal/DynamicCompositeType.java| 21 ++--
.../org/apache/cassandra/tools/NodeProbe.java | 10 --
src/java/org/apache/cassandra/utils/Hex.java| 11 ++
3 files changed, 38 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a3e697d/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
--
diff --git a/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
b/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
index 35e6e33..faa1955 100644
--- a/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
+++ b/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
@@ -22,6 +22,9 @@ import java.nio.ByteBuffer;
import java.util.HashMap;
import java.util.Map;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.exceptions.SyntaxException;
import org.apache.cassandra.serializers.TypeSerializer;
@@ -49,6 +52,8 @@ import org.apache.cassandra.utils.ByteBufferUtil;
*/
public class DynamicCompositeType extends AbstractCompositeType
{
+private static final Logger logger =
LoggerFactory.getLogger(DynamicCompositeType.class);
+
private final Map> aliases;
// interning instances
@@ -185,13 +190,25 @@ public class DynamicCompositeType extends
AbstractCompositeType
throw new MarshalException("Not enough bytes to read
comparator name of component " + i);
ByteBuffer value = getBytes(bb, header);
+String valueStr = null;
try
{
-comparator = TypeParser.parse(ByteBufferUtil.string(value));
+valueStr = ByteBufferUtil.string(value);
+comparator = TypeParser.parse(valueStr);
+}
+catch (CharacterCodingException ce)
+{
+// ByteBufferUtil.string failed.
+// Log it here and we'll further throw an exception below
since comparator == null
+logger.error("Failed with [{}] when decoding the byte buffer
in ByteBufferUtil.string()",
+ ce.toString());
}
catch (Exception e)
{
-// we'll deal with this below since comparator == null
+// parse failed.
+// Log it here and we'll further throw an exception below
since comparator == null
+logger.error("Failed to parse value string \"{}\" with
exception: [{}]",
+ valueStr, e.toString());
}
}
else
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a3e697d/src/java/org/apache/cassandra/tools/NodeProbe.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java
b/src/java/org/apache/cassandra/tools/NodeProbe.java
index d874ef0..a342866 100644
--- a/src/java/org/apache/cassandra/tools/NodeProbe.java
+++ b/src/java/org/apache/cassandra/tools/NodeProbe.java
@@ -237,7 +237,10 @@ public class NodeProbe implements AutoCloseable
ssProxy.removeNotificationListener(runner);
jmxc.removeConnectionNotificationListener(runner);
}
-catch (Throwable ignored) {}
+catch (Throwable e)
+{
+out.println("Exception occurred during clean-up. " + e);
+}
}
}
@@ -262,7 +265,10 @@ public class NodeProbe implements AutoCloseable
ssProxy.removeNotificationListener(runner);
jmxc.removeConnectionNotificationListener(runner);
}
-catch (Throwable ignored) {}
+catch (Throwable e)
+{
+out.println("Exception occurred during clean-up. " + e);
+}
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7a3e697d/src/java/org/apache/cassandra/utils/Hex.java
-
[1/2] git commit: remove dead code
Updated Branches:
refs/heads/trunk 88bef0cbf -> c3670e4f8
remove dead code
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6e0ce7a0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6e0ce7a0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6e0ce7a0
Branch: refs/heads/trunk
Commit: 6e0ce7a0507f58aab61343bdc6e8d955834cb321
Parents: ce9c8c2
Author: Dave Brosius
Authored: Thu Feb 6 23:40:32 2014 -0500
Committer: Dave Brosius
Committed: Thu Feb 6 23:40:32 2014 -0500
--
src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 3 ---
1 file changed, 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6e0ce7a0/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 535dbb3..e9d55d4 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -49,7 +49,6 @@ public class DynamicEndpointSnitch extends
AbstractEndpointSnitch implements ILa
private boolean registered = false;
private final ConcurrentHashMap scores = new
ConcurrentHashMap();
-private final ConcurrentHashMap lastReceived = new
ConcurrentHashMap();
private final ConcurrentHashMap
samples = new ConcurrentHashMap();
public final IEndpointSnitch subsnitch;
@@ -201,8 +200,6 @@ public class DynamicEndpointSnitch extends
AbstractEndpointSnitch implements ILa
public void receiveTiming(InetAddress host, long latency) // this is cheap
{
-lastReceived.put(host, System.nanoTime());
-
ExponentiallyDecayingSample sample = samples.get(host);
if (sample == null)
{
[2/2] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c3670e4f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c3670e4f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c3670e4f Branch: refs/heads/trunk Commit: c3670e4f8dc58067deb31ca4a0bb741cc8781b60 Parents: 88bef0c 6e0ce7a Author: Dave Brosius Authored: Thu Feb 6 23:42:00 2014 -0500 Committer: Dave Brosius Committed: Thu Feb 6 23:42:00 2014 -0500 -- src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 3 --- 1 file changed, 3 deletions(-) --
git commit: remove dead code
Updated Branches:
refs/heads/cassandra-2.0 ce9c8c2cd -> 6e0ce7a05
remove dead code
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6e0ce7a0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6e0ce7a0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6e0ce7a0
Branch: refs/heads/cassandra-2.0
Commit: 6e0ce7a0507f58aab61343bdc6e8d955834cb321
Parents: ce9c8c2
Author: Dave Brosius
Authored: Thu Feb 6 23:40:32 2014 -0500
Committer: Dave Brosius
Committed: Thu Feb 6 23:40:32 2014 -0500
--
src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 3 ---
1 file changed, 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6e0ce7a0/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 535dbb3..e9d55d4 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -49,7 +49,6 @@ public class DynamicEndpointSnitch extends
AbstractEndpointSnitch implements ILa
private boolean registered = false;
private final ConcurrentHashMap scores = new
ConcurrentHashMap();
-private final ConcurrentHashMap lastReceived = new
ConcurrentHashMap();
private final ConcurrentHashMap
samples = new ConcurrentHashMap();
public final IEndpointSnitch subsnitch;
@@ -201,8 +200,6 @@ public class DynamicEndpointSnitch extends
AbstractEndpointSnitch implements ILa
public void receiveTiming(InetAddress host, long latency) // this is cheap
{
-lastReceived.put(host, System.nanoTime());
-
ExponentiallyDecayingSample sample = samples.get(host);
if (sample == null)
{
[jira] [Commented] (CASSANDRA-6622) Streaming session failures during node replace using replace_address
[
https://issues.apache.org/jira/browse/CASSANDRA-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894191#comment-13894191
]
Ravi Prasad commented on CASSANDRA-6622:
bq. Can you try the patch from CASSANDRA-6658?
Didn't help. What i'm seeing is, the other nodes in the ring take around 2-3
seconds for PHI on the replacing node to drop below convict threshold. But,
they also receive the stream plan from the replacing node with in 2 seconds of
starting of replacing node. I think this would affect normal bootstrap also,
but there we sleep for RING_DELAY already.
> Streaming session failures during node replace using replace_address
>
>
> Key: CASSANDRA-6622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6622
> Project: Cassandra
> Issue Type: Bug
> Environment: RHEL6, cassandra-2.0.4
>Reporter: Ravi Prasad
>Assignee: Brandon Williams
> Attachments: 0001-don-t-signal-restart-of-dead-states.txt,
> 6622-2.0.txt, logs.tgz
>
>
> When using replace_address, Gossiper ApplicationState is set to hibernate,
> which is a down state. We are seeing that the peer nodes are seeing streaming
> plan request even before the Gossiper on them marks the replacing node as
> dead. As a result, streaming on peer nodes convicts the replacing node by
> closing the stream handler.
> I think, making the StorageService thread on the replacing node, sleep for
> BROADCAST_INTERVAL before bootstrapping, would avoid this scenario.
> Relevant logs from peer node (see that the Gossiper on peer node mark the
> replacing node as down, 2 secs after the streaming init request):
> {noformat}
> INFO [STREAM-INIT-/x.x.x.x:46436] 2014-01-26 20:42:24,388
> StreamResultFuture.java (line 116) [Stream
> #5c6cd940-86ca-11e3-90a0-411b913c0e88] Received streaming plan for Bootstrap
>
> INFO [GossipTasks:1] 2014-01-26 20:42:25,240 StreamResultFuture.java (line
> 181) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Session with /x.x.x.x is
> complete
> WARN [GossipTasks:1] 2014-01-26 20:42:25,240 StreamResultFuture.java (line
> 210) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Stream failed
> INFO [GossipStage:1] 2014-01-26 20:42:25,242 Gossiper.java (line 850)
> InetAddress /x.x.x.x is now DOWN
> ERROR [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,766 StreamSession.java (line
> 410) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Streaming error occurred
> java.lang.RuntimeException: Outgoing stream handler has been closed
> at
> org.apache.cassandra.streaming.ConnectionHandler.sendMessage(ConnectionHandler.java:175)
> at
> org.apache.cassandra.streaming.StreamSession.prepare(StreamSession.java:436)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:358)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:293)
> at java.lang.Thread.run(Thread.java:722)
> INFO [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,768 StreamResultFuture.java
> (line 181) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Session with
> /x.x.x.x is complete
> WARN [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,768 StreamResultFuture.java
> (line 210) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Stream failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
git commit: Switched to Guava 16.0 for CASSANDRA-6639
Updated Branches: refs/heads/trunk 5fe060074 -> 88bef0cbf Switched to Guava 16.0 for CASSANDRA-6639 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/88bef0cb Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/88bef0cb Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/88bef0cb Branch: refs/heads/trunk Commit: 88bef0cbf39dd5c87ca9575d47123c99b0f6e1f7 Parents: 5fe0600 Author: Mikhail Stepura Authored: Thu Jan 30 10:50:12 2014 -0800 Committer: Mikhail Stepura Committed: Thu Feb 6 20:22:28 2014 -0800 -- build.xml | 3 +- lib/guava-15.0.jar | Bin 2172168 -> 0 bytes lib/guava-16.0.jar | Bin 0 -> 2225441 bytes lib/licenses/guava-15.0.txt | 202 --- lib/licenses/guava-16.0.txt | 202 +++ .../apache/cassandra/tracing/TraceState.java| 5 +- 6 files changed, 205 insertions(+), 207 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/88bef0cb/build.xml -- diff --git a/build.xml b/build.xml index 54d6226..d36b39e 100644 --- a/build.xml +++ b/build.xml @@ -340,7 +340,7 @@ - + @@ -418,7 +418,6 @@ - http://git-wip-us.apache.org/repos/asf/cassandra/blob/88bef0cb/lib/guava-15.0.jar -- diff --git a/lib/guava-15.0.jar b/lib/guava-15.0.jar deleted file mode 100644 index eb9ef8a..000 Binary files a/lib/guava-15.0.jar and /dev/null differ http://git-wip-us.apache.org/repos/asf/cassandra/blob/88bef0cb/lib/guava-16.0.jar -- diff --git a/lib/guava-16.0.jar b/lib/guava-16.0.jar new file mode 100644 index 000..7afcb10 Binary files /dev/null and b/lib/guava-16.0.jar differ http://git-wip-us.apache.org/repos/asf/cassandra/blob/88bef0cb/lib/licenses/guava-15.0.txt -- diff --git a/lib/licenses/guava-15.0.txt b/lib/licenses/guava-15.0.txt deleted file mode 100644 index d645695..000 --- a/lib/licenses/guava-15.0.txt +++ /dev/null @@ -1,202 +0,0 @@ - - Apache License - Version 2.0, January 2004 -http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Derivative Works" shall mean any work, whether in Source or Object - form, that is based on (or derived from) the Work and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. For the purposes - of this License, Derivative Works shall not include works that remain - separable from, or merely link (or bind by name) to the interfaces of, - the Work and Derivative Works there
[jira] [Commented] (CASSANDRA-6568) sstables incorrectly getting marked as "not live"
[
https://issues.apache.org/jira/browse/CASSANDRA-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894137#comment-13894137
]
Nate McCall commented on CASSANDRA-6568:
[~krummas] I agree with Rob - that would have be hugely useful for me recently.
> sstables incorrectly getting marked as "not live"
> -
>
> Key: CASSANDRA-6568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6568
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: 1.2.12 with several 1.2.13 patches
>Reporter: Chris Burroughs
>Assignee: Marcus Eriksson
> Fix For: 1.2.15, 2.0.6
>
> Attachments: 0001-add-jmx-method-to-get-non-active-sstables.patch
>
>
> {noformat}
> -rw-rw-r-- 14 cassandra cassandra 1.4G Nov 25 19:46
> /data/sstables/data/ks/cf/ks-cf-ic-402383-Data.db
> -rw-rw-r-- 14 cassandra cassandra 13G Nov 26 00:04
> /data/sstables/data/ks/cf/ks-cf-ic-402430-Data.db
> -rw-rw-r-- 14 cassandra cassandra 13G Nov 26 05:03
> /data/sstables/data/ks/cf/ks-cf-ic-405231-Data.db
> -rw-rw-r-- 31 cassandra cassandra 21G Nov 26 08:38
> /data/sstables/data/ks/cf/ks-cf-ic-405232-Data.db
> -rw-rw-r-- 2 cassandra cassandra 2.6G Dec 3 13:44
> /data/sstables/data/ks/cf/ks-cf-ic-434662-Data.db
> -rw-rw-r-- 14 cassandra cassandra 1.5G Dec 5 09:05
> /data/sstables/data/ks/cf/ks-cf-ic-438698-Data.db
> -rw-rw-r-- 2 cassandra cassandra 3.1G Dec 6 12:10
> /data/sstables/data/ks/cf/ks-cf-ic-440983-Data.db
> -rw-rw-r-- 2 cassandra cassandra 96M Dec 8 01:52
> /data/sstables/data/ks/cf/ks-cf-ic-444041-Data.db
> -rw-rw-r-- 2 cassandra cassandra 3.3G Dec 9 16:37
> /data/sstables/data/ks/cf/ks-cf-ic-451116-Data.db
> -rw-rw-r-- 2 cassandra cassandra 876M Dec 10 11:23
> /data/sstables/data/ks/cf/ks-cf-ic-453552-Data.db
> -rw-rw-r-- 2 cassandra cassandra 891M Dec 11 03:21
> /data/sstables/data/ks/cf/ks-cf-ic-454518-Data.db
> -rw-rw-r-- 2 cassandra cassandra 102M Dec 11 12:27
> /data/sstables/data/ks/cf/ks-cf-ic-455429-Data.db
> -rw-rw-r-- 2 cassandra cassandra 906M Dec 11 23:54
> /data/sstables/data/ks/cf/ks-cf-ic-455533-Data.db
> -rw-rw-r-- 1 cassandra cassandra 214M Dec 12 05:02
> /data/sstables/data/ks/cf/ks-cf-ic-456426-Data.db
> -rw-rw-r-- 1 cassandra cassandra 203M Dec 12 10:49
> /data/sstables/data/ks/cf/ks-cf-ic-456879-Data.db
> -rw-rw-r-- 1 cassandra cassandra 49M Dec 12 12:03
> /data/sstables/data/ks/cf/ks-cf-ic-456963-Data.db
> -rw-rw-r-- 18 cassandra cassandra 20G Dec 25 01:09
> /data/sstables/data/ks/cf/ks-cf-ic-507770-Data.db
> -rw-rw-r-- 3 cassandra cassandra 12G Jan 8 04:22
> /data/sstables/data/ks/cf/ks-cf-ic-567100-Data.db
> -rw-rw-r-- 3 cassandra cassandra 957M Jan 8 22:51
> /data/sstables/data/ks/cf/ks-cf-ic-569015-Data.db
> -rw-rw-r-- 2 cassandra cassandra 923M Jan 9 17:04
> /data/sstables/data/ks/cf/ks-cf-ic-571303-Data.db
> -rw-rw-r-- 1 cassandra cassandra 821M Jan 10 08:20
> /data/sstables/data/ks/cf/ks-cf-ic-574642-Data.db
> -rw-rw-r-- 1 cassandra cassandra 18M Jan 10 08:48
> /data/sstables/data/ks/cf/ks-cf-ic-574723-Data.db
> {noformat}
> I tried to do a user defined compaction on sstables from November and got "it
> is not an active sstable". Live sstable count from jmx was about 7 while on
> disk there were over 20. Live vs total size showed about a ~50 GiB
> difference.
> Forcing a gc from jconsole had no effect. However, restarting the node
> resulted in live sstables/bytes *increasing* to match what was on disk. User
> compaction could now compact the November sstables. This cluster was last
> restarted in mid December.
> I'm not sure what affect "not live" had on other operations of the cluster.
> From the logs it seems that the files were sent at least at some point as
> part of repair, but I don't know if they were being being used for read
> requests or not. Because the problem that got me looking in the first place
> was poor performance I suspect they were used for reads (and the reads were
> slow because so many sstables were being read). I presume based on their age
> at the least they were being excluded from compaction.
> I'm not aware of any isLive() or getRefCount() to problematically confirm
> which nodes have this problem. In this cluster almost all columns have a 14
> day TTL, based on the number of nodes with November sstables it appears to be
> occurring on a significant fraction of the nodes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6656) Exception logging
[
https://issues.apache.org/jira/browse/CASSANDRA-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ding Yuan updated CASSANDRA-6656:
-
Attachment: trunk-6656-v3.txt
> Exception logging
> -
>
> Key: CASSANDRA-6656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6656
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
>Reporter: Ding Yuan
>Assignee: Ding Yuan
>Priority: Trivial
> Fix For: 2.1
>
> Attachments: trunk-6656-v2.txt, trunk-6656-v3.txt, trunk-6656.txt
>
>
> Reporting a few cases where informative exceptions can be silently swallowed.
> Attaching a proposed patch.
> =
> Case 1
> Line: 95, File: "org/apache/cassandra/utils/Hex.java"
> An actual failure in the underlying constructor will be lost.
> Propose to log it.
> {noformat}
> try
> {
> s = stringConstructor.newInstance(0, c.length, c);
> + }
> + catch (InvocationTargetException ite) {
> + // The underlying constructor failed. Unwrapping the
> exception.
> + logger.info("Underlying constructor throws exception: ",
> ite.getCause());
> }
> catch (Exception e)
> {
> // Swallowing as we'll just use a copying constructor
> }
> return s == null ? new String(c) : s;
> {noformat}
> ==
> =
> Case 2
> Line: 192, File: "org/apache/cassandra/db/marshal/DynamicCompositeType.java"
> The actual cause of comparator error can be lost as it can fail in multiple
> locations.
> {noformat}
> AbstractType comparator = null;
> int header = getShortLength(bb);
> if ((header & 0x8000) == 0)
> {
> ByteBuffer value = getBytes(bb, header);
> try
> {
> comparator = TypeParser.parse(ByteBufferUtil.string(value));
> }
> catch (Exception e)
> {
> <--- can fail here
> // we'll deal with this below since comparator == null
> }
> }
> else
> {
> comparator = aliases.get((byte)(header & 0xFF));
> <--- can fail here
> }
> if (comparator == null)
> throw new MarshalException("Cannot find comparator for component
> " + i);
> {noformat}
> Propose to log the exception.
> ==
> =
> Case 3
> Line: 239, File: "org/apache/cassandra/tools/NodeProbe.java"
> Exception ignored in finally. Propose log them with debug or trace.
> {noformat}
> 232: finally
> 233: {
> 234: try
> 235: {
> 236: ssProxy.removeNotificationListener(runner);
> 236: ssProxy.removeNotificationListener(runner);
> 237: jmxc.removeConnectionNotificationListener(runner);
> 238: }
> 239: catch (Throwable ignored) {}
> 240: }
> {noformat}
> Similar case is at line 264 in the same file.
> ==
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6656) Exception logging
[
https://issues.apache.org/jira/browse/CASSANDRA-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894163#comment-13894163
]
Mikhail Stepura commented on CASSANDRA-6656:
+1
> Exception logging
> -
>
> Key: CASSANDRA-6656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6656
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
>Reporter: Ding Yuan
>Assignee: Ding Yuan
>Priority: Trivial
> Fix For: 2.1
>
> Attachments: trunk-6656-v2.txt, trunk-6656-v3.txt, trunk-6656.txt
>
>
> Reporting a few cases where informative exceptions can be silently swallowed.
> Attaching a proposed patch.
> =
> Case 1
> Line: 95, File: "org/apache/cassandra/utils/Hex.java"
> An actual failure in the underlying constructor will be lost.
> Propose to log it.
> {noformat}
> try
> {
> s = stringConstructor.newInstance(0, c.length, c);
> + }
> + catch (InvocationTargetException ite) {
> + // The underlying constructor failed. Unwrapping the
> exception.
> + logger.info("Underlying constructor throws exception: ",
> ite.getCause());
> }
> catch (Exception e)
> {
> // Swallowing as we'll just use a copying constructor
> }
> return s == null ? new String(c) : s;
> {noformat}
> ==
> =
> Case 2
> Line: 192, File: "org/apache/cassandra/db/marshal/DynamicCompositeType.java"
> The actual cause of comparator error can be lost as it can fail in multiple
> locations.
> {noformat}
> AbstractType comparator = null;
> int header = getShortLength(bb);
> if ((header & 0x8000) == 0)
> {
> ByteBuffer value = getBytes(bb, header);
> try
> {
> comparator = TypeParser.parse(ByteBufferUtil.string(value));
> }
> catch (Exception e)
> {
> <--- can fail here
> // we'll deal with this below since comparator == null
> }
> }
> else
> {
> comparator = aliases.get((byte)(header & 0xFF));
> <--- can fail here
> }
> if (comparator == null)
> throw new MarshalException("Cannot find comparator for component
> " + i);
> {noformat}
> Propose to log the exception.
> ==
> =
> Case 3
> Line: 239, File: "org/apache/cassandra/tools/NodeProbe.java"
> Exception ignored in finally. Propose log them with debug or trace.
> {noformat}
> 232: finally
> 233: {
> 234: try
> 235: {
> 236: ssProxy.removeNotificationListener(runner);
> 236: ssProxy.removeNotificationListener(runner);
> 237: jmxc.removeConnectionNotificationListener(runner);
> 238: }
> 239: catch (Throwable ignored) {}
> 240: }
> {noformat}
> Similar case is at line 264 in the same file.
> ==
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6591) un-deprecate cache recentHitRate and expose in o.a.c.metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-6591: -- Reviewer: Yuki Morishita > un-deprecate cache recentHitRate and expose in o.a.c.metrics > > > Key: CASSANDRA-6591 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6591 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Burroughs >Assignee: Chris Burroughs >Priority: Minor > Attachments: j6591-1.2-v1.txt, j6591-1.2-v2.txt, j6591-1.2-v3.txt > > > recentHitRate metrics were not added as part of CASSANDRA-4009 because there > is not an obvious way to do it with the Metrics library. Instead hitRate was > added as an all time measurement since node restart. > This does allow changes in cache rate (aka production performance problems) > to be detected. Ideally there would be 1/5/15 moving averages for the hit > rate, but I'm not sure how to calculate that. Instead I propose updating > recentHitRate on a fixed interval and exposing that as a Gauge. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CASSANDRA-6671) NoSuchElementException in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-6671.
---
Resolution: Fixed
Fix Version/s: 2.1
Reviewer: Jonathan Ellis
Assignee: Benedict
committed
> NoSuchElementException in trunk
> ---
>
> Key: CASSANDRA-6671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6671
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Benedict
> Fix For: 2.1
>
> Attachments: tmp.patch
>
>
> When running {{cassandra-stress -o 1000}} from {{cassandra-1.2}} against
> the latest trunk, I noticed this error in the system log:
> {noformat}
> ERROR 01:13:11 Exception in thread Thread[MutationStage:68,5,main]
> java.lang.RuntimeException: java.util.NoSuchElementException
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2063)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_40]
> Caused by: java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentLinkedDeque.screenNullResult(ConcurrentLinkedDeque.java:812)
> ~[na:1.7.0_40]
> at
> java.util.concurrent.ConcurrentLinkedDeque.getLast(ConcurrentLinkedDeque.java:963)
> ~[na:1.7.0_40]
> at
> org.apache.cassandra.utils.concurrent.WaitQueue.signalAll(WaitQueue.java:122)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.OpOrder$Group.unlink(OpOrder.java:254)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.OpOrder$Group.finishOne(OpOrder.java:209)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment$Allocation.markWritten(CommitLogSegment.java:581)
> ~[main/:na]
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:231)
> ~[main/:na]
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:193)
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:349) ~[main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:328) ~[main/:na]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:205) ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$7.runMayThrow(StorageProxy.java:997)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2059)
> ~[main/:na]
> ... 3 common frames omitted
> {noformat}
> I'm not sure what the implications are.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6591) un-deprecate cache recentHitRate and expose in o.a.c.metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894130#comment-13894130 ] Yuki Morishita commented on CASSANDRA-6591: --- Sure. * +1 on Misses * Is the division of two(hits and requests) exponential moving average the same as the moving average of hit rate? or it is still ok even if not? > un-deprecate cache recentHitRate and expose in o.a.c.metrics > > > Key: CASSANDRA-6591 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6591 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Burroughs >Assignee: Chris Burroughs >Priority: Minor > Attachments: j6591-1.2-v1.txt, j6591-1.2-v2.txt, j6591-1.2-v3.txt > > > recentHitRate metrics were not added as part of CASSANDRA-4009 because there > is not an obvious way to do it with the Metrics library. Instead hitRate was > added as an all time measurement since node restart. > This does allow changes in cache rate (aka production performance problems) > to be detected. Ideally there would be 1/5/15 moving averages for the hit > rate, but I'm not sure how to calculate that. Instead I propose updating > recentHitRate on a fixed interval and exposing that as a Gauge. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6671) NoSuchElementException in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-6671:
Attachment: tmp.patch
[~jbellis] I knew it was dangerous to replace NBQ with CLQ :-)
I will be dropping a major patch that would fix this within the next couple of
days, however this may take some time to get merged. In the mean time I'm
attaching a trivial fix: getLast() apparently isn't remotely concurrency safe,
and will throw a NPE if the queue is empty. peekLast() is the correct method to
use.
> NoSuchElementException in trunk
> ---
>
> Key: CASSANDRA-6671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6671
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
> Attachments: tmp.patch
>
>
> When running {{cassandra-stress -o 1000}} from {{cassandra-1.2}} against
> the latest trunk, I noticed this error in the system log:
> {noformat}
> ERROR 01:13:11 Exception in thread Thread[MutationStage:68,5,main]
> java.lang.RuntimeException: java.util.NoSuchElementException
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2063)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_40]
> Caused by: java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentLinkedDeque.screenNullResult(ConcurrentLinkedDeque.java:812)
> ~[na:1.7.0_40]
> at
> java.util.concurrent.ConcurrentLinkedDeque.getLast(ConcurrentLinkedDeque.java:963)
> ~[na:1.7.0_40]
> at
> org.apache.cassandra.utils.concurrent.WaitQueue.signalAll(WaitQueue.java:122)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.OpOrder$Group.unlink(OpOrder.java:254)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.OpOrder$Group.finishOne(OpOrder.java:209)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment$Allocation.markWritten(CommitLogSegment.java:581)
> ~[main/:na]
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:231)
> ~[main/:na]
> at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:193)
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:349) ~[main/:na]
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:328) ~[main/:na]
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:205) ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$7.runMayThrow(StorageProxy.java:997)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2059)
> ~[main/:na]
> ... 3 common frames omitted
> {noformat}
> I'm not sure what the implications are.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5921) Don't return empty list when the L0 compaction candidates could cause overlap in L1
[ https://issues.apache.org/jira/browse/CASSANDRA-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894154#comment-13894154 ] Ravi Prasad commented on CASSANDRA-5921: we're seeing overlaps in L1 in cassandra-2.0.4, multithreaded_compaction:false, concurrent_compactors:default(num_cores). Also reported by other user in ilist: http://qnalist.com/questions/4702288/exception-during-add-node-due-to-test-beforeappend-on-sstablewriter reverting the changes here to pre-2.0/CASSANDRA-5907, don't see any overlaps. > Don't return empty list when the L0 compaction candidates could cause overlap > in L1 > --- > > Key: CASSANDRA-5921 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5921 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Minor > Fix For: 2.0.1 > > Attachments: > 0001-instead-of-doing-no-compaction-if-we-have-sstables-t.patch, > 0001-instead-of-doing-no-compaction-if-we-have-sstables-t.patch, 5921-v3.txt > > > Followup to CASSANDRA-5907 - instead of returning empty list when the > compaction candidates could cause overlap in L1, remove sstables that would > cause the overlap from the candidates. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894144#comment-13894144 ] Ravi Prasad commented on CASSANDRA-6285: Also, one more factor with disruptor based hsha is direct memory/Unsafe versus heap-based message buffers. When we encountered this issue, we were running with jna, hence was using direct memory buffers. I didn't test with heap-based message buffers. > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6656) Exception logging
[
https://issues.apache.org/jira/browse/CASSANDRA-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894124#comment-13894124
]
Ding Yuan commented on CASSANDRA-6656:
--
Agreed Mikhail Stepura! Attached another one to address your comment.
> Exception logging
> -
>
> Key: CASSANDRA-6656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6656
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
>Reporter: Ding Yuan
>Assignee: Ding Yuan
>Priority: Trivial
> Fix For: 2.1
>
> Attachments: trunk-6656-v2.txt, trunk-6656-v3.txt, trunk-6656.txt
>
>
> Reporting a few cases where informative exceptions can be silently swallowed.
> Attaching a proposed patch.
> =
> Case 1
> Line: 95, File: "org/apache/cassandra/utils/Hex.java"
> An actual failure in the underlying constructor will be lost.
> Propose to log it.
> {noformat}
> try
> {
> s = stringConstructor.newInstance(0, c.length, c);
> + }
> + catch (InvocationTargetException ite) {
> + // The underlying constructor failed. Unwrapping the
> exception.
> + logger.info("Underlying constructor throws exception: ",
> ite.getCause());
> }
> catch (Exception e)
> {
> // Swallowing as we'll just use a copying constructor
> }
> return s == null ? new String(c) : s;
> {noformat}
> ==
> =
> Case 2
> Line: 192, File: "org/apache/cassandra/db/marshal/DynamicCompositeType.java"
> The actual cause of comparator error can be lost as it can fail in multiple
> locations.
> {noformat}
> AbstractType comparator = null;
> int header = getShortLength(bb);
> if ((header & 0x8000) == 0)
> {
> ByteBuffer value = getBytes(bb, header);
> try
> {
> comparator = TypeParser.parse(ByteBufferUtil.string(value));
> }
> catch (Exception e)
> {
> <--- can fail here
> // we'll deal with this below since comparator == null
> }
> }
> else
> {
> comparator = aliases.get((byte)(header & 0xFF));
> <--- can fail here
> }
> if (comparator == null)
> throw new MarshalException("Cannot find comparator for component
> " + i);
> {noformat}
> Propose to log the exception.
> ==
> =
> Case 3
> Line: 239, File: "org/apache/cassandra/tools/NodeProbe.java"
> Exception ignored in finally. Propose log them with debug or trace.
> {noformat}
> 232: finally
> 233: {
> 234: try
> 235: {
> 236: ssProxy.removeNotificationListener(runner);
> 236: ssProxy.removeNotificationListener(runner);
> 237: jmxc.removeConnectionNotificationListener(runner);
> 238: }
> 239: catch (Throwable ignored) {}
> 240: }
> {noformat}
> Similar case is at line 264 in the same file.
> ==
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
git commit: fix NPE patch by Benedict Elliott Smith; reviewed by jbellis for CASSANDRA-6671
Updated Branches:
refs/heads/trunk ff2a92c13 -> 5fe060074
fix NPE
patch by Benedict Elliott Smith; reviewed by jbellis for CASSANDRA-6671
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5fe06007
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5fe06007
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5fe06007
Branch: refs/heads/trunk
Commit: 5fe0600744cba01d8e238746c0bd363f2059320c
Parents: ff2a92c
Author: Jonathan Ellis
Authored: Thu Feb 6 20:28:35 2014 -0600
Committer: Jonathan Ellis
Committed: Thu Feb 6 20:29:09 2014 -0600
--
src/java/org/apache/cassandra/db/DataTracker.java | 7 ---
src/java/org/apache/cassandra/utils/concurrent/WaitQueue.java | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5fe06007/src/java/org/apache/cassandra/db/DataTracker.java
--
diff --git a/src/java/org/apache/cassandra/db/DataTracker.java
b/src/java/org/apache/cassandra/db/DataTracker.java
index f2aae50..d90c0ff 100644
--- a/src/java/org/apache/cassandra/db/DataTracker.java
+++ b/src/java/org/apache/cassandra/db/DataTracker.java
@@ -437,11 +437,12 @@ public class DataTracker
public int getMeanColumns()
{
long sum = 0;
-int count = 0;
+long count = 0;
for (SSTableReader sstable : getSSTables())
{
-sum += sstable.getEstimatedColumnCount().mean();
-count++;
+long n = sstable.getEstimatedColumnCount().count();
+sum += sstable.getEstimatedColumnCount().mean() * n;
+count += n;
}
return count > 0 ? (int) (sum / count) : 0;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5fe06007/src/java/org/apache/cassandra/utils/concurrent/WaitQueue.java
--
diff --git a/src/java/org/apache/cassandra/utils/concurrent/WaitQueue.java
b/src/java/org/apache/cassandra/utils/concurrent/WaitQueue.java
index 3b4ce5f..4f3747d 100644
--- a/src/java/org/apache/cassandra/utils/concurrent/WaitQueue.java
+++ b/src/java/org/apache/cassandra/utils/concurrent/WaitQueue.java
@@ -111,7 +111,8 @@ public final class WaitQueue
*/
public void signalAll()
{
-if (!hasWaiters())
+RegisteredSignal last = queue.peekLast();
+if (last == null)
return;
List woke = null;
if (logger.isTraceEnabled())
@@ -119,7 +120,6 @@ public final class WaitQueue
long start = System.nanoTime();
// we wake up only a snapshot of the queue, to avoid a race where the
condition is not met and the woken thread
// immediately waits on the queue again
-RegisteredSignal last = queue.getLast();
Iterator iter = queue.iterator();
while (iter.hasNext())
{
[jira] [Created] (CASSANDRA-6671) NoSuchElementException in trunk
Tyler Hobbs created CASSANDRA-6671:
--
Summary: NoSuchElementException in trunk
Key: CASSANDRA-6671
URL: https://issues.apache.org/jira/browse/CASSANDRA-6671
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
When running {{cassandra-stress -o 1000}} from {{cassandra-1.2}} against
the latest trunk, I noticed this error in the system log:
{noformat}
ERROR 01:13:11 Exception in thread Thread[MutationStage:68,5,main]
java.lang.RuntimeException: java.util.NoSuchElementException
at
org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2063)
~[main/:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_40]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_40]
Caused by: java.util.NoSuchElementException: null
at
java.util.concurrent.ConcurrentLinkedDeque.screenNullResult(ConcurrentLinkedDeque.java:812)
~[na:1.7.0_40]
at
java.util.concurrent.ConcurrentLinkedDeque.getLast(ConcurrentLinkedDeque.java:963)
~[na:1.7.0_40]
at
org.apache.cassandra.utils.concurrent.WaitQueue.signalAll(WaitQueue.java:122)
~[main/:na]
at
org.apache.cassandra.utils.concurrent.OpOrder$Group.unlink(OpOrder.java:254)
~[main/:na]
at
org.apache.cassandra.utils.concurrent.OpOrder$Group.finishOne(OpOrder.java:209)
~[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogSegment$Allocation.markWritten(CommitLogSegment.java:581)
~[main/:na]
at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:231)
~[main/:na]
at org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:193)
~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:349) ~[main/:na]
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:328) ~[main/:na]
at org.apache.cassandra.db.Mutation.apply(Mutation.java:205) ~[main/:na]
at
org.apache.cassandra.service.StorageProxy$7.runMayThrow(StorageProxy.java:997)
~[main/:na]
at
org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2059)
~[main/:na]
... 3 common frames omitted
{noformat}
I'm not sure what the implications are.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CASSANDRA-6669) NullPointerException(s) on startup if StorageServiceShutdownHook fails
[ https://issues.apache.org/jira/browse/CASSANDRA-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-6669. - Resolution: Fixed I fixed this, twice, most recently in 723fcd1936ad > NullPointerException(s) on startup if StorageServiceShutdownHook fails > -- > > Key: CASSANDRA-6669 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6669 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: RHEL 6.5 (likely not hardware specific) >Reporter: Andre Campeau >Priority: Minor > Fix For: 2.0.4 > > > For example, when starting a newly installed Cassandra node for the first > time, if the seed is down (and the current node is not a seed) a > RuntimeException gets thrown by the Gossiper with "Unable to gossip with any > seeds", and Cassandra subsequently shuts down. > The issue is with the StorageServiceShutdownHook thread which, if any > exception is thrown as it's executing, will miss the remaining steps in the > shutdown process. > Here's a log fragment. > INFO [MemoryMeter:1] 2014-01-29 09:07:04,126 Memtable.java (line 451) > CFS(Keyspace='system', ColumnFamily='schema_columnfamilies') liveRatio is > 2.8177450396801733 (just-counted was 2.5754099604780003). calculation took > 459ms for 26900 cells > INFO [ScheduledTasks:1] 2014-01-29 09:07:04,168 GCInspector.java (line 116) > GC for ParNew: 293 ms for 1 collections, 318930288 used; max is 6215958528 > INFO [MemoryMeter:1] 2014-01-29 09:07:04,246 Memtable.java (line 451) > CFS(Keyspace='system', ColumnFamily='schema_columns') liveRatio is > 2.8940509915872097 (just-counted was 2.6458758011978563). calculation took > 119ms for 23968 cells > INFO [MemoryMeter:1] 2014-01-29 09:07:07,005 Memtable.java (line 451) > CFS(Keyspace='system', ColumnFamily='schema_columnfamilies') liveRatio is > 2.6841006146942297 (just-counted was 2.550456189708286). calculation took > 297ms for 54325 cells > INFO [ScheduledTasks:1] 2014-01-29 09:07:07,326 GCInspector.java (line 116) > GC for ParNew: 289 ms for 1 collections, 291162792 used; max is 6215958528 > INFO [MemoryMeter:1] 2014-01-29 09:07:07,607 Memtable.java (line 451) > CFS(Keyspace='system', ColumnFamily='schema_columns') liveRatio is > 2.770798679512837 (just-counted was 2.6475463674384643). calculation took > 601ms for 47908 cells > INFO [main] 2014-01-29 09:07:09,914 StorageService.java (line 490) Cassandra > version: 2.0.4-SNAPSHOT > INFO [main] 2014-01-29 09:07:09,914 StorageService.java (line 491) Thrift > API version: 19.39.0 > INFO [main] 2014-01-29 09:07:09,918 StorageService.java (line 492) CQL > supported versions: 2.0.0,3.1.3 (default: 3.1.3) > INFO [main] 2014-01-29 09:07:09,933 StorageService.java (line 515) Loading > persisted ring state > INFO [main] 2014-01-29 09:07:09,974 MessagingService.java (line 458) > Starting Messaging Service on port 7000 > ERROR [main] 2014-01-29 09:07:40,993 CassandraDaemon.java (line 473) > Exception encountered during startup > java.lang.RuntimeException: Unable to gossip with any seeds > at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1160) > at > org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:426) > at > org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:618) > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:586) > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:485) > at > org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:341) > at > org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:456) > at > org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:499) > ERROR [StorageServiceShutdownHook] 2014-01-29 09:07:41,150 > CassandraDaemon.java (line 188) Exception in thread > Thread[StorageServiceShutdownHook,5,main] > java.lang.NullPointerException > at > org.apache.cassandra.service.StorageService.stopNativeTransport(StorageService.java:349) > at > org.apache.cassandra.service.StorageService.shutdownClientServers(StorageService.java:364) > at > org.apache.cassandra.service.StorageService.access$000(StorageService.java:97) > at > org.apache.cassandra.service.StorageService$1.runMayThrow(StorageService.java:551) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CASSANDRA-6670) LeaveAndBootstrapTest occasional failure reproduced in 2.0
[
https://issues.apache.org/jira/browse/CASSANDRA-6670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-6670:
---
Assignee: Brandon Williams
> LeaveAndBootstrapTest occasional failure reproduced in 2.0
> --
>
> Key: CASSANDRA-6670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6670
> Project: Cassandra
> Issue Type: Test
> Components: Tests
> Environment: Debian Stable (Wheezy) amd64
> Oracle JVM 1.7.0_51-b13 (and 1.7.0_45-b18)
>Reporter: Michael Shuler
>Assignee: Brandon Williams
>Priority: Minor
> Attachments: system.log, test.sh
>
>
> {noformat}
> Run #122
> Buildfile: /home/mshuler/git/cassandra/build.xml
> init:
> maven-ant-tasks-localrepo:
> maven-ant-tasks-download:
> maven-ant-tasks-init:
> maven-declare-dependencies:
> maven-ant-tasks-retrieve-build:
> init-dependencies:
> [echo] Loading dependency paths from file:
> /home/mshuler/git/cassandra/build/build-dependencies.xml
> check-gen-cli-grammar:
> gen-cli-grammar:
> check-gen-cql2-grammar:
> gen-cql2-grammar:
> check-gen-cql3-grammar:
> gen-cql3-grammar:
> build-project:
> [echo] apache-cassandra: /home/mshuler/git/cassandra/build.xml
> createVersionPropFile:
> [propertyfile] Updating property file:
> /home/mshuler/git/cassandra/src/resources/org/apache/cassandra/config/version.properties
> [copy] Copying 1 file to /home/mshuler/git/cassandra/build/classes/main
> build:
> build-test:
> test:
> [echo] running unit tests
> [junit] WARNING: multiple versions of ant detected in path for junit
> [junit]
> jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/Project.class
> [junit] and
> jar:file:/home/mshuler/git/cassandra/build/lib/jars/ant-1.6.5.jar!/org/apache/tools/ant/Project.class
> [junit] Testsuite: org.apache.cassandra.service.LeaveAndBootstrapTest
> [junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 7.054 sec
> [junit]
> [junit] - Standard Error -
> [junit] WARN 22:14:26,870 Node /127.0.0.3 'leaving' token mismatch. Long
> network partition?
> [junit] - ---
> [junit] Testcase:
> newTestWriteEndpointsDuringLeave(org.apache.cassandra.service.LeaveAndBootstrapTest):
> FAILED
> [junit] mismatched endpoint sets expected:<[/127.0.0.4, /127.0.0.5]> but
> was:<[/127.0.0.4]>
> [junit] junit.framework.AssertionFailedError: mismatched endpoint sets
> expected:<[/127.0.0.4, /127.0.0.5]> but was:<[/127.0.0.4]>
> [junit] at
> org.apache.cassandra.service.LeaveAndBootstrapTest.newTestWriteEndpointsDuringLeave(LeaveAndBootstrapTest.java:134)
> [junit]
> [junit]
> [junit] Test org.apache.cassandra.service.LeaveAndBootstrapTest FAILED
> BUILD FAILED
> /home/mshuler/git/cassandra/build.xml:1079: The following error occurred
> while executing this line:
> /home/mshuler/git/cassandra/build.xml:1038: Some unit test(s) failed.
> Total time: 10 seconds
> {noformat}
> - test.sh attached
> - system.log from failed test attached
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6604) AssertionError: Verb COUNTER_MUTATION should not legally be dropped
[
https://issues.apache.org/jira/browse/CASSANDRA-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893996#comment-13893996
]
Eric Lubow commented on CASSANDRA-6604:
---
I'm not entirely sure this is cosmetic. We have a 20 node cluster running
1.2.13.2 (DSE 3.2.4) and it is not under a heavy load at all. We are seeing
this simultaneously with tens of thousands of dropped mutations under higher
traffic scenarios and just thousands of mutations dropped under lower traffic
scenarios. However, it is only happening on a single node. There is nothing
(visibly) wrong with that node other than higher CPU utilization that the other
nodes. Even with the higher CPU utilization, it is still not a stressed node
and yet we are seeing the dropped MUTATIONS and this error message (again only
on this node).
> AssertionError: Verb COUNTER_MUTATION should not legally be dropped
> ---
>
> Key: CASSANDRA-6604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6604
> Project: Cassandra
> Issue Type: Bug
>Reporter: Bartłomiej Romański
> Fix For: 1.2.14, 2.0.5
>
>
> We're seeing the following errors in our logs from time to time (about once
> an hour):
> {code}
> ERROR [MutationStage:10] 2014-01-19 10:36:26,659 CassandraDaemon.java (line
> 187) Exception in thread Thread[MutationStage:10,5,main]
> java.lang.AssertionError: Verb COUNTER_MUTATION should not legally be dropped
> at
> org.apache.cassandra.net.MessagingService.incrementDroppedMessages(MessagingService.java:779)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1925)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {code}
> They always appear in groups. About 50-100 errors in a row.
> We've got a 12-nodes cluster recently upgraded from 1.2.10 to 2.0.4. It's
> under pretty heavy load.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893967#comment-13893967 ] Pavel Yaskevich commented on CASSANDRA-6285: I see that you have it set to NONE in CF schema but have you also tried disabling it all together in yaml? I'm not saying that it would help but trying to eliminate all possibilities. It's just not obvious to me if it's a hsha problem how Thrift could actually be correctly interpreting erroneous data from the socket, dispatching it the right Thrift handler and deserializing whole mutation (and meta information) to insert it into storage... > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893956#comment-13893956 ] Brandon Kearby commented on CASSANDRA-6285: --- [~xedin], I've tried disabling the key_cache and it didn't help. That was the last thing I tried. > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6670) LeaveAndBootstrapTest occasional failure reproduced in 2.0
[
https://issues.apache.org/jira/browse/CASSANDRA-6670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-6670:
--
Attachment: system.log
test.sh
> LeaveAndBootstrapTest occasional failure reproduced in 2.0
> --
>
> Key: CASSANDRA-6670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6670
> Project: Cassandra
> Issue Type: Test
> Components: Tests
> Environment: Debian Stable (Wheezy) amd64
> Oracle JVM 1.7.0_51-b13 (and 1.7.0_45-b18)
>Reporter: Michael Shuler
>Priority: Minor
> Attachments: system.log, test.sh
>
>
> {noformat}
> Run #122
> Buildfile: /home/mshuler/git/cassandra/build.xml
> init:
> maven-ant-tasks-localrepo:
> maven-ant-tasks-download:
> maven-ant-tasks-init:
> maven-declare-dependencies:
> maven-ant-tasks-retrieve-build:
> init-dependencies:
> [echo] Loading dependency paths from file:
> /home/mshuler/git/cassandra/build/build-dependencies.xml
> check-gen-cli-grammar:
> gen-cli-grammar:
> check-gen-cql2-grammar:
> gen-cql2-grammar:
> check-gen-cql3-grammar:
> gen-cql3-grammar:
> build-project:
> [echo] apache-cassandra: /home/mshuler/git/cassandra/build.xml
> createVersionPropFile:
> [propertyfile] Updating property file:
> /home/mshuler/git/cassandra/src/resources/org/apache/cassandra/config/version.properties
> [copy] Copying 1 file to /home/mshuler/git/cassandra/build/classes/main
> build:
> build-test:
> test:
> [echo] running unit tests
> [junit] WARNING: multiple versions of ant detected in path for junit
> [junit]
> jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/Project.class
> [junit] and
> jar:file:/home/mshuler/git/cassandra/build/lib/jars/ant-1.6.5.jar!/org/apache/tools/ant/Project.class
> [junit] Testsuite: org.apache.cassandra.service.LeaveAndBootstrapTest
> [junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 7.054 sec
> [junit]
> [junit] - Standard Error -
> [junit] WARN 22:14:26,870 Node /127.0.0.3 'leaving' token mismatch. Long
> network partition?
> [junit] - ---
> [junit] Testcase:
> newTestWriteEndpointsDuringLeave(org.apache.cassandra.service.LeaveAndBootstrapTest):
> FAILED
> [junit] mismatched endpoint sets expected:<[/127.0.0.4, /127.0.0.5]> but
> was:<[/127.0.0.4]>
> [junit] junit.framework.AssertionFailedError: mismatched endpoint sets
> expected:<[/127.0.0.4, /127.0.0.5]> but was:<[/127.0.0.4]>
> [junit] at
> org.apache.cassandra.service.LeaveAndBootstrapTest.newTestWriteEndpointsDuringLeave(LeaveAndBootstrapTest.java:134)
> [junit]
> [junit]
> [junit] Test org.apache.cassandra.service.LeaveAndBootstrapTest FAILED
> BUILD FAILED
> /home/mshuler/git/cassandra/build.xml:1079: The following error occurred
> while executing this line:
> /home/mshuler/git/cassandra/build.xml:1038: Some unit test(s) failed.
> Total time: 10 seconds
> {noformat}
> - test.sh attached
> - system.log from failed test attached
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CASSANDRA-6670) LeaveAndBootstrapTest occasional failure reproduced in 2.0
Michael Shuler created CASSANDRA-6670:
-
Summary: LeaveAndBootstrapTest occasional failure reproduced in 2.0
Key: CASSANDRA-6670
URL: https://issues.apache.org/jira/browse/CASSANDRA-6670
Project: Cassandra
Issue Type: Test
Components: Tests
Environment: Debian Stable (Wheezy) amd64
Oracle JVM 1.7.0_51-b13 (and 1.7.0_45-b18)
Reporter: Michael Shuler
Priority: Minor
{noformat}
Run #122
Buildfile: /home/mshuler/git/cassandra/build.xml
init:
maven-ant-tasks-localrepo:
maven-ant-tasks-download:
maven-ant-tasks-init:
maven-declare-dependencies:
maven-ant-tasks-retrieve-build:
init-dependencies:
[echo] Loading dependency paths from file:
/home/mshuler/git/cassandra/build/build-dependencies.xml
check-gen-cli-grammar:
gen-cli-grammar:
check-gen-cql2-grammar:
gen-cql2-grammar:
check-gen-cql3-grammar:
gen-cql3-grammar:
build-project:
[echo] apache-cassandra: /home/mshuler/git/cassandra/build.xml
createVersionPropFile:
[propertyfile] Updating property file:
/home/mshuler/git/cassandra/src/resources/org/apache/cassandra/config/version.properties
[copy] Copying 1 file to /home/mshuler/git/cassandra/build/classes/main
build:
build-test:
test:
[echo] running unit tests
[junit] WARNING: multiple versions of ant detected in path for junit
[junit]
jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/Project.class
[junit] and
jar:file:/home/mshuler/git/cassandra/build/lib/jars/ant-1.6.5.jar!/org/apache/tools/ant/Project.class
[junit] Testsuite: org.apache.cassandra.service.LeaveAndBootstrapTest
[junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 7.054 sec
[junit]
[junit] - Standard Error -
[junit] WARN 22:14:26,870 Node /127.0.0.3 'leaving' token mismatch. Long
network partition?
[junit] - ---
[junit] Testcase:
newTestWriteEndpointsDuringLeave(org.apache.cassandra.service.LeaveAndBootstrapTest):
FAILED
[junit] mismatched endpoint sets expected:<[/127.0.0.4, /127.0.0.5]> but
was:<[/127.0.0.4]>
[junit] junit.framework.AssertionFailedError: mismatched endpoint sets
expected:<[/127.0.0.4, /127.0.0.5]> but was:<[/127.0.0.4]>
[junit] at
org.apache.cassandra.service.LeaveAndBootstrapTest.newTestWriteEndpointsDuringLeave(LeaveAndBootstrapTest.java:134)
[junit]
[junit]
[junit] Test org.apache.cassandra.service.LeaveAndBootstrapTest FAILED
BUILD FAILED
/home/mshuler/git/cassandra/build.xml:1079: The following error occurred while
executing this line:
/home/mshuler/git/cassandra/build.xml:1038: Some unit test(s) failed.
Total time: 10 seconds
{noformat}
- test.sh attached
- system.log from failed test attached
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CASSANDRA-6669) NullPointerException(s) on startup if StorageServiceShutdownHook fails
Andre Campeau created CASSANDRA-6669: Summary: NullPointerException(s) on startup if StorageServiceShutdownHook fails Key: CASSANDRA-6669 URL: https://issues.apache.org/jira/browse/CASSANDRA-6669 Project: Cassandra Issue Type: Bug Components: Core Environment: RHEL 6.5 (likely not hardware specific) Reporter: Andre Campeau Priority: Minor Fix For: 2.0.4 For example, when starting a newly installed Cassandra node for the first time, if the seed is down (and the current node is not a seed) a RuntimeException gets thrown by the Gossiper with "Unable to gossip with any seeds", and Cassandra subsequently shuts down. The issue is with the StorageServiceShutdownHook thread which, if any exception is thrown as it's executing, will miss the remaining steps in the shutdown process. Here's a log fragment. INFO [MemoryMeter:1] 2014-01-29 09:07:04,126 Memtable.java (line 451) CFS(Keyspace='system', ColumnFamily='schema_columnfamilies') liveRatio is 2.8177450396801733 (just-counted was 2.5754099604780003). calculation took 459ms for 26900 cells INFO [ScheduledTasks:1] 2014-01-29 09:07:04,168 GCInspector.java (line 116) GC for ParNew: 293 ms for 1 collections, 318930288 used; max is 6215958528 INFO [MemoryMeter:1] 2014-01-29 09:07:04,246 Memtable.java (line 451) CFS(Keyspace='system', ColumnFamily='schema_columns') liveRatio is 2.8940509915872097 (just-counted was 2.6458758011978563). calculation took 119ms for 23968 cells INFO [MemoryMeter:1] 2014-01-29 09:07:07,005 Memtable.java (line 451) CFS(Keyspace='system', ColumnFamily='schema_columnfamilies') liveRatio is 2.6841006146942297 (just-counted was 2.550456189708286). calculation took 297ms for 54325 cells INFO [ScheduledTasks:1] 2014-01-29 09:07:07,326 GCInspector.java (line 116) GC for ParNew: 289 ms for 1 collections, 291162792 used; max is 6215958528 INFO [MemoryMeter:1] 2014-01-29 09:07:07,607 Memtable.java (line 451) CFS(Keyspace='system', ColumnFamily='schema_columns') liveRatio is 2.770798679512837 (just-counted was 2.6475463674384643). calculation took 601ms for 47908 cells INFO [main] 2014-01-29 09:07:09,914 StorageService.java (line 490) Cassandra version: 2.0.4-SNAPSHOT INFO [main] 2014-01-29 09:07:09,914 StorageService.java (line 491) Thrift API version: 19.39.0 INFO [main] 2014-01-29 09:07:09,918 StorageService.java (line 492) CQL supported versions: 2.0.0,3.1.3 (default: 3.1.3) INFO [main] 2014-01-29 09:07:09,933 StorageService.java (line 515) Loading persisted ring state INFO [main] 2014-01-29 09:07:09,974 MessagingService.java (line 458) Starting Messaging Service on port 7000 ERROR [main] 2014-01-29 09:07:40,993 CassandraDaemon.java (line 473) Exception encountered during startup java.lang.RuntimeException: Unable to gossip with any seeds at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1160) at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:426) at org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:618) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:586) at org.apache.cassandra.service.StorageService.initServer(StorageService.java:485) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:341) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:456) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:499) ERROR [StorageServiceShutdownHook] 2014-01-29 09:07:41,150 CassandraDaemon.java (line 188) Exception in thread Thread[StorageServiceShutdownHook,5,main] java.lang.NullPointerException at org.apache.cassandra.service.StorageService.stopNativeTransport(StorageService.java:349) at org.apache.cassandra.service.StorageService.shutdownClientServers(StorageService.java:364) at org.apache.cassandra.service.StorageService.access$000(StorageService.java:97) at org.apache.cassandra.service.StorageService$1.runMayThrow(StorageService.java:551) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893894#comment-13893894 ] Pavel Yaskevich commented on CASSANDRA-6285: [~rhatch] The 0 frame size you are seeing is a known Thrift problem which happens even with stock server implementations, they are working on it but it shouldn't cause any problems as such frames are ignored (it could also happen if something does e.g. telnet to the thrift port). I'm not sure that this is a problem with HsHa directly but might be unveiled by the increased throughput you can get with HsHa comparing to sync, it looks exactly like https://issues.apache.org/jira/browse/CASSANDRA-4687 (as [~brandon.kearby] mentioned) so can you try disabling key_cache and try uploading again with hsha? > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5412) Lots of deleted rows came back to life after upgrade from 1.1.6 to 1.1.10
[ https://issues.apache.org/jira/browse/CASSANDRA-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893876#comment-13893876 ] Arya Goudarzi commented on CASSANDRA-5412: -- +1 > Lots of deleted rows came back to life after upgrade from 1.1.6 to 1.1.10 > - > > Key: CASSANDRA-5412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5412 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.10 > Environment: Ubuntu 10.04 LTS > Sun Java 6 u39 > 1.1.6 => 1.1.10 >Reporter: Arya Goudarzi > > Also per discussion here: > http://www.mail-archive.com/user@cassandra.apache.org/msg28905.html > I was not able to find any answers as to why a simple upgrade process could > bring back a lot of (millions) of deleted rows to life. We have successful > repairs running on our cluster every night. Unless repair is not doing its > job, it is not possible to the best of my knowledge that the deleted rows > come back unless there is a bug. I have previously experienced this issue > when I upgraded our sandbox cluster. I failed at every single attempt to > reproduce the issue by restoring a fresh cluster from snapshot, and > performing the upgrade from 1.1.6 to 1.1.10. I even exercised this with the > snapshot of our production cluster before upgrading and was not successful. > So, I finally made the decision to upgrade, and guess what?! Millions of > deleted rows came back after the upgrade. > This time I confirmed the timestamps of the deleted rows that came back; they > were actually before the time there were deleted. So, this is just like when > tombstones get purged before they get propagated. We use nanosecond precision > timestamps (19 digits). > My discussion on the mailing list did not lead anywhere, though Aaron helped > me find one another possible way of this happening by Hinted Handoff which I > filed a separate ticket for. I don't believe this is an issue for us as we > don't have nodes down for a long period of time. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5412) Lots of deleted rows came back to life after upgrade from 1.1.6 to 1.1.10
[ https://issues.apache.org/jira/browse/CASSANDRA-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893848#comment-13893848 ] Robert Coli commented on CASSANDRA-5412: In retrospect, this seems likely to have been CASSANDRA-6503, I'm going to link them for google searchers. > Lots of deleted rows came back to life after upgrade from 1.1.6 to 1.1.10 > - > > Key: CASSANDRA-5412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5412 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.10 > Environment: Ubuntu 10.04 LTS > Sun Java 6 u39 > 1.1.6 => 1.1.10 >Reporter: Arya Goudarzi > > Also per discussion here: > http://www.mail-archive.com/user@cassandra.apache.org/msg28905.html > I was not able to find any answers as to why a simple upgrade process could > bring back a lot of (millions) of deleted rows to life. We have successful > repairs running on our cluster every night. Unless repair is not doing its > job, it is not possible to the best of my knowledge that the deleted rows > come back unless there is a bug. I have previously experienced this issue > when I upgraded our sandbox cluster. I failed at every single attempt to > reproduce the issue by restoring a fresh cluster from snapshot, and > performing the upgrade from 1.1.6 to 1.1.10. I even exercised this with the > snapshot of our production cluster before upgrading and was not successful. > So, I finally made the decision to upgrade, and guess what?! Millions of > deleted rows came back after the upgrade. > This time I confirmed the timestamps of the deleted rows that came back; they > were actually before the time there were deleted. So, this is just like when > tombstones get purged before they get propagated. We use nanosecond precision > timestamps (19 digits). > My discussion on the mailing list did not lead anywhere, though Aaron helped > me find one another possible way of this happening by Hinted Handoff which I > filed a separate ticket for. I don't believe this is an issue for us as we > don't have nodes down for a long period of time. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6591) un-deprecate cache recentHitRate and expose in o.a.c.metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893842#comment-13893842 ] Chris Burroughs commented on CASSANDRA-6591: [~yukim] Could you take a look at your leisure? > un-deprecate cache recentHitRate and expose in o.a.c.metrics > > > Key: CASSANDRA-6591 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6591 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Burroughs >Assignee: Chris Burroughs >Priority: Minor > Attachments: j6591-1.2-v1.txt, j6591-1.2-v2.txt, j6591-1.2-v3.txt > > > recentHitRate metrics were not added as part of CASSANDRA-4009 because there > is not an obvious way to do it with the Metrics library. Instead hitRate was > added as an all time measurement since node restart. > This does allow changes in cache rate (aka production performance problems) > to be detected. Ideally there would be 1/5/15 moving averages for the hit > rate, but I'm not sure how to calculate that. Instead I propose updating > recentHitRate on a fixed interval and exposing that as a Gauge. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6305) cqlsh support for User Types
[
https://issues.apache.org/jira/browse/CASSANDRA-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-6305:
---
Attachment: trunk-6305-2.patch
Attached the 2nd version of the patch - refresh UT metadata only after
{{alter/create/drop type}}
> cqlsh support for User Types
>
>
> Key: CASSANDRA-6305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6305
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Aleksey Yeschenko
>Assignee: Mikhail Stepura
> Labels: cqlsh
> Fix For: 2.1
>
> Attachments: trunk-6305-1.patch, trunk-6305-2.patch
>
>
> We need cqlsh support for several things:
> 1. Autocomplete for UPDATE/INSERT/SELECT
> 2. Autocomplete for ALTER TYPE/CREATE TYPE/DROP TYPE
> 3. Proper decoding of UserType values (currently showing the encoded blob)
> 4. Support UserTypes in DESCRIBE
> 5. Separate DESCRIBE TYPES|TYPE cmds
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[3/3] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ff2a92c1 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ff2a92c1 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ff2a92c1 Branch: refs/heads/trunk Commit: ff2a92c13c822e3220fe980323590bb4032f32bc Parents: d5c5734 ce9c8c2 Author: Brandon Williams Authored: Thu Feb 6 15:05:54 2014 -0600 Committer: Brandon Williams Committed: Thu Feb 6 15:05:54 2014 -0600 -- CHANGES.txt| 1 + .../org/apache/cassandra/gms/FailureDetector.java | 17 - 2 files changed, 9 insertions(+), 9 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ff2a92c1/CHANGES.txt -- diff --cc CHANGES.txt index 86e576c,85c6533..098d8ad --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,36 -1,8 +1,37 @@@ +2.1 + * add listsnapshots command to nodetool (CASSANDRA-5742) + * Introduce AtomicBTreeColumns (CASSANDRA-6271) + * Multithreaded commitlog (CASSANDRA-3578) + * allocate fixed index summary memory pool and resample cold index summaries + to use less memory (CASSANDRA-5519) + * Removed multithreaded compaction (CASSANDRA-6142) + * Parallelize fetching rows for low-cardinality indexes (CASSANDRA-1337) + * change logging from log4j to logback (CASSANDRA-5883) + * switch to LZ4 compression for internode communication (CASSANDRA-5887) + * Stop using Thrift-generated Index* classes internally (CASSANDRA-5971) + * Remove 1.2 network compatibility code (CASSANDRA-5960) + * Remove leveled json manifest migration code (CASSANDRA-5996) + * Remove CFDefinition (CASSANDRA-6253) + * Use AtomicIntegerFieldUpdater in RefCountedMemory (CASSANDRA-6278) + * User-defined types for CQL3 (CASSANDRA-5590) + * Use of o.a.c.metrics in nodetool (CASSANDRA-5871, 6406) + * Batch read from OTC's queue and cleanup (CASSANDRA-1632) + * Secondary index support for collections (CASSANDRA-4511, 6383) + * SSTable metadata(Stats.db) format change (CASSANDRA-6356) + * Push composites support in the storage engine + (CASSANDRA-5417, CASSANDRA-6520) + * Add snapshot space used to cfstats (CASSANDRA-6231) + * Add cardinality estimator for key count estimation (CASSANDRA-5906) + * CF id is changed to be non-deterministic. Data dir/key cache are created + uniquely for CF id (CASSANDRA-5202) + * New counters implementation (CASSANDRA-6504) + * Replace UnsortedColumns usage with ArrayBackedSortedColumns (CASSANDRA-6630) + * Add option to use row cache with a given amount of rows (CASSANDRA-5357) + 2.0.6 + * Failure detector correctly converts initial value to nanos (CASSANDRA-6658) * Add nodetool taketoken to relocate vnodes (CASSANDRA-4445) * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) - * Improve nodetool cfhistograms formatting (CASSANDRA-6360) * Expose bulk loading progress over JMX (CASSANDRA-4757) * Correctly handle null with IF conditions and TTL (CASSANDRA-6623) * Account for range/row tombstones in tombstone drop http://git-wip-us.apache.org/repos/asf/cassandra/blob/ff2a92c1/src/java/org/apache/cassandra/gms/FailureDetector.java --
[2/3] git commit: Failure detector correctly converts initial value to nanos Patch by brandonwilliams reviewed by jbellis for CASSANDRA-6658
Failure detector correctly converts initial value to nanos
Patch by brandonwilliams reviewed by jbellis for CASSANDRA-6658
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ce9c8c2c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ce9c8c2c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ce9c8c2c
Branch: refs/heads/trunk
Commit: ce9c8c2cde6e336e8bb8aa74b5d2c9241a0e606e
Parents: 5f64af6
Author: Brandon Williams
Authored: Thu Feb 6 15:05:29 2014 -0600
Committer: Brandon Williams
Committed: Thu Feb 6 15:05:29 2014 -0600
--
CHANGES.txt| 1 +
.../org/apache/cassandra/gms/FailureDetector.java | 17 -
2 files changed, 9 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ce9c8c2c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6e3c2c2..85c6533 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.6
+ * Failure detector correctly converts initial value to nanos (CASSANDRA-6658)
* Add nodetool taketoken to relocate vnodes (CASSANDRA-4445)
* Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645)
* Improve nodetool cfhistograms formatting (CASSANDRA-6360)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ce9c8c2c/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index a7eb82f..36776bc 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -23,6 +23,7 @@ import java.net.InetAddress;
import java.net.UnknownHostException;
import java.util.*;
import java.util.concurrent.CopyOnWriteArrayList;
+import java.util.concurrent.TimeUnit;
import javax.management.MBeanServer;
import javax.management.ObjectName;
@@ -45,7 +46,7 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
{
public static final String MBEAN_NAME =
"org.apache.cassandra.net:type=FailureDetector";
private static final int SAMPLE_SIZE = 1000;
-protected static final int INITIAL_VALUE = getInitialValue();
+protected static final long INITIAL_VALUE_NANOS =
TimeUnit.NANOSECONDS.convert(getInitialValue(), TimeUnit.MILLISECONDS);
public static final IFailureDetector instance = new FailureDetector();
private static final Logger logger =
LoggerFactory.getLogger(FailureDetector.class);
@@ -73,7 +74,7 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
}
}
-private static int getInitialValue()
+private static long getInitialValue()
{
String newvalue = System.getProperty("cassandra.fd_initial_value_ms");
if (newvalue != null)
@@ -296,29 +297,27 @@ class ArrivalWindow
// change.
private final double PHI_FACTOR = 1.0 / Math.log(10.0);
-private static final long MILLI_TO_NANO = 100L;
-
// in the event of a long partition, never record an interval longer than
the rpc timeout,
// since if a host is regularly experiencing connectivity problems lasting
this long we'd
// rather mark it down quickly instead of adapting
// this value defaults to the same initial value the FD is seeded with
-private final long MAX_INTERVAL_IN_NANO = getMaxInterval() * MILLI_TO_NANO;
+private final long MAX_INTERVAL_IN_NANO = getMaxInterval();
ArrivalWindow(int size)
{
arrivalIntervals = new BoundedStatsDeque(size);
}
-private static int getMaxInterval()
+private static long getMaxInterval()
{
String newvalue = System.getProperty("cassandra.fd_max_interval_ms");
if (newvalue != null)
{
logger.info("Overriding FD MAX_INTERVAL to {}ms", newvalue);
-return Integer.parseInt(newvalue);
+return TimeUnit.NANOSECONDS.convert(Integer.parseInt(newvalue),
TimeUnit.MILLISECONDS);
}
else
-return FailureDetector.INITIAL_VALUE;
+return FailureDetector.INITIAL_VALUE_NANOS;
}
synchronized void add(long value)
@@ -337,7 +336,7 @@ class ArrivalWindow
// We use a very large initial interval since the "right" average
depends on the cluster size
// and it's better to err high (false negatives, which will be
corrected by waiting a bit longer)
// than low (false positives, which cause "flapping").
-arrivalIntervals.add(FailureDetector.INITIAL_VALUE);
+arrivalIntervals.add(FailureDetector.INITIA
[1/3] git commit: Failure detector correctly converts initial value to nanos Patch by brandonwilliams reviewed by jbellis for CASSANDRA-6658
Updated Branches:
refs/heads/cassandra-2.0 5f64af63a -> ce9c8c2cd
refs/heads/trunk d5c5734c8 -> ff2a92c13
Failure detector correctly converts initial value to nanos
Patch by brandonwilliams reviewed by jbellis for CASSANDRA-6658
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ce9c8c2c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ce9c8c2c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ce9c8c2c
Branch: refs/heads/cassandra-2.0
Commit: ce9c8c2cde6e336e8bb8aa74b5d2c9241a0e606e
Parents: 5f64af6
Author: Brandon Williams
Authored: Thu Feb 6 15:05:29 2014 -0600
Committer: Brandon Williams
Committed: Thu Feb 6 15:05:29 2014 -0600
--
CHANGES.txt| 1 +
.../org/apache/cassandra/gms/FailureDetector.java | 17 -
2 files changed, 9 insertions(+), 9 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ce9c8c2c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6e3c2c2..85c6533 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.6
+ * Failure detector correctly converts initial value to nanos (CASSANDRA-6658)
* Add nodetool taketoken to relocate vnodes (CASSANDRA-4445)
* Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645)
* Improve nodetool cfhistograms formatting (CASSANDRA-6360)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ce9c8c2c/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index a7eb82f..36776bc 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -23,6 +23,7 @@ import java.net.InetAddress;
import java.net.UnknownHostException;
import java.util.*;
import java.util.concurrent.CopyOnWriteArrayList;
+import java.util.concurrent.TimeUnit;
import javax.management.MBeanServer;
import javax.management.ObjectName;
@@ -45,7 +46,7 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
{
public static final String MBEAN_NAME =
"org.apache.cassandra.net:type=FailureDetector";
private static final int SAMPLE_SIZE = 1000;
-protected static final int INITIAL_VALUE = getInitialValue();
+protected static final long INITIAL_VALUE_NANOS =
TimeUnit.NANOSECONDS.convert(getInitialValue(), TimeUnit.MILLISECONDS);
public static final IFailureDetector instance = new FailureDetector();
private static final Logger logger =
LoggerFactory.getLogger(FailureDetector.class);
@@ -73,7 +74,7 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
}
}
-private static int getInitialValue()
+private static long getInitialValue()
{
String newvalue = System.getProperty("cassandra.fd_initial_value_ms");
if (newvalue != null)
@@ -296,29 +297,27 @@ class ArrivalWindow
// change.
private final double PHI_FACTOR = 1.0 / Math.log(10.0);
-private static final long MILLI_TO_NANO = 100L;
-
// in the event of a long partition, never record an interval longer than
the rpc timeout,
// since if a host is regularly experiencing connectivity problems lasting
this long we'd
// rather mark it down quickly instead of adapting
// this value defaults to the same initial value the FD is seeded with
-private final long MAX_INTERVAL_IN_NANO = getMaxInterval() * MILLI_TO_NANO;
+private final long MAX_INTERVAL_IN_NANO = getMaxInterval();
ArrivalWindow(int size)
{
arrivalIntervals = new BoundedStatsDeque(size);
}
-private static int getMaxInterval()
+private static long getMaxInterval()
{
String newvalue = System.getProperty("cassandra.fd_max_interval_ms");
if (newvalue != null)
{
logger.info("Overriding FD MAX_INTERVAL to {}ms", newvalue);
-return Integer.parseInt(newvalue);
+return TimeUnit.NANOSECONDS.convert(Integer.parseInt(newvalue),
TimeUnit.MILLISECONDS);
}
else
-return FailureDetector.INITIAL_VALUE;
+return FailureDetector.INITIAL_VALUE_NANOS;
}
synchronized void add(long value)
@@ -337,7 +336,7 @@ class ArrivalWindow
// We use a very large initial interval since the "right" average
depends on the cluster size
// and it's better to err high (false negatives, which will be
corrected by waiting a bit longer)
// than low (false positives, which cause "flapping").
-
[jira] [Updated] (CASSANDRA-6658) Nodes flap once at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-6658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6658: -- Fix Version/s: (was: 1.2.16) Ah, you're right. It was a bad merge. > Nodes flap once at startup > -- > > Key: CASSANDRA-6658 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6658 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.6 > > Attachments: 6658-v2.txt, 6658.txt > > > Upon initially seeing each other, a node will mark another UP, then DOWN, > then UP again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6667) Mean cells per sstable is calculated incorrectly
[ https://issues.apache.org/jira/browse/CASSANDRA-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6667: -- Attachment: 6667-v2.txt v2 changes count to long (pointed out by Paulo Gaspar, who brought this to my attention initially) > Mean cells per sstable is calculated incorrectly > > > Key: CASSANDRA-6667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6667 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 1.2.16, 2.0.6 > > Attachments: 6667-v2.txt, 6667.txt > > > We currently take the average of the mean for each partition, rather than > correctly weighting by cell count. This affects hint paging as well as index > selectivity calculation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6658) Nodes flap once at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-6658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893807#comment-13893807 ] Brandon Williams commented on CASSANDRA-6658: - 1.2 doesn't use nanos, so I don't think so. > Nodes flap once at startup > -- > > Key: CASSANDRA-6658 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6658 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 1.2.16, 2.0.6 > > Attachments: 6658-v2.txt, 6658.txt > > > Upon initially seeing each other, a node will mark another UP, then DOWN, > then UP again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6658) Nodes flap once at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-6658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6658: -- Fix Version/s: 1.2.16 Looks like this affects 1.2 as well > Nodes flap once at startup > -- > > Key: CASSANDRA-6658 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6658 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 1.2.16, 2.0.6 > > Attachments: 6658-v2.txt, 6658.txt > > > Upon initially seeing each other, a node will mark another UP, then DOWN, > then UP again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893800#comment-13893800 ] Brandon Kearby commented on CASSANDRA-6285: --- [~xedin], I was running with 0.3.3. The previous version would hang on describe ring for me. > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6658) Nodes flap once at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-6658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893802#comment-13893802 ] Jonathan Ellis commented on CASSANDRA-6658: --- +1 > Nodes flap once at startup > -- > > Key: CASSANDRA-6658 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6658 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 1.2.16, 2.0.6 > > Attachments: 6658-v2.txt, 6658.txt > > > Upon initially seeing each other, a node will mark another UP, then DOWN, > then UP again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6357) Flush memtables to separate directory
[ https://issues.apache.org/jira/browse/CASSANDRA-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6357: -- Attachment: 6357-v2.txt v2 attached that handles blacklisted-flush-location > Flush memtables to separate directory > - > > Key: CASSANDRA-6357 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6357 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Patrick McFadin >Assignee: Jonathan Ellis > Fix For: 2.0.6 > > Attachments: 6357-v2.txt, 6357.txt, > c6357-stress-write-latency-99th-1.png > > > Flush writers are a critical element for keeping a node healthy. When several > compactions run on systems with low performing data directories, IO becomes a > premium. Once the disk subsystem is saturated, write IO is blocked which will > cause flush writer threads to backup. Since memtables are large blocks of > memory in the JVM, too much blocking can cause excessive GC over time > degrading performance. In the worst case causing an OOM. > Since compaction is running on the data directories. My proposal is to create > a separate directory for flushing memtables. Potentially we can use the same > methodology of keeping the commit log separate and minimize disk contention > against the critical function of the flushwriter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6357) Flush memtables to separate directory
[ https://issues.apache.org/jira/browse/CASSANDRA-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6357: -- Reviewer: Aleksey Yeschenko > Flush memtables to separate directory > - > > Key: CASSANDRA-6357 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6357 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Patrick McFadin >Assignee: Jonathan Ellis > Fix For: 2.0.6 > > Attachments: 6357-v2.txt, 6357.txt, > c6357-stress-write-latency-99th-1.png > > > Flush writers are a critical element for keeping a node healthy. When several > compactions run on systems with low performing data directories, IO becomes a > premium. Once the disk subsystem is saturated, write IO is blocked which will > cause flush writer threads to backup. Since memtables are large blocks of > memory in the JVM, too much blocking can cause excessive GC over time > degrading performance. In the worst case causing an OOM. > Since compaction is running on the data directories. My proposal is to create > a separate directory for flushing memtables. Potentially we can use the same > methodology of keeping the commit log separate and minimize disk contention > against the critical function of the flushwriter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6357) Flush memtables to separate directory
[ https://issues.apache.org/jira/browse/CASSANDRA-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6357: -- Priority: Minor (was: Major) Fix Version/s: 2.0.6 Issue Type: New Feature (was: Improvement) > Flush memtables to separate directory > - > > Key: CASSANDRA-6357 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6357 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Patrick McFadin >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 2.0.6 > > Attachments: 6357-v2.txt, 6357.txt, > c6357-stress-write-latency-99th-1.png > > > Flush writers are a critical element for keeping a node healthy. When several > compactions run on systems with low performing data directories, IO becomes a > premium. Once the disk subsystem is saturated, write IO is blocked which will > cause flush writer threads to backup. Since memtables are large blocks of > memory in the JVM, too much blocking can cause excessive GC over time > degrading performance. In the worst case causing an OOM. > Since compaction is running on the data directories. My proposal is to create > a separate directory for flushing memtables. Potentially we can use the same > methodology of keeping the commit log separate and minimize disk contention > against the critical function of the flushwriter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6622) Streaming session failures during node replace using replace_address
[
https://issues.apache.org/jira/browse/CASSANDRA-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893755#comment-13893755
]
Brandon Williams commented on CASSANDRA-6622:
-
Can you try the patch from CASSANDRA-6658? I think that's the problem here,
the incorrect FD signal is sent with an extremely high phi value, tripping
StreamSession's convict with greater than two times the normal phi.
> Streaming session failures during node replace using replace_address
>
>
> Key: CASSANDRA-6622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6622
> Project: Cassandra
> Issue Type: Bug
> Environment: RHEL6, cassandra-2.0.4
>Reporter: Ravi Prasad
>Assignee: Brandon Williams
> Attachments: 0001-don-t-signal-restart-of-dead-states.txt,
> 6622-2.0.txt, logs.tgz
>
>
> When using replace_address, Gossiper ApplicationState is set to hibernate,
> which is a down state. We are seeing that the peer nodes are seeing streaming
> plan request even before the Gossiper on them marks the replacing node as
> dead. As a result, streaming on peer nodes convicts the replacing node by
> closing the stream handler.
> I think, making the StorageService thread on the replacing node, sleep for
> BROADCAST_INTERVAL before bootstrapping, would avoid this scenario.
> Relevant logs from peer node (see that the Gossiper on peer node mark the
> replacing node as down, 2 secs after the streaming init request):
> {noformat}
> INFO [STREAM-INIT-/x.x.x.x:46436] 2014-01-26 20:42:24,388
> StreamResultFuture.java (line 116) [Stream
> #5c6cd940-86ca-11e3-90a0-411b913c0e88] Received streaming plan for Bootstrap
>
> INFO [GossipTasks:1] 2014-01-26 20:42:25,240 StreamResultFuture.java (line
> 181) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Session with /x.x.x.x is
> complete
> WARN [GossipTasks:1] 2014-01-26 20:42:25,240 StreamResultFuture.java (line
> 210) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Stream failed
> INFO [GossipStage:1] 2014-01-26 20:42:25,242 Gossiper.java (line 850)
> InetAddress /x.x.x.x is now DOWN
> ERROR [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,766 StreamSession.java (line
> 410) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Streaming error occurred
> java.lang.RuntimeException: Outgoing stream handler has been closed
> at
> org.apache.cassandra.streaming.ConnectionHandler.sendMessage(ConnectionHandler.java:175)
> at
> org.apache.cassandra.streaming.StreamSession.prepare(StreamSession.java:436)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:358)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:293)
> at java.lang.Thread.run(Thread.java:722)
> INFO [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,768 StreamResultFuture.java
> (line 181) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Session with
> /x.x.x.x is complete
> WARN [STREAM-IN-/x.x.x.x] 2014-01-26 20:42:25,768 StreamResultFuture.java
> (line 210) [Stream #5c6cd940-86ca-11e3-90a0-411b913c0e88] Stream failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893751#comment-13893751 ] Pavel Yaskevich edited comment on CASSANDRA-6285 at 2/6/14 8:29 PM: [~ravilr] Can you try with the most recent release of hsha, version 0.3.3? Just remove the old jar and drop in new one, that should be sufficient. was (Author: xedin): [~ravilr] Can you try with the most recent release of hsha, version 0.3.3? Just remove the old jar and drop in new once, that should be sufficient. > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893751#comment-13893751 ] Pavel Yaskevich commented on CASSANDRA-6285: [~ravilr] Can you try with the most recent release of hsha, version 0.3.3? Just remove the old jar and drop in new once, that should be sufficient. > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6658) Nodes flap once at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-6658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-6658: Reviewer: Jonathan Ellis Fix Version/s: 2.0.6 > Nodes flap once at startup > -- > > Key: CASSANDRA-6658 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6658 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.6 > > Attachments: 6658-v2.txt, 6658.txt > > > Upon initially seeing each other, a node will mark another UP, then DOWN, > then UP again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6568) sstables incorrectly getting marked as "not live"
[
https://issues.apache.org/jira/browse/CASSANDRA-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893723#comment-13893723
]
Robert Coli commented on CASSANDRA-6568:
I've always wanted a JMX feature like that, currently the only way to do
something similar is to get keys from all the index files and test them with
getsstables. I've been interested in the context of manually copying SSTables
into the data directory when f/e using refresh. Probably not generally useful,
but excellent to see it being used to debug here.
> sstables incorrectly getting marked as "not live"
> -
>
> Key: CASSANDRA-6568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6568
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: 1.2.12 with several 1.2.13 patches
>Reporter: Chris Burroughs
>Assignee: Marcus Eriksson
> Fix For: 1.2.15, 2.0.6
>
> Attachments: 0001-add-jmx-method-to-get-non-active-sstables.patch
>
>
> {noformat}
> -rw-rw-r-- 14 cassandra cassandra 1.4G Nov 25 19:46
> /data/sstables/data/ks/cf/ks-cf-ic-402383-Data.db
> -rw-rw-r-- 14 cassandra cassandra 13G Nov 26 00:04
> /data/sstables/data/ks/cf/ks-cf-ic-402430-Data.db
> -rw-rw-r-- 14 cassandra cassandra 13G Nov 26 05:03
> /data/sstables/data/ks/cf/ks-cf-ic-405231-Data.db
> -rw-rw-r-- 31 cassandra cassandra 21G Nov 26 08:38
> /data/sstables/data/ks/cf/ks-cf-ic-405232-Data.db
> -rw-rw-r-- 2 cassandra cassandra 2.6G Dec 3 13:44
> /data/sstables/data/ks/cf/ks-cf-ic-434662-Data.db
> -rw-rw-r-- 14 cassandra cassandra 1.5G Dec 5 09:05
> /data/sstables/data/ks/cf/ks-cf-ic-438698-Data.db
> -rw-rw-r-- 2 cassandra cassandra 3.1G Dec 6 12:10
> /data/sstables/data/ks/cf/ks-cf-ic-440983-Data.db
> -rw-rw-r-- 2 cassandra cassandra 96M Dec 8 01:52
> /data/sstables/data/ks/cf/ks-cf-ic-444041-Data.db
> -rw-rw-r-- 2 cassandra cassandra 3.3G Dec 9 16:37
> /data/sstables/data/ks/cf/ks-cf-ic-451116-Data.db
> -rw-rw-r-- 2 cassandra cassandra 876M Dec 10 11:23
> /data/sstables/data/ks/cf/ks-cf-ic-453552-Data.db
> -rw-rw-r-- 2 cassandra cassandra 891M Dec 11 03:21
> /data/sstables/data/ks/cf/ks-cf-ic-454518-Data.db
> -rw-rw-r-- 2 cassandra cassandra 102M Dec 11 12:27
> /data/sstables/data/ks/cf/ks-cf-ic-455429-Data.db
> -rw-rw-r-- 2 cassandra cassandra 906M Dec 11 23:54
> /data/sstables/data/ks/cf/ks-cf-ic-455533-Data.db
> -rw-rw-r-- 1 cassandra cassandra 214M Dec 12 05:02
> /data/sstables/data/ks/cf/ks-cf-ic-456426-Data.db
> -rw-rw-r-- 1 cassandra cassandra 203M Dec 12 10:49
> /data/sstables/data/ks/cf/ks-cf-ic-456879-Data.db
> -rw-rw-r-- 1 cassandra cassandra 49M Dec 12 12:03
> /data/sstables/data/ks/cf/ks-cf-ic-456963-Data.db
> -rw-rw-r-- 18 cassandra cassandra 20G Dec 25 01:09
> /data/sstables/data/ks/cf/ks-cf-ic-507770-Data.db
> -rw-rw-r-- 3 cassandra cassandra 12G Jan 8 04:22
> /data/sstables/data/ks/cf/ks-cf-ic-567100-Data.db
> -rw-rw-r-- 3 cassandra cassandra 957M Jan 8 22:51
> /data/sstables/data/ks/cf/ks-cf-ic-569015-Data.db
> -rw-rw-r-- 2 cassandra cassandra 923M Jan 9 17:04
> /data/sstables/data/ks/cf/ks-cf-ic-571303-Data.db
> -rw-rw-r-- 1 cassandra cassandra 821M Jan 10 08:20
> /data/sstables/data/ks/cf/ks-cf-ic-574642-Data.db
> -rw-rw-r-- 1 cassandra cassandra 18M Jan 10 08:48
> /data/sstables/data/ks/cf/ks-cf-ic-574723-Data.db
> {noformat}
> I tried to do a user defined compaction on sstables from November and got "it
> is not an active sstable". Live sstable count from jmx was about 7 while on
> disk there were over 20. Live vs total size showed about a ~50 GiB
> difference.
> Forcing a gc from jconsole had no effect. However, restarting the node
> resulted in live sstables/bytes *increasing* to match what was on disk. User
> compaction could now compact the November sstables. This cluster was last
> restarted in mid December.
> I'm not sure what affect "not live" had on other operations of the cluster.
> From the logs it seems that the files were sent at least at some point as
> part of repair, but I don't know if they were being being used for read
> requests or not. Because the problem that got me looking in the first place
> was poor performance I suspect they were used for reads (and the reads were
> slow because so many sstables were being read). I presume based on their age
> at the least they were being excluded from compaction.
> I'm not aware of any isLive() or getRefCount() to problematically confirm
> which nodes have this problem. In this cluster almost all columns have a 14
> day TTL, based on the number of nodes with November sstables it appears to be
> occurring on a significant fraction of the nodes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6668) Inconsistent handling of row expiration using TTL in collections
[
https://issues.apache.org/jira/browse/CASSANDRA-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DOAN DuyHai updated CASSANDRA-6668:
---
Description:
The expiration of row when all TTLed columns have expired is inconsistent
Scenario 1)
{code:sql}
cqlsh:test> create table ttl_issue(id int primary key,collection set);
cqlsh:test> update ttl_issue USING TTL 2 set collection = collection +
{'test_2'} where id=10;
cqlsh:test> update ttl_issue USING TTL 3 set collection = collection +
{'test_3'} where id=10;
cqlsh:test> select * from ttl_issue;
id | collection
+--
10 | {'test_2', 'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+--
10 | {'test_2', 'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
10 | {'test_3'}
cqlsh:test> select * from ttl_issue;
cqlsh:test>
{code}
As we can see, after a few seconds, both columns of the collection are
expired. When all columns of the set have expired, the SELECT * FROM ttl_issue
*returns no result, meaning that the whole row has expired.*
Scenario 2)
{code:sql}
cqlsh:test> update ttl_issue USING TTL 3 set collection = collection +
{'test_3'} where id=11;
cqlsh:test> update ttl_issue USING TTL 1000 set collection = collection +
{'test_1000'} where id=11;
cqlsh:test> update ttl_issue set collection = collection - {'test_1000'} where
id=11;
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | null
{code}
In this second scenario. We add elements to the collection with TTL but then
remove one of them. *After a while, although all TTLed columns have expired,
the row is till there with only the primary key present.*
One should expect to get the same behavior as in scenario 1), e.g. the
complete row should expire.
I've also tried removing one element from collection using TTL 0
({code:sql}update ttl_issue USING TTL 0 set collection = collection -
{'test_1000'} where id=11;{code}) but the result is the same.
Quick guest: bug on row deletion marker for specific collection element
append/remove ?
was:
The expiration of row when all TTLed columns have expired is inconsistent
Scenario 1)
{code:sql}
cqlsh:test> create table ttl_issue(id int primary key,collection set);
cqlsh:test> update ttl_issue USING TTL 2 set collection = collection +
{'test_2'} where id=10;
cqlsh:test> update ttl_issue USING TTL 3 set collection = collection +
{'test_3'} where id=10;
cqlsh:test> select * from ttl_issue;
id | collection
+--
10 | {'test_2', 'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+--
10 | {'test_2', 'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
10 | {'test_3'}
cqlsh:test> select * from ttl_issue;
cqlsh:test>
{code}
As we can see, after a few seconds, both columns of the collection are
expired. When all columns of the set have expired, the SELECT * FROM ttl_issue
*returns no result, meaning that the whole row has expired.*
Scenario 2)
{code:sql}
cqlsh:test> update ttl_issue USING TTL 3 set collection = collection +
{'test_3'} where id=11;
cqlsh:test> update ttl_issue USING TTL 1000 set collection = collection +
{'test_1000'} where id=11;
cqlsh:test> update ttl_issue set collection = collection - {'test_1000'} where
id=11;
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | null
{code}
In this second scenario. We add elements to the collection with TTL but then
remove one of them. *After a while, although all TTLed columns have expired,
the row is till there with only the primary key present.*
One should expect to get the same behavior as in scenario 1), e.g. the
complete row should expire.
I've also tried removing one element from collection using TTL 0
({code:sql}update ttl_issue USING TTL 0 set collection = collection -
{'test_1000'} where id=11;{code}) but the result is the same.
> Inconsistent handling of row expiration using TTL in collections
>
>
> Key: CASSANDRA-6668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6668
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Apache Ca
[jira] [Created] (CASSANDRA-6668) Inconsistent handling of row expiration using TTL in collections
DOAN DuyHai created CASSANDRA-6668:
--
Summary: Inconsistent handling of row expiration using TTL in
collections
Key: CASSANDRA-6668
URL: https://issues.apache.org/jira/browse/CASSANDRA-6668
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Apache Cassandra 2.0.3
Apache Cassandra 1.2.8
CQLSH client 3.1.6
Reporter: DOAN DuyHai
Priority: Critical
The expiration of row when all TTLed columns have expired is inconsistent
Scenario 1)
{code:sql}
cqlsh:test> create table ttl_issue(id int primary key,collection set);
cqlsh:test> update ttl_issue USING TTL 2 set collection = collection +
{'test_2'} where id=10;
cqlsh:test> update ttl_issue USING TTL 3 set collection = collection +
{'test_3'} where id=10;
cqlsh:test> select * from ttl_issue;
id | collection
+--
10 | {'test_2', 'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+--
10 | {'test_2', 'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
10 | {'test_3'}
cqlsh:test> select * from ttl_issue;
cqlsh:test>
{code}
As we can see, after a few seconds, both columns of the collection are
expired. When all columns of the set have expired, the SELECT * FROM ttl_issue
*returns no result, meaning that the whole row has expired.*
Scenario 2)
{code:sql}
cqlsh:test> update ttl_issue USING TTL 3 set collection = collection +
{'test_3'} where id=11;
cqlsh:test> update ttl_issue USING TTL 1000 set collection = collection +
{'test_1000'} where id=11;
cqlsh:test> update ttl_issue set collection = collection - {'test_1000'} where
id=11;
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | {'test_3'}
cqlsh:test> select * from ttl_issue;
id | collection
+
11 | null
{code}
In this second scenario. We add elements to the collection with TTL but then
remove one of them. *After a while, although all TTLed columns have expired,
the row is till there with only the primary key present.*
One should expect to get the same behavior as in scenario 1), e.g. the
complete row should expire.
I've also tried removing one element from collection using TTL 0
({code:sql}update ttl_issue USING TTL 0 set collection = collection -
{'test_1000'} where id=11;{code}) but the result is the same.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6656) Exception logging
[
https://issues.apache.org/jira/browse/CASSANDRA-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893701#comment-13893701
]
Mikhail Stepura commented on CASSANDRA-6656:
[~d.yuan]
Thanks, but I still have a couple of comments for *DynamicCompositeType*
{code}
catch (CharacterCodingException ce)
{
// ByteBufferUtil.string failed.
// Log it here and we'll further throw an exception below since
comparator == null
logger.error("Failed when converting value to string. ", ce);
}
catch (Exception e)
{
// parse failed.
// Log it here and we'll further throw an exception below since
comparator == null
logger.error("Failed to parse value string: {}. Exception
follows. ", valueStr, e);
}
{code}
* The first {{logger.error()}} at CharacterCodingException will print out the
entire stack for the exception, because it's {{Logger.error(String,
Throwable)}} . You only print a message in all other cases. Why the full stack
trace here?
* The second one (at Exception) will not print exception at all. You are using
{{Logger.error(String, Object, Object)}} but provide only 1 formatting anchor
({}) for {{valueStr}} so exception will not be logged at all.
> Exception logging
> -
>
> Key: CASSANDRA-6656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6656
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
>Reporter: Ding Yuan
>Assignee: Ding Yuan
>Priority: Trivial
> Fix For: 2.1
>
> Attachments: trunk-6656-v2.txt, trunk-6656.txt
>
>
> Reporting a few cases where informative exceptions can be silently swallowed.
> Attaching a proposed patch.
> =
> Case 1
> Line: 95, File: "org/apache/cassandra/utils/Hex.java"
> An actual failure in the underlying constructor will be lost.
> Propose to log it.
> {noformat}
> try
> {
> s = stringConstructor.newInstance(0, c.length, c);
> + }
> + catch (InvocationTargetException ite) {
> + // The underlying constructor failed. Unwrapping the
> exception.
> + logger.info("Underlying constructor throws exception: ",
> ite.getCause());
> }
> catch (Exception e)
> {
> // Swallowing as we'll just use a copying constructor
> }
> return s == null ? new String(c) : s;
> {noformat}
> ==
> =
> Case 2
> Line: 192, File: "org/apache/cassandra/db/marshal/DynamicCompositeType.java"
> The actual cause of comparator error can be lost as it can fail in multiple
> locations.
> {noformat}
> AbstractType comparator = null;
> int header = getShortLength(bb);
> if ((header & 0x8000) == 0)
> {
> ByteBuffer value = getBytes(bb, header);
> try
> {
> comparator = TypeParser.parse(ByteBufferUtil.string(value));
> }
> catch (Exception e)
> {
> <--- can fail here
> // we'll deal with this below since comparator == null
> }
> }
> else
> {
> comparator = aliases.get((byte)(header & 0xFF));
> <--- can fail here
> }
> if (comparator == null)
> throw new MarshalException("Cannot find comparator for component
> " + i);
> {noformat}
> Propose to log the exception.
> ==
> =
> Case 3
> Line: 239, File: "org/apache/cassandra/tools/NodeProbe.java"
> Exception ignored in finally. Propose log them with debug or trace.
> {noformat}
> 232: finally
> 233: {
> 234: try
> 235: {
> 236: ssProxy.removeNotificationListener(runner);
> 236: ssProxy.removeNotificationListener(runner);
> 237: jmxc.removeConnectionNotificationListener(runner);
> 238: }
> 239: catch (Throwable ignored) {}
> 240: }
> {noformat}
> Similar case is at line 264 in the same file.
> ==
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CASSANDRA-4445) balance utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-4445. - Resolution: Fixed Reviewer: Jonathan Ellis Committed. > balance utility for vnodes > -- > > Key: CASSANDRA-4445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 1.2.0 beta 1 >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.6 > > Attachments: 4445.txt > > > We need a 'balance' utility similar to move without a token, in the cases > where entropy is not your friend and gives you an unbalanced cluster (I've > seen up to a 7% discrepancy myself) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
git commit: Add nodetool taketoken to relocate vnodes. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4445
Updated Branches:
refs/heads/trunk ac666706d -> d5c5734c8
Add nodetool taketoken to relocate vnodes.
Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4445
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d5c5734c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d5c5734c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d5c5734c
Branch: refs/heads/trunk
Commit: d5c5734c89a62869ee0c207306543b7f1e9cdf27
Parents: ac66670
Author: Brandon Williams
Authored: Thu Feb 6 13:22:57 2014 -0600
Committer: Brandon Williams
Committed: Thu Feb 6 13:22:57 2014 -0600
--
CHANGES.txt | 1 +
.../cassandra/service/StorageService.java | 3 +++
.../org/apache/cassandra/tools/NodeProbe.java | 5
.../org/apache/cassandra/tools/NodeTool.java| 25 +++-
4 files changed, 33 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d5c5734c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 6e1b984..86e576c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -29,6 +29,7 @@
* Add option to use row cache with a given amount of rows (CASSANDRA-5357)
2.0.6
+ * Add nodetool taketoken to relocate vnodes (CASSANDRA-4445)
* Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645)
* Expose bulk loading progress over JMX (CASSANDRA-4757)
* Correctly handle null with IF conditions and TTL (CASSANDRA-6623)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d5c5734c/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index d891a59..4d6e13f 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3129,6 +3129,9 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
for (String srcT : srcTokens)
{
getPartitioner().getTokenFactory().validate(srcT);
+Token token =
getPartitioner().getTokenFactory().fromString(srcT);
+if
(tokenMetadata.getTokens(tokenMetadata.getEndpoint(token)).size() < 2)
+throw new IOException("Cannot relocate " + srcT + ";
source node would have no tokens left");
tokens.add(getPartitioner().getTokenFactory().fromString(srcT));
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d5c5734c/src/java/org/apache/cassandra/tools/NodeProbe.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java
b/src/java/org/apache/cassandra/tools/NodeProbe.java
index e44b576..d874ef0 100644
--- a/src/java/org/apache/cassandra/tools/NodeProbe.java
+++ b/src/java/org/apache/cassandra/tools/NodeProbe.java
@@ -487,6 +487,11 @@ public class NodeProbe implements AutoCloseable
ssProxy.move(newToken);
}
+public void takeTokens(List tokens) throws IOException
+{
+ssProxy.relocate(tokens);
+}
+
public void removeNode(String token)
{
ssProxy.removeNode(token);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d5c5734c/src/java/org/apache/cassandra/tools/NodeTool.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeTool.java
b/src/java/org/apache/cassandra/tools/NodeTool.java
index cc94b35..10e581c 100644
--- a/src/java/org/apache/cassandra/tools/NodeTool.java
+++ b/src/java/org/apache/cassandra/tools/NodeTool.java
@@ -138,7 +138,8 @@ public class NodeTool
DisableHandoff.class,
Drain.class,
TruncateHints.class,
-TpStats.class
+TpStats.class,
+TakeToken.class
);
Cli parser = Cli.builder("nodetool")
@@ -1360,6 +1361,26 @@ public class NodeTool
}
}
+@Command(name = "taketoken", description = "Move the token(s) from the
existing owner(s) to this node. For vnodes only. Use to escape negative
tokens.")
+public static class TakeToken extends NodeToolCmd
+{
+@Arguments(usage = "", description = "Token(s) to take",
required = true)
+private List tokens = new ArrayList();
+
+@Override
+public void execute(NodeProbe probe)
+{
+try
+{
+probe.takeTokens(tokens);
+}
+catch (IOException e)
+{
+
[2/3] git commit: Add nodetool taketoken to relocate vnodes. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4445
Add nodetool taketoken to relocate vnodes.
Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4445
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5f64af63
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5f64af63
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5f64af63
Branch: refs/heads/trunk
Commit: 5f64af63ae063c055c214d8925098f34f4111474
Parents: 2103646
Author: Brandon Williams
Authored: Thu Feb 6 13:00:24 2014 -0600
Committer: Brandon Williams
Committed: Thu Feb 6 13:00:24 2014 -0600
--
CHANGES.txt| 1 +
src/java/org/apache/cassandra/service/StorageService.java | 3 +++
src/java/org/apache/cassandra/tools/NodeCmd.java | 6 ++
src/java/org/apache/cassandra/tools/NodeProbe.java | 5 +
src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml | 3 +++
5 files changed, 18 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ceb25c3..6e3c2c2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.6
+ * Add nodetool taketoken to relocate vnodes (CASSANDRA-4445)
* Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645)
* Improve nodetool cfhistograms formatting (CASSANDRA-6360)
* Expose bulk loading progress over JMX (CASSANDRA-4757)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 26846e7..e181c44 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3098,6 +3098,9 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
for (String srcT : srcTokens)
{
getPartitioner().getTokenFactory().validate(srcT);
+Token token =
getPartitioner().getTokenFactory().fromString(srcT);
+if
(tokenMetadata.getTokens(tokenMetadata.getEndpoint(token)).size() < 2)
+throw new IOException("Cannot relocate " + srcT + ";
source node would have no tokens left");
tokens.add(getPartitioner().getTokenFactory().fromString(srcT));
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/src/java/org/apache/cassandra/tools/NodeCmd.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java
b/src/java/org/apache/cassandra/tools/NodeCmd.java
index fd7b69b..f3cd563 100644
--- a/src/java/org/apache/cassandra/tools/NodeCmd.java
+++ b/src/java/org/apache/cassandra/tools/NodeCmd.java
@@ -169,6 +169,7 @@ public class NodeCmd
STATUSTHRIFT,
STOP,
STOPDAEMON,
+TAKETOKEN,
TPSTATS,
TRUNCATEHINTS,
UPGRADESSTABLES,
@@ -1315,6 +1316,11 @@ public class NodeCmd
probe.setTraceProbability(Double.parseDouble(arguments[0]));
break;
+case TAKETOKEN:
+if (arguments.length < 1) { badUse("Must supply at least
one token to take"); }
+probe.takeTokens(arguments);
+break;
+
case REBUILD :
if (arguments.length > 1) { badUse("Too many arguments.");
}
probe.rebuild(arguments.length == 1 ? arguments[0] : null);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/src/java/org/apache/cassandra/tools/NodeProbe.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java
b/src/java/org/apache/cassandra/tools/NodeProbe.java
index 0fbb12a..ffd6203 100644
--- a/src/java/org/apache/cassandra/tools/NodeProbe.java
+++ b/src/java/org/apache/cassandra/tools/NodeProbe.java
@@ -471,6 +471,11 @@ public class NodeProbe
ssProxy.move(newToken);
}
+public void takeTokens(String[] tokens) throws IOException
+{
+ssProxy.relocate(Arrays.asList(tokens));
+}
+
public void removeNode(String token)
{
ssProxy.removeNode(token);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml
--
diff --git a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml
b/src/resour
[1/3] git commit: Add nodetool taketoken to relocate vnodes. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4445
Updated Branches:
refs/heads/cassandra-2.0 21036468c -> 5f64af63a
refs/heads/trunk ad8cea4ea -> ac666706d
Add nodetool taketoken to relocate vnodes.
Patch by brandonwilliams reviewed by jbellis for CASSANDRA-4445
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5f64af63
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5f64af63
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5f64af63
Branch: refs/heads/cassandra-2.0
Commit: 5f64af63ae063c055c214d8925098f34f4111474
Parents: 2103646
Author: Brandon Williams
Authored: Thu Feb 6 13:00:24 2014 -0600
Committer: Brandon Williams
Committed: Thu Feb 6 13:00:24 2014 -0600
--
CHANGES.txt| 1 +
src/java/org/apache/cassandra/service/StorageService.java | 3 +++
src/java/org/apache/cassandra/tools/NodeCmd.java | 6 ++
src/java/org/apache/cassandra/tools/NodeProbe.java | 5 +
src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml | 3 +++
5 files changed, 18 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ceb25c3..6e3c2c2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.6
+ * Add nodetool taketoken to relocate vnodes (CASSANDRA-4445)
* Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645)
* Improve nodetool cfhistograms formatting (CASSANDRA-6360)
* Expose bulk loading progress over JMX (CASSANDRA-4757)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 26846e7..e181c44 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3098,6 +3098,9 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
for (String srcT : srcTokens)
{
getPartitioner().getTokenFactory().validate(srcT);
+Token token =
getPartitioner().getTokenFactory().fromString(srcT);
+if
(tokenMetadata.getTokens(tokenMetadata.getEndpoint(token)).size() < 2)
+throw new IOException("Cannot relocate " + srcT + ";
source node would have no tokens left");
tokens.add(getPartitioner().getTokenFactory().fromString(srcT));
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/src/java/org/apache/cassandra/tools/NodeCmd.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java
b/src/java/org/apache/cassandra/tools/NodeCmd.java
index fd7b69b..f3cd563 100644
--- a/src/java/org/apache/cassandra/tools/NodeCmd.java
+++ b/src/java/org/apache/cassandra/tools/NodeCmd.java
@@ -169,6 +169,7 @@ public class NodeCmd
STATUSTHRIFT,
STOP,
STOPDAEMON,
+TAKETOKEN,
TPSTATS,
TRUNCATEHINTS,
UPGRADESSTABLES,
@@ -1315,6 +1316,11 @@ public class NodeCmd
probe.setTraceProbability(Double.parseDouble(arguments[0]));
break;
+case TAKETOKEN:
+if (arguments.length < 1) { badUse("Must supply at least
one token to take"); }
+probe.takeTokens(arguments);
+break;
+
case REBUILD :
if (arguments.length > 1) { badUse("Too many arguments.");
}
probe.rebuild(arguments.length == 1 ? arguments[0] : null);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/src/java/org/apache/cassandra/tools/NodeProbe.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java
b/src/java/org/apache/cassandra/tools/NodeProbe.java
index 0fbb12a..ffd6203 100644
--- a/src/java/org/apache/cassandra/tools/NodeProbe.java
+++ b/src/java/org/apache/cassandra/tools/NodeProbe.java
@@ -471,6 +471,11 @@ public class NodeProbe
ssProxy.move(newToken);
}
+public void takeTokens(String[] tokens) throws IOException
+{
+ssProxy.relocate(Arrays.asList(tokens));
+}
+
public void removeNode(String token)
{
ssProxy.removeNode(token);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5f64af63/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml
[3/3] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ac666706 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ac666706 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ac666706 Branch: refs/heads/trunk Commit: ac666706d7b8ab67fb14423f02471d37f5e3b226 Parents: ad8cea4 5f64af6 Author: Brandon Williams Authored: Thu Feb 6 13:11:40 2014 -0600 Committer: Brandon Williams Committed: Thu Feb 6 13:11:40 2014 -0600 -- --
[jira] [Commented] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893660#comment-13893660 ] Ravi Prasad commented on CASSANDRA-6285: cc [~xedin] we were also seeing such random out of place partitions/rows in sstables (rows not hashing to the node) while using disruptor based hsha thrift server, causing compaction to fail with out of order keys. this used to happen on freshly flushed sstables in L0. We also used to see thrift validation failing on some columns while reading back. We don't see these after switching back to sync server. > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
git commit: CHANGES
Updated Branches: refs/heads/trunk ca00f622a -> ad8cea4ea CHANGES Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ad8cea4e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ad8cea4e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ad8cea4e Branch: refs/heads/trunk Commit: ad8cea4ea5c6d6e8dbee346f11de2f376a209031 Parents: ca00f62 Author: Jonathan Ellis Authored: Thu Feb 6 12:55:10 2014 -0600 Committer: Jonathan Ellis Committed: Thu Feb 6 12:55:13 2014 -0600 -- CHANGES.txt | 1 - 1 file changed, 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ad8cea4e/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 75c80c2..6e1b984 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -30,7 +30,6 @@ 2.0.6 * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) - * Improve nodetool cfhistograms formatting (CASSANDRA-6360) * Expose bulk loading progress over JMX (CASSANDRA-4757) * Correctly handle null with IF conditions and TTL (CASSANDRA-6623) * Account for range/row tombstones in tombstone drop
[jira] [Commented] (CASSANDRA-4445) balance utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893651#comment-13893651 ] Jonathan Ellis commented on CASSANDRA-4445: --- +1 > balance utility for vnodes > -- > > Key: CASSANDRA-4445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 1.2.0 beta 1 >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.6 > > Attachments: 4445.txt > > > We need a 'balance' utility similar to move without a token, in the cases > where entropy is not your friend and gives you an unbalanced cluster (I've > seen up to a 7% discrepancy myself) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6360) Make nodetool cfhistograms output easily understandable
[ https://issues.apache.org/jira/browse/CASSANDRA-6360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893652#comment-13893652 ] Tyler Hobbs commented on CASSANDRA-6360: bq. Committed to 2.0; can you give me a patch against trunk? Thanks. We're leaving trunk as-is, since it has already been improved in a different way. > Make nodetool cfhistograms output easily understandable > --- > > Key: CASSANDRA-6360 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6360 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs >Priority: Trivial > Attachments: 6360-2.0-v2.patch, 6360-2.0.patch > > > Almost nobody understands the cfhistograms output without googling it. By > default, we shouldn't share an axis across all metrics. We can still provide > the current format with a --compact option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-4445) balance utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4445: Attachment: 4445.txt You'd _almost_ get a very weird way to decommission a node, except the system table would throw an assertion. Updated patch won't let you relocate a token if the source node doesn't have more than one token. > balance utility for vnodes > -- > > Key: CASSANDRA-4445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 1.2.0 beta 1 >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.6 > > Attachments: 4445.txt > > > We need a 'balance' utility similar to move without a token, in the cases > where entropy is not your friend and gives you an unbalanced cluster (I've > seen up to a 7% discrepancy myself) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-4445) balance utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4445: Attachment: (was: 4445.txt) > balance utility for vnodes > -- > > Key: CASSANDRA-4445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 1.2.0 beta 1 >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.6 > > > We need a 'balance' utility similar to move without a token, in the cases > where entropy is not your friend and gives you an unbalanced cluster (I've > seen up to a 7% discrepancy myself) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6667) Mean cells per sstable is calculated incorrectly
[ https://issues.apache.org/jira/browse/CASSANDRA-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893632#comment-13893632 ] Jonathan Ellis commented on CASSANDRA-6667: --- (Tagged [~krummas] for review.) > Mean cells per sstable is calculated incorrectly > > > Key: CASSANDRA-6667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6667 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 1.2.16, 2.0.6 > > Attachments: 6667.txt > > > We currently take the average of the mean for each partition, rather than > correctly weighting by cell count. This affects hint paging as well as index > selectivity calculation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6667) Mean cells per sstable is calculated incorrectly
Jonathan Ellis created CASSANDRA-6667: - Summary: Mean cells per sstable is calculated incorrectly Key: CASSANDRA-6667 URL: https://issues.apache.org/jira/browse/CASSANDRA-6667 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Priority: Minor We currently take the average of the mean for each partition, rather than correctly weighting by cell count. This affects hint paging as well as index selectivity calculation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6667) Mean cells per sstable is calculated incorrectly
[ https://issues.apache.org/jira/browse/CASSANDRA-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6667: -- Attachment: 6667.txt > Mean cells per sstable is calculated incorrectly > > > Key: CASSANDRA-6667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6667 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Priority: Minor > Attachments: 6667.txt > > > We currently take the average of the mean for each partition, rather than > correctly weighting by cell count. This affects hint paging as well as index > selectivity calculation. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-4445) balance utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893615#comment-13893615 ] Jonathan Ellis commented on CASSANDRA-4445: --- What happens if I run this against a non-vnode cluster? > balance utility for vnodes > -- > > Key: CASSANDRA-4445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 1.2.0 beta 1 >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.6 > > Attachments: 4445.txt > > > We need a 'balance' utility similar to move without a token, in the cases > where entropy is not your friend and gives you an unbalanced cluster (I've > seen up to a 7% discrepancy myself) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-4445) balance utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4445: Attachment: 4445.txt Since we already expose everything we need via jmx, simple patch to expose 'taketoken' to nodetool, which will relocate the tokens from wherever they exist to the node it is called against. > balance utility for vnodes > -- > > Key: CASSANDRA-4445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 > Project: Cassandra > Issue Type: New Feature > Components: Core >Affects Versions: 1.2.0 beta 1 >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > Fix For: 2.0.6 > > Attachments: 4445.txt > > > We need a 'balance' utility similar to move without a token, in the cases > where entropy is not your friend and gives you an unbalanced cluster (I've > seen up to a 7% discrepancy myself) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CASSANDRA-6575) By default, Cassandra should refuse to start if JNA can't be initialized properly
[
https://issues.apache.org/jira/browse/CASSANDRA-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893604#comment-13893604
]
Clément Lardeur edited comment on CASSANDRA-6575 at 2/6/14 6:08 PM:
I have submitted a new patch that take into account a linking error during the
registering of the native C library.
If an {{UnsatisfiedLinkError}} occurred during the initialization, the CLibrary
should still be available.
When you call a native method you always call {{tryXXX()}} that ignore any
linking error.
This way Cassandra should refused to start if and only if JNA is not present in
the classpath or is obsolete.
was (Author: clardeur):
I have submitted a new patch that take into account a linking error during the
registering of the native C library.
If an {{UnsatisfiedLinkError}} occurred during the initialization, the CLibrary
should still be available.
When you call a native method you always call {{tryXXX()}} that ignore any
linking error.
This way Cassandra should refuse to start if and only if JNA is not present in
the classpath or is obsolete.
> By default, Cassandra should refuse to start if JNA can't be initialized
> properly
> -
>
> Key: CASSANDRA-6575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6575
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Tupshin Harper
>Assignee: Clément Lardeur
>Priority: Minor
> Labels: lhf
> Fix For: 2.1
>
> Attachments: trunk-6575-v2.patch, trunk-6575-v3.patch,
> trunk-6575.patch
>
>
> Failure to have JNA working properly is such a common undetected problem that
> it would be far preferable to have Cassandra refuse to startup unless JNA is
> initialized. In theory, this should be much less of a problem with Cassandra
> 2.1 due to CASSANDRA-5872, but even there, it might fail due to native lib
> problems, or might otherwise be misconfigured. A yaml override, such as
> boot_without_jna would allow the deliberate overriding of this policy.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6575) By default, Cassandra should refuse to start if JNA can't be initialized properly
[
https://issues.apache.org/jira/browse/CASSANDRA-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clément Lardeur updated CASSANDRA-6575:
---
Attachment: trunk-6575-v3.patch
I have submitted a new patch that take into account a linking error during the
registering of the native C library.
If an {{UnsatisfiedLinkError}} occurred during the initialization, the CLibrary
should still be available.
When you call a native method you always call {{tryXXX()}} that ignore any
linking error.
This way Cassandra should refuse to start if and only if JNA is not present in
the classpath or is obsolete.
> By default, Cassandra should refuse to start if JNA can't be initialized
> properly
> -
>
> Key: CASSANDRA-6575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6575
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Tupshin Harper
>Assignee: Clément Lardeur
>Priority: Minor
> Labels: lhf
> Fix For: 2.1
>
> Attachments: trunk-6575-v2.patch, trunk-6575-v3.patch,
> trunk-6575.patch
>
>
> Failure to have JNA working properly is such a common undetected problem that
> it would be far preferable to have Cassandra refuse to startup unless JNA is
> initialized. In theory, this should be much less of a problem with Cassandra
> 2.1 due to CASSANDRA-5872, but even there, it might fail due to native lib
> problems, or might otherwise be misconfigured. A yaml override, such as
> boot_without_jna would allow the deliberate overriding of this policy.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-4851) CQL3: improve support for paginating over composites
[
https://issues.apache.org/jira/browse/CASSANDRA-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893599#comment-13893599
]
Sylvain Lebresne commented on CASSANDRA-4851:
-
bq. Is that a leftover from a previous iteration?
They are, sorry about forgetting to clean that up. I'll remove on commit or on
the next iteration, whatever comes first.
> CQL3: improve support for paginating over composites
>
>
> Key: CASSANDRA-4851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4851
> Project: Cassandra
> Issue Type: Improvement
> Components: API
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 2.0.6
>
> Attachments: 4851.txt
>
>
> Consider the following table:
> {noformat}
> CREATE TABLE test (
> k int,
> c1 int,
> c2 int,
> PRIMARY KEY (k, c1, c2)
> )
> {noformat}
> with the following data:
> {noformat}
> k | c1 | c2
>
> 0 | 0 | 0
> 0 | 0 | 1
> 0 | 1 | 0
> 0 | 1 | 1
> {noformat}
> Currently, CQL3 allows to slice over either c1 or c2:
> {noformat}
> SELECT * FROM test WHERE k = 0 AND c1 > 0 AND c1 < 2
> SELECT * FROM test WHERE k = 0 AND c1 = 1 AND c2 > 0 AND c2 < 2
> {noformat}
> but you cannot express a query that return the 3 last records. Indeed, for
> that you would need to do a query like say:
> {noformat}
> SELECT * FROM test WHERE k = 0 AND ((c1 = 0 AND c2 > 0) OR c2 > 0)
> {noformat}
> but we don't support that.
> This can make it hard to paginate over say all records for {{k = 0}} (I'm
> saying "can" because if the value for c2 cannot be very large, an easy
> workaround could be to paginate by entire value of c1, which you can do).
> For the case where you only paginate to avoid OOMing on a query,
> CASSANDRA-4415 will that and is probably the best solution. However, there
> may be case where the pagination is say user (as in, the user of your
> application) triggered.
> I note that one solution would be to add the OR support at least in case like
> the one above. That's definitively doable but on the other side, we won't be
> able to support full-blown OR, so it may not be very natural that we support
> seemingly random combination of OR and not others.
> Another solution would be to allow the following syntax:
> {noformat}
> SELECT * FROM test WHERE k = 0 AND (c1, c2) > (0, 0)
> {noformat}
> which would literally mean that you want records where the values of c1 and
> c2 taken as a tuple is lexicographically greater than the tuple (0, 0). This
> is less SQL-like (though maybe some SQL store have that, it's a fairly thing
> to have imo?), but would be much simpler to implement and probably to use too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6561) Static columns in CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-6561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893596#comment-13893596
]
Sylvain Lebresne commented on CASSANDRA-6561:
-
Pushed rebased and generally updated version at
https://github.com/pcmanus/cassandra/commits/6561-3.
One important change of this version is that I realized that the "trick" of
reusing the end-of-component in a composite was not working, messing with the
end-of-component was problematic for slices and some edge cases were not
working properly. The new version uses a somewhat more direct approach of
prefixing the name of static columns by 0x, and CompositeType checks for
that. The reason for that value is that it was actually not possible for an
existing composite name to have a first component of 65535 bytes, since the
full cell name is limited to that size and a composite name has at least 3
bytes more that it's component (even if it has only one of them).
Another point that is worth noting is that the new patch now properly handles
any mix of conditions in batches (as long as it's only on one partition),
include {{IF NOT EXISTS}} ones (which was not the case of the previous version).
bq. I'd prefer new ColumnDefinition.Kind.STATIC
I switched to that with the last commit on the branch above. I kind of agree
that it's probably a little cleaner, though it's worth noting that it's not
necessarily simpler because that kind of mean separating regular and static
columns while there is many cases where they are treated the same way. Anyway,
not a huge deal either. I also ended-up renaming a bunch of stuffs in
CFDefinition to keep things sane. Admittingly not all the renames were
absolutely necessary for this patch but well, they make things cleaner.
Haven't fixed cqlsh describe yet as cqlsh is not the code I know the best but I
can have a look at it a
> Static columns in CQL3
> --
>
> Key: CASSANDRA-6561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6561
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0.6
>
>
> I'd like to suggest the following idea for adding "static" columns to CQL3.
> I'll note that the basic idea has been suggested by jhalliday on irc but the
> rest of the details are mine and I should be blamed for anything stupid in
> what follows.
> Let me start with a rational: there is 2 main family of CF that have been
> historically used in Thrift: static ones and dynamic ones. CQL3 handles both
> family through the presence or not of clustering columns. There is however
> some cases where mixing both behavior has its use. I like to think of those
> use cases as 3 broad category:
> # to denormalize small amounts of not-entirely-static data in otherwise
> static entities. It's say "tags" for a product or "custom properties" in a
> user profile. This is why we've added CQL3 collections. Importantly, this is
> the *only* use case for which collections are meant (which doesn't diminishes
> their usefulness imo, and I wouldn't disagree that we've maybe not
> communicated this too well).
> # to optimize fetching both a static entity and related dynamic ones. Say you
> have blog posts, and each post has associated comments (chronologically
> ordered). *And* say that a very common query is "fetch a post and its 50 last
> comments". In that case, it *might* be beneficial to store a blog post
> (static entity) in the same underlying CF than it's comments for performance
> reason. So that "fetch a post and it's 50 last comments" is just one slice
> internally.
> # you want to CAS rows of a dynamic partition based on some partition
> condition. This is the same use case than why CASSANDRA-5633 exists for.
> As said above, 1) is already covered by collections, but 2) and 3) are not
> (and
> I strongly believe collections are not the right fit, API wise, for those).
> Also, note that I don't want to underestimate the usefulness of 2). In most
> cases, using a separate table for the blog posts and the comments is The
> Right Solution, and trying to do 2) is premature optimisation. Yet, when used
> properly, that kind of optimisation can make a difference, so I think having
> a relatively native solution for it in CQL3 could make sense.
> Regarding 3), though CASSANDRA-5633 would provide one solution for it, I have
> the feeling that static columns actually are a more natural approach (in term
> of API). That's arguably more of a personal opinion/feeling though.
> So long story short, CQL3 lacks a way to mix both some "static" and "dynamic"
> rows in the same partition of the same CQL3 table, and I think such a tool
> could have it's use.
> The proposal is thus to allow "static" columns. Static columns would o
[jira] [Commented] (CASSANDRA-6285) LCS compaction failing with Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893563#comment-13893563 ] Brandon Kearby commented on CASSANDRA-6285: --- [~thobbs], The odd thing is that with hsha, it works with one node. When we have two or more nodes in the cluster, it starts getting these errors. > LCS compaction failing with Exception > - > > Key: CASSANDRA-6285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6285 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: 4 nodes, shortly updated from 1.2.11 to 2.0.2 >Reporter: David Sauer >Assignee: Tyler Hobbs > Fix For: 2.0.6 > > Attachments: compaction_test.py > > > After altering everything to LCS the table OpsCenter.rollups60 amd one other > none OpsCenter-Table got stuck with everything hanging around in L0. > The compaction started and ran until the logs showed this: > ERROR [CompactionExecutor:111] 2013-11-01 19:14:53,865 CassandraDaemon.java > (line 187) Exception in thread Thread[CompactionExecutor:111,1,RMI Runtime] > java.lang.RuntimeException: Last written key > DecoratedKey(1326283851463420237, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574426c6f6f6d46696c746572537061636555736564) > >= current key DecoratedKey(954210699457429663, > 37382e34362e3132382e3139382d6a7576616c69735f6e6f72785f696e6465785f323031335f31305f30382d63616368655f646f63756d656e74736c6f6f6b75702d676574546f74616c4469736b5370616365557365640b0f) > writing into > /var/lib/cassandra/data/OpsCenter/rollups60/OpsCenter-rollups60-tmp-jb-58656-Data.db > at > org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:141) > at > org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:164) > at > org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:160) > at > org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:296) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > 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:724) > Moving back to STC worked to keep the compactions running. > Especialy my own Table i would like to move to LCS. > After a major compaction with STC the move to LCS fails with the same > Exception. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6568) sstables incorrectly getting marked as "not live"
[
https://issues.apache.org/jira/browse/CASSANDRA-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-6568:
---
Attachment: 0001-add-jmx-method-to-get-non-active-sstables.patch
Been trying to reproduce this today, but without any luck
Attaching patch that exposes a JMX method that shows the difference between
files on disk and the sstables Cassandra knows about, should perhaps help us
find the issue.
> sstables incorrectly getting marked as "not live"
> -
>
> Key: CASSANDRA-6568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6568
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: 1.2.12 with several 1.2.13 patches
>Reporter: Chris Burroughs
>Assignee: Marcus Eriksson
> Fix For: 1.2.15, 2.0.6
>
> Attachments: 0001-add-jmx-method-to-get-non-active-sstables.patch
>
>
> {noformat}
> -rw-rw-r-- 14 cassandra cassandra 1.4G Nov 25 19:46
> /data/sstables/data/ks/cf/ks-cf-ic-402383-Data.db
> -rw-rw-r-- 14 cassandra cassandra 13G Nov 26 00:04
> /data/sstables/data/ks/cf/ks-cf-ic-402430-Data.db
> -rw-rw-r-- 14 cassandra cassandra 13G Nov 26 05:03
> /data/sstables/data/ks/cf/ks-cf-ic-405231-Data.db
> -rw-rw-r-- 31 cassandra cassandra 21G Nov 26 08:38
> /data/sstables/data/ks/cf/ks-cf-ic-405232-Data.db
> -rw-rw-r-- 2 cassandra cassandra 2.6G Dec 3 13:44
> /data/sstables/data/ks/cf/ks-cf-ic-434662-Data.db
> -rw-rw-r-- 14 cassandra cassandra 1.5G Dec 5 09:05
> /data/sstables/data/ks/cf/ks-cf-ic-438698-Data.db
> -rw-rw-r-- 2 cassandra cassandra 3.1G Dec 6 12:10
> /data/sstables/data/ks/cf/ks-cf-ic-440983-Data.db
> -rw-rw-r-- 2 cassandra cassandra 96M Dec 8 01:52
> /data/sstables/data/ks/cf/ks-cf-ic-444041-Data.db
> -rw-rw-r-- 2 cassandra cassandra 3.3G Dec 9 16:37
> /data/sstables/data/ks/cf/ks-cf-ic-451116-Data.db
> -rw-rw-r-- 2 cassandra cassandra 876M Dec 10 11:23
> /data/sstables/data/ks/cf/ks-cf-ic-453552-Data.db
> -rw-rw-r-- 2 cassandra cassandra 891M Dec 11 03:21
> /data/sstables/data/ks/cf/ks-cf-ic-454518-Data.db
> -rw-rw-r-- 2 cassandra cassandra 102M Dec 11 12:27
> /data/sstables/data/ks/cf/ks-cf-ic-455429-Data.db
> -rw-rw-r-- 2 cassandra cassandra 906M Dec 11 23:54
> /data/sstables/data/ks/cf/ks-cf-ic-455533-Data.db
> -rw-rw-r-- 1 cassandra cassandra 214M Dec 12 05:02
> /data/sstables/data/ks/cf/ks-cf-ic-456426-Data.db
> -rw-rw-r-- 1 cassandra cassandra 203M Dec 12 10:49
> /data/sstables/data/ks/cf/ks-cf-ic-456879-Data.db
> -rw-rw-r-- 1 cassandra cassandra 49M Dec 12 12:03
> /data/sstables/data/ks/cf/ks-cf-ic-456963-Data.db
> -rw-rw-r-- 18 cassandra cassandra 20G Dec 25 01:09
> /data/sstables/data/ks/cf/ks-cf-ic-507770-Data.db
> -rw-rw-r-- 3 cassandra cassandra 12G Jan 8 04:22
> /data/sstables/data/ks/cf/ks-cf-ic-567100-Data.db
> -rw-rw-r-- 3 cassandra cassandra 957M Jan 8 22:51
> /data/sstables/data/ks/cf/ks-cf-ic-569015-Data.db
> -rw-rw-r-- 2 cassandra cassandra 923M Jan 9 17:04
> /data/sstables/data/ks/cf/ks-cf-ic-571303-Data.db
> -rw-rw-r-- 1 cassandra cassandra 821M Jan 10 08:20
> /data/sstables/data/ks/cf/ks-cf-ic-574642-Data.db
> -rw-rw-r-- 1 cassandra cassandra 18M Jan 10 08:48
> /data/sstables/data/ks/cf/ks-cf-ic-574723-Data.db
> {noformat}
> I tried to do a user defined compaction on sstables from November and got "it
> is not an active sstable". Live sstable count from jmx was about 7 while on
> disk there were over 20. Live vs total size showed about a ~50 GiB
> difference.
> Forcing a gc from jconsole had no effect. However, restarting the node
> resulted in live sstables/bytes *increasing* to match what was on disk. User
> compaction could now compact the November sstables. This cluster was last
> restarted in mid December.
> I'm not sure what affect "not live" had on other operations of the cluster.
> From the logs it seems that the files were sent at least at some point as
> part of repair, but I don't know if they were being being used for read
> requests or not. Because the problem that got me looking in the first place
> was poor performance I suspect they were used for reads (and the reads were
> slow because so many sstables were being read). I presume based on their age
> at the least they were being excluded from compaction.
> I'm not aware of any isLive() or getRefCount() to problematically confirm
> which nodes have this problem. In this cluster almost all columns have a 14
> day TTL, based on the number of nodes with November sstables it appears to be
> occurring on a significant fraction of the nodes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
git commit: nope 6522 was not merged from 1.2
Updated Branches: refs/heads/cassandra-2.0 933df01d2 -> 21036468c nope 6522 was not merged from 1.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/21036468 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/21036468 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/21036468 Branch: refs/heads/cassandra-2.0 Commit: 21036468c5304a5aac45a0f4f7db2580e4c91e24 Parents: 933df01 Author: Marcus Eriksson Authored: Thu Feb 6 18:05:39 2014 +0100 Committer: Marcus Eriksson Committed: Thu Feb 6 18:05:39 2014 +0100 -- CHANGES.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/21036468/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 8148083..ceb25c3 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -3,11 +3,11 @@ * Improve nodetool cfhistograms formatting (CASSANDRA-6360) * Expose bulk loading progress over JMX (CASSANDRA-4757) * Correctly handle null with IF conditions and TTL (CASSANDRA-6623) + * Account for range/row tombstones in tombstone drop + time histogram (CASSANDRA-6522) Merged from 1.2: * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) * Fix partition and range deletes not triggering flush (CASSANDRA-6655) - * Account for range/row tombstones in tombstone drop - time histogram (CASSANDRA-6522) 2.0.5 * Reduce garbage generated by bloom filter lookups (CASSANDRA-6609)
[1/2] git commit: nope 6522 was not merged from 1.2
Updated Branches: refs/heads/trunk 300b02633 -> ca00f622a nope 6522 was not merged from 1.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/21036468 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/21036468 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/21036468 Branch: refs/heads/trunk Commit: 21036468c5304a5aac45a0f4f7db2580e4c91e24 Parents: 933df01 Author: Marcus Eriksson Authored: Thu Feb 6 18:05:39 2014 +0100 Committer: Marcus Eriksson Committed: Thu Feb 6 18:05:39 2014 +0100 -- CHANGES.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/21036468/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 8148083..ceb25c3 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -3,11 +3,11 @@ * Improve nodetool cfhistograms formatting (CASSANDRA-6360) * Expose bulk loading progress over JMX (CASSANDRA-4757) * Correctly handle null with IF conditions and TTL (CASSANDRA-6623) + * Account for range/row tombstones in tombstone drop + time histogram (CASSANDRA-6522) Merged from 1.2: * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) * Fix partition and range deletes not triggering flush (CASSANDRA-6655) - * Account for range/row tombstones in tombstone drop - time histogram (CASSANDRA-6522) 2.0.5 * Reduce garbage generated by bloom filter lookups (CASSANDRA-6609)
[2/2] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ca00f622 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ca00f622 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ca00f622 Branch: refs/heads/trunk Commit: ca00f622a5dcf899271d80076066ace3949a7e73 Parents: 300b026 2103646 Author: Marcus Eriksson Authored: Thu Feb 6 18:05:46 2014 +0100 Committer: Marcus Eriksson Committed: Thu Feb 6 18:05:46 2014 +0100 -- CHANGES.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ca00f622/CHANGES.txt --
[2/4] git commit: Update CHANGES for CASSANDRA-6522
Update CHANGES for CASSANDRA-6522 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/933df01d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/933df01d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/933df01d Branch: refs/heads/trunk Commit: 933df01d2b64ecf3698e171017e37d67546acfb7 Parents: 862698c Author: Marcus Eriksson Authored: Thu Feb 6 17:58:36 2014 +0100 Committer: Marcus Eriksson Committed: Thu Feb 6 17:58:36 2014 +0100 -- CHANGES.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/933df01d/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 58d3f90..8148083 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -6,7 +6,8 @@ Merged from 1.2: * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) * Fix partition and range deletes not triggering flush (CASSANDRA-6655) - + * Account for range/row tombstones in tombstone drop + time histogram (CASSANDRA-6522) 2.0.5 * Reduce garbage generated by bloom filter lookups (CASSANDRA-6609)
[3/4] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0b56fc09 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0b56fc09 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0b56fc09 Branch: refs/heads/trunk Commit: 0b56fc0987d250f02c6d03e27c1ae68e8e1a27a9 Parents: b4cd7b5 933df01 Author: Marcus Eriksson Authored: Thu Feb 6 17:58:55 2014 +0100 Committer: Marcus Eriksson Committed: Thu Feb 6 17:58:55 2014 +0100 -- CHANGES.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0b56fc09/CHANGES.txt --
[1/4] git commit: Merge remote-tracking branch 'origin/cassandra-2.0' into cassandra-2.0
Updated Branches: refs/heads/trunk b4cd7b58e -> 300b02633 Merge remote-tracking branch 'origin/cassandra-2.0' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/862698cd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/862698cd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/862698cd Branch: refs/heads/trunk Commit: 862698cd546ebc3adc99b5c84cfaf0764d3e3e96 Parents: 0b6913e 45955e6 Author: Jonathan Ellis Authored: Thu Feb 6 10:19:43 2014 -0600 Committer: Jonathan Ellis Committed: Thu Feb 6 10:19:43 2014 -0600 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/862698cd/CHANGES.txt --
[4/4] git commit: Update CHANGES after CASSANDRA-5357
Update CHANGES after CASSANDRA-5357 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/300b0263 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/300b0263 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/300b0263 Branch: refs/heads/trunk Commit: 300b02633e79f8e786a8a1f3ee1425d726c74663 Parents: 0b56fc0 Author: Marcus Eriksson Authored: Thu Feb 6 18:00:30 2014 +0100 Committer: Marcus Eriksson Committed: Thu Feb 6 18:00:30 2014 +0100 -- CHANGES.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/300b0263/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 1edbe0a..9d752ee 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -26,7 +26,7 @@ uniquely for CF id (CASSANDRA-5202) * New counters implementation (CASSANDRA-6504) * Replace UnsortedColumns usage with ArrayBackedSortedColumns (CASSANDRA-6630) - + * Add option to use row cache with a given amount of rows (CASSANDRA-5357) 2.0.6 * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645)
git commit: Update CHANGES for CASSANDRA-6522
Updated Branches: refs/heads/cassandra-2.0 862698cd5 -> 933df01d2 Update CHANGES for CASSANDRA-6522 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/933df01d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/933df01d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/933df01d Branch: refs/heads/cassandra-2.0 Commit: 933df01d2b64ecf3698e171017e37d67546acfb7 Parents: 862698c Author: Marcus Eriksson Authored: Thu Feb 6 17:58:36 2014 +0100 Committer: Marcus Eriksson Committed: Thu Feb 6 17:58:36 2014 +0100 -- CHANGES.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/933df01d/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 58d3f90..8148083 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -6,7 +6,8 @@ Merged from 1.2: * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) * Fix partition and range deletes not triggering flush (CASSANDRA-6655) - + * Account for range/row tombstones in tombstone drop + time histogram (CASSANDRA-6522) 2.0.5 * Reduce garbage generated by bloom filter lookups (CASSANDRA-6609)
[2/3] git commit: Improve nodetool cfhistograms formatting patch by Tyler Hobbs; reviewed by Benedict Elliott Smith for CASSANDRA-6360
Improve nodetool cfhistograms formatting
patch by Tyler Hobbs; reviewed by Benedict Elliott Smith for CASSANDRA-6360
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/43e6e184
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/43e6e184
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/43e6e184
Branch: refs/heads/trunk
Commit: 43e6e184b0bc4881a3324fa1caad987207a95e9e
Parents: cd26f48
Author: Jonathan Ellis
Authored: Thu Feb 6 10:11:51 2014 -0600
Committer: Jonathan Ellis
Committed: Thu Feb 6 10:11:51 2014 -0600
--
CHANGES.txt | 1 +
.../org/apache/cassandra/tools/NodeCmd.java | 128 +++
2 files changed, 104 insertions(+), 25 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/43e6e184/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 728c57a..dfbe5c6 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.6
+ * Improve nodetool cfhistograms formatting (CASSANDRA-6360)
* Expose bulk loading progress over JMX (CASSANDRA-4757)
* Correctly handle null with IF conditions and TTL (CASSANDRA-6623)
Merged from 1.2:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/43e6e184/src/java/org/apache/cassandra/tools/NodeCmd.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeCmd.java
b/src/java/org/apache/cassandra/tools/NodeCmd.java
index ab05d16..fd7b69b 100644
--- a/src/java/org/apache/cassandra/tools/NodeCmd.java
+++ b/src/java/org/apache/cassandra/tools/NodeCmd.java
@@ -75,7 +75,7 @@ public class NodeCmd
private static final Pair CFSTATS_IGNORE_OPT =
Pair.create("i", "ignore");
private static final Pair RESOLVE_IP = Pair.create("r",
"resolve-ip");
private static final Pair SCRUB_SKIP_CORRUPTED_OPT =
Pair.create("s", "skip-corrupted");
-
+private static final Pair COMPACT_OPT = Pair.create("c",
"compact");
private static final String DEFAULT_HOST = "127.0.0.1";
private static final int DEFAULT_PORT = 7199;
@@ -104,6 +104,7 @@ public class NodeCmd
options.addOption(CFSTATS_IGNORE_OPT, false, "ignore the supplied list
of keyspace.columnfamiles in statistics");
options.addOption(RESOLVE_IP, false, "show node domain names instead
of IPs");
options.addOption(SCRUB_SKIP_CORRUPTED_OPT, false, "when scrubbing
counter tables, skip corrupted rows");
+options.addOption(COMPACT_OPT, false, "print histograms in a more
compact format");
}
public NodeCmd(NodeProbe probe)
@@ -956,7 +957,47 @@ public class NodeCmd
outs.println("RemovalStatus: " + probe.getRemovalStatus());
}
-private void printCfHistograms(String keySpace, String columnFamily,
PrintStream output)
+/**
+ * Returns a pair of the min and max indexes we actually have histogram
data for.
+ * If there's no data, -1 will be returned for the min and max.
+ */
+private Pair getDataBounds(long[] data)
+{
+int lowestIndex = -1;
+int highestIndex = -1;
+for (int i = 0; i < data.length; i++)
+{
+if (data[i] > 0)
+{
+highestIndex = i;
+if (lowestIndex == -1)
+lowestIndex = i;
+}
+}
+return Pair.create(lowestIndex, highestIndex);
+}
+
+private void printHistogram(long[] data, long[] offsets, String unit,
PrintStream output)
+{
+Pair bounds = getDataBounds(data);
+if (bounds.left == -1)
+{
+output.println("No Data");
+}
+else
+{
+long maxValue = -1;
+for (int i = bounds.left; i <= bounds.right; i++)
+maxValue = Math.max(maxValue, offsets[i]);
+
+String format = "%" + new Long(maxValue).toString().length() + "d
%s: %d";
+for (int i = bounds.left; i <= bounds.right; i++)
+output.println(String.format(format, offsets[i], unit,
data[i]));
+}
+output.println("");
+}
+
+private void printCfHistograms(String keySpace, String columnFamily,
PrintStream output, boolean compactFormat)
{
ColumnFamilyStoreMBean store = this.probe.getCfsProxy(keySpace,
columnFamily);
@@ -970,25 +1011,46 @@ public class NodeCmd
long[] ecch = store.getEstimatedColumnCountHistogram();
output.println(String.format("%s/%s histograms", keySpace,
columnFamily));
+output.println("");
-output.println(String.format("%-10s%10s%18s%18s%18s%18s",
- "Offset", "SSTables", "Write Latency",
"Read Latency", "Partition Si
[jira] [Commented] (CASSANDRA-6666) Avoid accumulating tombstones after partial hint replay
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893506#comment-13893506 ] Anne Sullivan commented on CASSANDRA-: -- Didn't realize that, thanks for the info. I'll have to try to reproduce the repair issue then as it must have been something different causing it. > Avoid accumulating tombstones after partial hint replay > --- > > Key: CASSANDRA- > URL: https://issues.apache.org/jira/browse/CASSANDRA- > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Labels: hintedhandoff > Fix For: 1.2.16, 2.0.6 > > Attachments: .txt > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6666) Avoid accumulating tombstones after partial hint replay
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893502#comment-13893502 ] Jonathan Ellis commented on CASSANDRA-: --- Hints (and other local system tables) are neither replicated nor repaired. > Avoid accumulating tombstones after partial hint replay > --- > > Key: CASSANDRA- > URL: https://issues.apache.org/jira/browse/CASSANDRA- > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Labels: hintedhandoff > Fix For: 1.2.16, 2.0.6 > > Attachments: .txt > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6666) Avoid accumulating tombstones after partial hint replay
[ https://issues.apache.org/jira/browse/CASSANDRA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893503#comment-13893503 ] Anne Sullivan commented on CASSANDRA-: -- Sorry, just re-read the patch, it will fix the nodetool repair problem too. Thanks. > Avoid accumulating tombstones after partial hint replay > --- > > Key: CASSANDRA- > URL: https://issues.apache.org/jira/browse/CASSANDRA- > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Labels: hintedhandoff > Fix For: 1.2.16, 2.0.6 > > Attachments: .txt > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[2/3] git commit: Fix upgradesstables NPE for non-CF-based indexes patch by Sergio Bossa; reviewed by jbellis for CASSANDRA-6645
Fix upgradesstables NPE for non-CF-based indexes patch by Sergio Bossa; reviewed by jbellis for CASSANDRA-6645 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/45955e68 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/45955e68 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/45955e68 Branch: refs/heads/trunk Commit: 45955e6829a765cb12671f628480e9c397cb695d Parents: 43e6e18 Author: Jonathan Ellis Authored: Thu Feb 6 10:14:37 2014 -0600 Committer: Jonathan Ellis Committed: Thu Feb 6 10:14:37 2014 -0600 -- CHANGES.txt | 1 + .../cassandra/db/index/SecondaryIndexSearcher.java | 2 +- .../db/index/composites/CompositesSearcher.java | 1 + .../apache/cassandra/db/index/keys/KeysSearcher.java| 1 + .../org/apache/cassandra/service/StorageService.java| 12 5 files changed, 12 insertions(+), 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index dfbe5c6..b260b49 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.0.6 + * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) * Improve nodetool cfhistograms formatting (CASSANDRA-6360) * Expose bulk loading progress over JMX (CASSANDRA-4757) * Correctly handle null with IF conditions and TTL (CASSANDRA-6623) http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java -- diff --git a/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java b/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java index f3e993d..e93efd1 100644 --- a/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java +++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java @@ -63,7 +63,7 @@ public abstract class SecondaryIndexSearcher continue; SecondaryIndex index = indexManager.getIndexForColumn(expression.column_name); -if (index == null || (expression.op != IndexOperator.EQ)) +if (index == null || index.getIndexCfs() == null || expression.op != IndexOperator.EQ) continue; int columns = index.getIndexCfs().getMeanColumns(); candidates.put(index, columns); http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java -- diff --git a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java index aa35605..90e7089 100644 --- a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java +++ b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java @@ -80,6 +80,7 @@ public class CompositesSearcher extends SecondaryIndexSearcher final IndexExpression primary = highestSelectivityPredicate(filter.getClause()); final CompositesIndex index = (CompositesIndex)indexManager.getIndexForColumn(primary.column_name); assert index != null; +assert index.getIndexCfs() != null; final DecoratedKey indexKey = index.getIndexKeyFor(primary.value); if (logger.isDebugEnabled()) http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java -- diff --git a/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java b/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java index e14f865..5d82ba0 100644 --- a/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java +++ b/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java @@ -63,6 +63,7 @@ public class KeysSearcher extends SecondaryIndexSearcher final IndexExpression primary = highestSelectivityPredicate(filter.getClause()); final SecondaryIndex index = indexManager.getIndexForColumn(primary.column_name); assert index != null; +assert index.getIndexCfs() != null; final DecoratedKey indexKey = index.getIndexKeyFor(primary.value); if (logger.isDebugEnabled()) http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/src/java/org/apache/cassandra/service/StorageService.java -- diff --git a/src/java/org/apache/cassandra/service/StorageService.java b/src/java/org/apache/cassandra/service/Storage
[3/3] git commit: merge from 2.0
merge from 2.0
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f97a981d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f97a981d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f97a981d
Branch: refs/heads/trunk
Commit: f97a981d560539565db540263eff3b0c80dbab8e
Parents: 3a82adb 45955e6
Author: Jonathan Ellis
Authored: Thu Feb 6 10:15:04 2014 -0600
Committer: Jonathan Ellis
Committed: Thu Feb 6 10:15:04 2014 -0600
--
CHANGES.txt | 2 ++
.../cassandra/db/index/SecondaryIndexSearcher.java | 8
.../db/index/composites/CompositesSearcher.java | 1 +
.../apache/cassandra/db/index/keys/KeysSearcher.java| 1 +
.../org/apache/cassandra/service/StorageService.java| 12
5 files changed, 20 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f97a981d/CHANGES.txt
--
diff --cc CHANGES.txt
index 745e50b,b260b49..ddb6984
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,34 -1,6 +1,36 @@@
+2.1
+ * add listsnapshots command to nodetool (CASSANDRA-5742)
+ * Introduce AtomicBTreeColumns (CASSANDRA-6271)
+ * Multithreaded commitlog (CASSANDRA-3578)
+ * allocate fixed index summary memory pool and resample cold index summaries
+ to use less memory (CASSANDRA-5519)
+ * Removed multithreaded compaction (CASSANDRA-6142)
+ * Parallelize fetching rows for low-cardinality indexes (CASSANDRA-1337)
+ * change logging from log4j to logback (CASSANDRA-5883)
+ * switch to LZ4 compression for internode communication (CASSANDRA-5887)
+ * Stop using Thrift-generated Index* classes internally (CASSANDRA-5971)
+ * Remove 1.2 network compatibility code (CASSANDRA-5960)
+ * Remove leveled json manifest migration code (CASSANDRA-5996)
+ * Remove CFDefinition (CASSANDRA-6253)
+ * Use AtomicIntegerFieldUpdater in RefCountedMemory (CASSANDRA-6278)
+ * User-defined types for CQL3 (CASSANDRA-5590)
+ * Use of o.a.c.metrics in nodetool (CASSANDRA-5871, 6406)
+ * Batch read from OTC's queue and cleanup (CASSANDRA-1632)
+ * Secondary index support for collections (CASSANDRA-4511, 6383)
+ * SSTable metadata(Stats.db) format change (CASSANDRA-6356)
+ * Push composites support in the storage engine
+ (CASSANDRA-5417, CASSANDRA-6520)
+ * Add snapshot space used to cfstats (CASSANDRA-6231)
+ * Add cardinality estimator for key count estimation (CASSANDRA-5906)
+ * CF id is changed to be non-deterministic. Data dir/key cache are created
+ uniquely for CF id (CASSANDRA-5202)
+ * New counters implementation (CASSANDRA-6504)
+ * Replace UnsortedColumns usage with ArrayBackedSortedColumns
(CASSANDRA-6630)
+
+
2.0.6
+ * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645)
+ * Improve nodetool cfhistograms formatting (CASSANDRA-6360)
* Expose bulk loading progress over JMX (CASSANDRA-4757)
* Correctly handle null with IF conditions and TTL (CASSANDRA-6623)
Merged from 1.2:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f97a981d/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java
--
diff --cc src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java
index a508a15,e93efd1..23f259b
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java
@@@ -63,11 -59,11 +63,19 @@@ public abstract class SecondaryIndexSea
for (IndexExpression expression : clause)
{
// skip columns belonging to a different index type
-if (!columns.contains(expression.column_name))
+if (!columns.contains(expression.column))
continue;
++<<< HEAD
+SecondaryIndex index =
indexManager.getIndexForColumn(expression.column);
+if (index == null || !expression.operator.allowsIndexQuery())
++||| merged common ancestors
++SecondaryIndex index =
indexManager.getIndexForColumn(expression.column_name);
++if (index == null || (expression.op != IndexOperator.EQ))
++===
+ SecondaryIndex index =
indexManager.getIndexForColumn(expression.column_name);
+ if (index == null || index.getIndexCfs() == null || expression.op
!= IndexOperator.EQ)
++>>> cassandra-2.0
continue;
int columns = index.getIndexCfs().getMeanColumns();
candidates.put(index, columns);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f97a981d/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
--
[1/3] git commit: Fix upgradesstables NPE for non-CF-based indexes patch by Sergio Bossa; reviewed by jbellis for CASSANDRA-6645
Updated Branches: refs/heads/cassandra-2.0 43e6e184b -> 45955e682 refs/heads/trunk 3a82adb89 -> f97a981d5 Fix upgradesstables NPE for non-CF-based indexes patch by Sergio Bossa; reviewed by jbellis for CASSANDRA-6645 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/45955e68 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/45955e68 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/45955e68 Branch: refs/heads/cassandra-2.0 Commit: 45955e6829a765cb12671f628480e9c397cb695d Parents: 43e6e18 Author: Jonathan Ellis Authored: Thu Feb 6 10:14:37 2014 -0600 Committer: Jonathan Ellis Committed: Thu Feb 6 10:14:37 2014 -0600 -- CHANGES.txt | 1 + .../cassandra/db/index/SecondaryIndexSearcher.java | 2 +- .../db/index/composites/CompositesSearcher.java | 1 + .../apache/cassandra/db/index/keys/KeysSearcher.java| 1 + .../org/apache/cassandra/service/StorageService.java| 12 5 files changed, 12 insertions(+), 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index dfbe5c6..b260b49 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.0.6 + * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) * Improve nodetool cfhistograms formatting (CASSANDRA-6360) * Expose bulk loading progress over JMX (CASSANDRA-4757) * Correctly handle null with IF conditions and TTL (CASSANDRA-6623) http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java -- diff --git a/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java b/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java index f3e993d..e93efd1 100644 --- a/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java +++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java @@ -63,7 +63,7 @@ public abstract class SecondaryIndexSearcher continue; SecondaryIndex index = indexManager.getIndexForColumn(expression.column_name); -if (index == null || (expression.op != IndexOperator.EQ)) +if (index == null || index.getIndexCfs() == null || expression.op != IndexOperator.EQ) continue; int columns = index.getIndexCfs().getMeanColumns(); candidates.put(index, columns); http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java -- diff --git a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java index aa35605..90e7089 100644 --- a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java +++ b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java @@ -80,6 +80,7 @@ public class CompositesSearcher extends SecondaryIndexSearcher final IndexExpression primary = highestSelectivityPredicate(filter.getClause()); final CompositesIndex index = (CompositesIndex)indexManager.getIndexForColumn(primary.column_name); assert index != null; +assert index.getIndexCfs() != null; final DecoratedKey indexKey = index.getIndexKeyFor(primary.value); if (logger.isDebugEnabled()) http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java -- diff --git a/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java b/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java index e14f865..5d82ba0 100644 --- a/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java +++ b/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java @@ -63,6 +63,7 @@ public class KeysSearcher extends SecondaryIndexSearcher final IndexExpression primary = highestSelectivityPredicate(filter.getClause()); final SecondaryIndex index = indexManager.getIndexForColumn(primary.column_name); assert index != null; +assert index.getIndexCfs() != null; final DecoratedKey indexKey = index.getIndexKeyFor(primary.value); if (logger.isDebugEnabled()) http://git-wip-us.apache.org/repos/asf/cassandra/blob/45955e68/src/java/org/apache/cassandra/service/StorageService.java --
[2/7] git commit: Fix upgradesstables NPE for non-CF-based indexes patch by Sergio Bossa; reviewed by jbellis for CASSANDRA-6645
Fix upgradesstables NPE for non-CF-based indexes patch by Sergio Bossa; reviewed by jbellis for CASSANDRA-6645 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8b6d87b8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8b6d87b8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8b6d87b8 Branch: refs/heads/trunk Commit: 8b6d87b86b0134221dd15fb74e96a9a8ee5ff1d9 Parents: adcb713 Author: Jonathan Ellis Authored: Thu Feb 6 10:16:41 2014 -0600 Committer: Jonathan Ellis Committed: Thu Feb 6 10:16:41 2014 -0600 -- CHANGES.txt | 2 ++ .../db/index/composites/CompositesSearcher.java | 3 ++- .../apache/cassandra/db/index/keys/KeysSearcher.java | 3 ++- .../org/apache/cassandra/service/StorageService.java | 14 ++ 4 files changed, 16 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8b6d87b8/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index cfdd148..4be97f1 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,6 +1,8 @@ 1.2.16 + * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645) * Fix partition and range deletes not triggering flush (CASSANDRA-6655) + 1.2.15 * Move handling of migration event source to solve bootstrap race (CASSANDRA-6648) * Make sure compaction throughput value doesn't overflow with int math (CASSANDRA-6647) http://git-wip-us.apache.org/repos/asf/cassandra/blob/8b6d87b8/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java -- diff --git a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java index 5ab1df6..3974466 100644 --- a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java +++ b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java @@ -65,7 +65,7 @@ public class CompositesSearcher extends SecondaryIndexSearcher continue; SecondaryIndex index = indexManager.getIndexForColumn(expression.column_name); -if (index == null || (expression.op != IndexOperator.EQ)) +if (index == null || index.getIndexCfs() == null || (expression.op != IndexOperator.EQ)) continue; int columns = index.getIndexCfs().getMeanColumns(); candidates.put(index, columns); @@ -106,6 +106,7 @@ public class CompositesSearcher extends SecondaryIndexSearcher final IndexExpression primary = highestSelectivityPredicate(filter.getClause()); final SecondaryIndex index = indexManager.getIndexForColumn(primary.column_name); assert index != null; +assert index.getIndexCfs() != null; final DecoratedKey indexKey = index.getIndexKeyFor(primary.value); if (logger.isDebugEnabled()) http://git-wip-us.apache.org/repos/asf/cassandra/blob/8b6d87b8/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java -- diff --git a/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java b/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java index bed6104..7e7595b 100644 --- a/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java +++ b/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java @@ -61,7 +61,7 @@ public class KeysSearcher extends SecondaryIndexSearcher continue; SecondaryIndex index = indexManager.getIndexForColumn(expression.column_name); -if (index == null || (expression.op != IndexOperator.EQ)) +if (index == null || index.getIndexCfs() == null || (expression.op != IndexOperator.EQ)) continue; int columns = index.getIndexCfs().getMeanColumns(); candidates.put(index, columns); @@ -102,6 +102,7 @@ public class KeysSearcher extends SecondaryIndexSearcher final IndexExpression primary = highestSelectivityPredicate(filter.getClause()); final SecondaryIndex index = indexManager.getIndexForColumn(primary.column_name); assert index != null; +assert index.getIndexCfs() != null; final DecoratedKey indexKey = index.getIndexKeyFor(primary.value); if (logger.isDebugEnabled()) http://git-wip-us.apache.org/repos/asf/cassandra/blob/8b6d87b8/src/java/org/apache/cassandra/service/StorageService.java -- diff --git a/src/java/org/apache/cassandra/service/StorageService.java b/src/java/org/apache/cassandra/service/StorageServic
[3/7] git commit: merge from 1.2
merge from 1.2
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0b6913ee
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0b6913ee
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0b6913ee
Branch: refs/heads/trunk
Commit: 0b6913ee0607e1392c5d743d2f896dcdd138fe40
Parents: 43e6e18 8b6d87b
Author: Jonathan Ellis
Authored: Thu Feb 6 10:17:57 2014 -0600
Committer: Jonathan Ellis
Committed: Thu Feb 6 10:17:57 2014 -0600
--
CHANGES.txt | 1 +
.../cassandra/db/index/SecondaryIndexSearcher.java | 2 +-
.../db/index/composites/CompositesSearcher.java | 1 +
.../apache/cassandra/db/index/keys/KeysSearcher.java| 1 +
.../org/apache/cassandra/service/StorageService.java| 12
5 files changed, 12 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0b6913ee/CHANGES.txt
--
diff --cc CHANGES.txt
index dfbe5c6,4be97f1..94c89cb
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,8 -1,5 +1,9 @@@
-1.2.16
+2.0.6
+ * Improve nodetool cfhistograms formatting (CASSANDRA-6360)
+ * Expose bulk loading progress over JMX (CASSANDRA-4757)
+ * Correctly handle null with IF conditions and TTL (CASSANDRA-6623)
+Merged from 1.2:
+ * Fix upgradesstables NPE for non-CF-based indexes (CASSANDRA-6645)
* Fix partition and range deletes not triggering flush (CASSANDRA-6655)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0b6913ee/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java
--
diff --cc src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java
index f3e993d,a8c1dde..e93efd1
--- a/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java
+++ b/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java
@@@ -45,41 -43,15 +45,41 @@@ public abstract class SecondaryIndexSea
/**
* @return true this index is able to handle given clauses.
*/
-public abstract boolean isIndexing(List clause);
-
-protected boolean isIndexValueStale(ColumnFamily liveData, ByteBuffer
indexedColumnName, ByteBuffer indexedValue)
+public boolean isIndexing(List clause)
{
-IColumn liveColumn = liveData.getColumn(indexedColumnName);
-if (liveColumn == null || liveColumn.isMarkedForDelete())
-return true;
-
-ByteBuffer liveValue = liveColumn.value();
-return 0 !=
liveData.metadata().getValueValidator(indexedColumnName).compare(indexedValue,
liveValue);
+return highestSelectivityPredicate(clause) != null;
+}
+
+protected IndexExpression
highestSelectivityPredicate(List clause)
+{
+IndexExpression best = null;
+int bestMeanCount = Integer.MAX_VALUE;
+Map candidates = new HashMap<>();
+
+for (IndexExpression expression : clause)
+{
+// skip columns belonging to a different index type
+if (!columns.contains(expression.column_name))
+continue;
+
+SecondaryIndex index =
indexManager.getIndexForColumn(expression.column_name);
- if (index == null || (expression.op != IndexOperator.EQ))
++if (index == null || index.getIndexCfs() == null || expression.op
!= IndexOperator.EQ)
+continue;
+int columns = index.getIndexCfs().getMeanColumns();
+candidates.put(index, columns);
+if (columns < bestMeanCount)
+{
+best = expression;
+bestMeanCount = columns;
+}
+}
+
+if (best == null)
+Tracing.trace("No applicable indexes found");
+else
+Tracing.trace("Candidate index mean cardinalities are {}.
Scanning with {}.",
+ FBUtilities.toString(candidates),
indexManager.getIndexForColumn(best.column_name).getIndexName());
+
+return best;
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0b6913ee/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
--
diff --cc
src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
index aa35605,3974466..90e7089
--- a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
+++ b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
@@@ -78,8 -104,9 +78,9 @@@ public class CompositesSearcher extend
// to each row matching that clause.
// TODO: allow merge join instead of just one index + lo
[6/7] git commit: Merge remote-tracking branch 'origin/cassandra-2.0' into cassandra-2.0
Merge remote-tracking branch 'origin/cassandra-2.0' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/862698cd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/862698cd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/862698cd Branch: refs/heads/cassandra-2.0 Commit: 862698cd546ebc3adc99b5c84cfaf0764d3e3e96 Parents: 0b6913e 45955e6 Author: Jonathan Ellis Authored: Thu Feb 6 10:19:43 2014 -0600 Committer: Jonathan Ellis Committed: Thu Feb 6 10:19:43 2014 -0600 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/862698cd/CHANGES.txt --
