[jira] Created: (CASSANDRA-2062) Use more efficient merge algorithm
Use more efficient merge algorithm
--
Key: CASSANDRA-2062
URL: https://issues.apache.org/jira/browse/CASSANDRA-2062
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.2
For {{M}} iterators containing {{N}} total items,
commons.collections.CollatingIterator performs a {{M*O(N)}} merge, and calls
hasNext multiple times per returned value. We can do better.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2062) Use more efficient merge algorithm
[
https://issues.apache.org/jira/browse/CASSANDRA-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-2062:
Attachment: 0003-Replace-Collating-with-Merge-in-CompactionIterator.txt
0002-Quickie-instrumentation-for-comparisons.txt
0001-Improved-iterator-for-merging-sorted-iterators.txt
Use more efficient merge algorithm
--
Key: CASSANDRA-2062
URL: https://issues.apache.org/jira/browse/CASSANDRA-2062
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.2
Attachments: 0001-Improved-iterator-for-merging-sorted-iterators.txt,
0002-Quickie-instrumentation-for-comparisons.txt,
0003-Replace-Collating-with-Merge-in-CompactionIterator.txt
For {{M}} iterators containing {{N}} total items,
commons.collections.CollatingIterator performs a {{O(M*N)}} merge, and calls
hasNext multiple times per returned value. We can do better.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2062) Use more efficient merge algorithm
[
https://issues.apache.org/jira/browse/CASSANDRA-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-2062:
Description: For {{M}} iterators containing {{N}} total items,
commons.collections.CollatingIterator performs a {{O(M*N)}} merge, and calls
hasNext multiple times per returned value. We can do better. (was: For {{M}}
iterators containing {{N}} total items, commons.collections.CollatingIterator
performs a {{M*O(N)}} merge, and calls hasNext multiple times per returned
value. We can do better.)
Use more efficient merge algorithm
--
Key: CASSANDRA-2062
URL: https://issues.apache.org/jira/browse/CASSANDRA-2062
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.2
Attachments: 0001-Improved-iterator-for-merging-sorted-iterators.txt,
0002-Quickie-instrumentation-for-comparisons.txt,
0003-Replace-Collating-with-Merge-in-CompactionIterator.txt
For {{M}} iterators containing {{N}} total items,
commons.collections.CollatingIterator performs a {{O(M*N)}} merge, and calls
hasNext multiple times per returned value. We can do better.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2062) Use more efficient merge algorithm
[
https://issues.apache.org/jira/browse/CASSANDRA-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-2062:
Attachment: 0005-Remove-temporary-instrumentation-and-CollatingIterator.txt
0004-Port-LazilyCompactedRow-ReducingKeyIterator-RangeSlice.txt
* 0001 - Adds MergeIterator, which uses a priority queue to perform a
{{O(2*log(M)*N)}} merge in the same space. Also guarantees to only call hasNext
once per item.
* 0002 - Adds some debug output for checking the number of comparisons
performed during compaction
* 0003 - Replaces CollatingIterator for Compaction
* 0004 - Replaces CollatingIterator elsewhere
* 0005 - Removes debug output and CollatingIterator from FBUtilities
The number of comparisons needed to compact {{M=sstables=100}},
{{N=rows=8}} drops from ~8 million ({{M*N}}) to ~1 million
({{2*log(M)*N}}), as expected.
{noformat}# MergeIterator
1 for org.apache.cassandra.io.CompactionIterator@7dc21ece
org.apache.cassandra.db.LongCompactionSpeedTest: sstables=2 rowsper=1
colsper=20: 2758 ms
39 for org.apache.cassandra.io.CompactionIterator@20ca5bff
org.apache.cassandra.db.LongCompactionSpeedTest: sstables=2 rowsper=20
colsper=1: 4504 ms
917546 for org.apache.cassandra.io.CompactionIterator@6360f5bf
org.apache.cassandra.db.LongCompactionSpeedTest: sstables=100 rowsper=800
colsper=5: 1021 ms
# CollatingIterator
1 for org.apache.cassandra.io.CompactionIterator@5f873eb2
org.apache.cassandra.db.LongCompactionSpeedTest: sstables=2 rowsper=1
colsper=20: 1732 ms
39 for org.apache.cassandra.io.CompactionIterator@357c7988
org.apache.cassandra.db.LongCompactionSpeedTest: sstables=2 rowsper=20
colsper=1: 4499 ms
7915050 for org.apache.cassandra.io.CompactionIterator@2ae0420b
org.apache.cassandra.db.LongCompactionSpeedTest: sstables=100 rowsper=800
colsper=5: 1427 ms{noformat}
Use more efficient merge algorithm
--
Key: CASSANDRA-2062
URL: https://issues.apache.org/jira/browse/CASSANDRA-2062
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.2
Attachments: 0001-Improved-iterator-for-merging-sorted-iterators.txt,
0002-Quickie-instrumentation-for-comparisons.txt,
0003-Replace-Collating-with-Merge-in-CompactionIterator.txt,
0004-Port-LazilyCompactedRow-ReducingKeyIterator-RangeSlice.txt,
0005-Remove-temporary-instrumentation-and-CollatingIterator.txt
For {{M}} iterators containing {{N}} total items,
commons.collections.CollatingIterator performs a {{O(M*N)}} merge, and calls
hasNext multiple times per returned value. We can do better.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2062) Use more efficient merge algorithm
[
https://issues.apache.org/jira/browse/CASSANDRA-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987452#action_12987452
]
Stu Hood commented on CASSANDRA-2062:
-
The times in that paste aren't supposed to be significant... I was just trying
to get the count of comparisons, so I was doing other things with my laptop.
That test uses very small keys (6 bytes), so the comparisons are relatively
cheap.
Use more efficient merge algorithm
--
Key: CASSANDRA-2062
URL: https://issues.apache.org/jira/browse/CASSANDRA-2062
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.2
Attachments: 0001-Improved-iterator-for-merging-sorted-iterators.txt,
0002-Quickie-instrumentation-for-comparisons.txt,
0003-Replace-Collating-with-Merge-in-CompactionIterator.txt,
0004-Port-LazilyCompactedRow-ReducingKeyIterator-RangeSlice.txt,
0005-Remove-temporary-instrumentation-and-CollatingIterator.txt
For {{M}} iterators containing {{N}} total items,
commons.collections.CollatingIterator performs a {{O(M*N)}} merge, and calls
hasNext multiple times per returned value. We can do better.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2062) Use more efficient merge algorithm
[
https://issues.apache.org/jira/browse/CASSANDRA-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987480#action_12987480
]
Stu Hood commented on CASSANDRA-2062:
-
Also, as an important side note: the core reason for implementing this was to
gain control over the consumption of the lazy nested iterators in the read path.
We survive now because we write the size of the row at the front of the row
(via some serious acrobatics at write time), which gives us hasNext() for rows
for free. But it became apparent while working on the block-based format that
hasNext() will not be cheap unless the current item has been consumed.
Consumption of the row is easy, and blocks will be framed so that they can be
very easily skipped, but you don't want to have to seek to the end of the row
to answer hasNext, and then seek back to the beginning to consume the row,
which is what CollatingIterator would have forced us to do.
There is actually one more roadblock to making this crazy iterator dance work:
ReducingIterator pulls one more item than it needs from its source before
'reducing' (consuming) the items it is holding. This breaks the invariant, but
it should be fixable by smashing ReducingIterator into MergeIterator.
Use more efficient merge algorithm
--
Key: CASSANDRA-2062
URL: https://issues.apache.org/jira/browse/CASSANDRA-2062
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.2
Attachments: 0001-Improved-iterator-for-merging-sorted-iterators.txt,
0002-Quickie-instrumentation-for-comparisons.txt,
0003-Replace-Collating-with-Merge-in-CompactionIterator.txt,
0004-Port-LazilyCompactedRow-ReducingKeyIterator-RangeSlice.txt,
0005-Remove-temporary-instrumentation-and-CollatingIterator.txt
For {{M}} iterators containing {{N}} total items,
commons.collections.CollatingIterator performs a {{O(M*N)}} merge, and calls
hasNext multiple times per returned value. We can do better.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2063) bug with test
bug with test - Key: CASSANDRA-2063 URL: https://issues.apache.org/jira/browse/CASSANDRA-2063 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Environment: RHL. Python 2.4.3 Reporter: Amit Cahanovich Priority: Minor when executing nosetests (e.g: nosetests test/system/test_avro_system.py), you get the following error: mod = load_module(part_fqname, fh, filename, desc) File /tmp/apache-cassandra-0.7.0-src/test/system/test_avro_system.py, line 19 from . import AvroTester ^ SyntaxError: invalid syntax All *.py scripts should be changed to be from __init__ import (AvroTester) instead of from . import AvroTester -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2064) When the target node is down and the replication factor is 1. Any batch mutate/read with consistency level QUORUM will fail to succeed.
When the target node is down and the replication factor is 1. Any batch mutate/read with consistency level QUORUM will fail to succeed. Key: CASSANDRA-2064 URL: https://issues.apache.org/jira/browse/CASSANDRA-2064 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Mikael Sitruk When the target node is down and the replication factor is 1. Any batch mutate or read (with consistency level QUORUM) will fail to succeed. This case occurs because the quorum cannot be verified. The storage proxy will write the data on its own log, but cannot assure the quorum (since the quorum definition requires the replica to respond) - the responseHandler.assureSufficientLiveNodes(); will throw UnavailableException. While it is OK to send an exception i think that the exception should contain an appropriate message - like consistency level: Quorum, replication factor: replication factor cannot be verified for key... (adding the natural and the hinted node should be nice too at least in the log). Perhaps a separate exception should be thrown (sub type of UnavailableException) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2065) Column Family replication info should be available in JMX
Column Family replication info should be available in JMX - Key: CASSANDRA-2065 URL: https://issues.apache.org/jira/browse/CASSANDRA-2065 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Mikael Sitruk It should be nice to have Column family replication information available via JMX. Currently the replication factor info is only available in the CLI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2063) bug with test
[ https://issues.apache.org/jira/browse/CASSANDRA-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2063: -- Fix Version/s: 0.7.2 Assignee: Eric Evans bug with test - Key: CASSANDRA-2063 URL: https://issues.apache.org/jira/browse/CASSANDRA-2063 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Environment: RHL. Python 2.4.3 Reporter: Amit Cahanovich Assignee: Eric Evans Priority: Minor Fix For: 0.7.2 Original Estimate: 0.17h Remaining Estimate: 0.17h when executing nosetests (e.g: nosetests test/system/test_avro_system.py), you get the following error: mod = load_module(part_fqname, fh, filename, desc) File /tmp/apache-cassandra-0.7.0-src/test/system/test_avro_system.py, line 19 from . import AvroTester ^ SyntaxError: invalid syntax All *.py scripts should be changed to be from __init__ import (AvroTester) instead of from . import AvroTester -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064155 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/cli/CliClient.java
Author: jbellis
Date: Thu Jan 27 15:21:39 2011
New Revision: 1064155
URL: http://svn.apache.org/viewvc?rev=1064155view=rev
Log:
fix CLI show keyspaces with null options on NTS
patch by Pavel Yaskevich; reviewed by jbellis for CASSANDRA-2049
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1064155r1=1064154r2=1064155view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Jan 27 15:21:39 2011
@@ -2,6 +2,7 @@
* fix potential overflow in nodetool cfstats (CASSANDRA-2057)
* add JVM shutdownhook to sync commitlog (CASSANDRA-1919)
* allow nodes to be up without being part of normal traffic (CASSANDRA-1951)
+ * fix CLI show keyspaces with null options on NTS (CASSANDRA-2049)
0.7.1
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java?rev=1064155r1=1064154r2=1064155view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
Thu Jan 27 15:21:39 2011
@@ -1237,9 +1237,14 @@ public class CliClient extends CliUserHe
sessionState.out.println( Replication Strategy: +
ks_def.strategy_class);
if (ks_def.strategy_class.endsWith(.NetworkTopologyStrategy))
-sessionState.out.println(Options: +
FBUtilities.toString(ks_def.strategy_options));
+{
+MapString, String options = ks_def.strategy_options;
+sessionState.out.println(Options: [ + ((options == null)
? : FBUtilities.toString(options)) + ]);
+}
else
+{
sessionState.out.println(Replication Factor: +
ks_def.replication_factor);
+}
sessionState.out.println( Column Families:);
[jira] Updated: (CASSANDRA-2061) Missing logging for some exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2061:
--
Attachment: 2061.txt
As near as I can tell, an exception thrown on a scheduled task will never kill
the executor, just like in TPE. I don't remember why the author [me] wrote
that code -- probably because it was replacing Timer and TimerTask, and an
uncaught exception in a TimerTask _will_ kill the timer.
Patch removes RetryingSTPE and replaces with DebuggableSTPE that has an
afterExecute copied from DTPE.
Missing logging for some exceptions
---
Key: CASSANDRA-2061
URL: https://issues.apache.org/jira/browse/CASSANDRA-2061
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Stu Hood
Fix For: 0.7.2
Attachments: 2061.txt
{quote}Since you are using ScheduledThreadPoolExecutor.schedule(), the
exception was swallowed by the FutureTask.
You will have to perform a get() method on the ScheduledFuture, and you will
get ExecutionException if there was any exception occured in run().{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2061) Missing logging for some exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2061:
--
Attachment: (was: 2061.txt)
Missing logging for some exceptions
---
Key: CASSANDRA-2061
URL: https://issues.apache.org/jira/browse/CASSANDRA-2061
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Stu Hood
Fix For: 0.7.2
Attachments: 2061.txt
{quote}Since you are using ScheduledThreadPoolExecutor.schedule(), the
exception was swallowed by the FutureTask.
You will have to perform a get() method on the ScheduledFuture, and you will
get ExecutionException if there was any exception occured in run().{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2061) Missing logging for some exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2061:
--
Attachment: 2061.txt
new patch also updates afterExecute in both classes to log error if default
uncaught exception handler is null
Missing logging for some exceptions
---
Key: CASSANDRA-2061
URL: https://issues.apache.org/jira/browse/CASSANDRA-2061
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Stu Hood
Fix For: 0.7.2
Attachments: 2061.txt
{quote}Since you are using ScheduledThreadPoolExecutor.schedule(), the
exception was swallowed by the FutureTask.
You will have to perform a get() method on the ScheduledFuture, and you will
get ExecutionException if there was any exception occured in run().{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2049) On the CLI, creating or updating a keyspace to use the NetworkTopologyStrategy breaks show keyspaces;
[ https://issues.apache.org/jira/browse/CASSANDRA-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987611#action_12987611 ] Hudson commented on CASSANDRA-2049: --- Integrated in Cassandra-0.7 #217 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/217/]) fix CLI show keyspaces with null options on NTS patch by Pavel Yaskevich; reviewed by jbellis for CASSANDRA-2049 On the CLI, creating or updating a keyspace to use the NetworkTopologyStrategy breaks show keyspaces; --- Key: CASSANDRA-2049 URL: https://issues.apache.org/jira/browse/CASSANDRA-2049 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Jeremy Hanna Assignee: Pavel Yaskevich Fix For: 0.7.2 Attachments: CASSANDRA-2049.patch Original Estimate: 0.33h Time Spent: 0.33h Remaining Estimate: 0h To reproduce: - Start fresh. - Run show keyspaces; - Run create keyspace Keyspace1 with placement_strategy='org.apache.cassandra.locator.NetworkTopologyStrategy'; - Run show keyspaces; Note how before it showed the system keyspace. After it shows just: Keyspace: Keyspace1: Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy null If you have multiple keyspaces, it will hide those as well. Also, if you create the keyspace and then update it with NetworkTopologyStrategy, the same thing will happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2061) Missing logging for some exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2061:
--
Attachment: 2061-0.7.txt
patch for 0.7
Missing logging for some exceptions
---
Key: CASSANDRA-2061
URL: https://issues.apache.org/jira/browse/CASSANDRA-2061
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Stu Hood
Fix For: 0.7.2
Attachments: 2061-0.7.txt, 2061.txt
{quote}Since you are using ScheduledThreadPoolExecutor.schedule(), the
exception was swallowed by the FutureTask.
You will have to perform a get() method on the ScheduledFuture, and you will
get ExecutionException if there was any exception occured in run().{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1064170 - in /cassandra/branches/cassandra-0.7: CHANGES.txt lib/jetty-6.1.21.jar lib/jetty-util-6.1.21.jar src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Author: jbellis
Date: Thu Jan 27 16:06:12 2011
New Revision: 1064170
URL: http://svn.apache.org/viewvc?rev=1064170view=rev
Log:
remove jetty dependency
patch by Nate McCall; reveiewed by stuhood for CASSANDRA-2050
Removed:
cassandra/branches/cassandra-0.7/lib/jetty-6.1.21.jar
cassandra/branches/cassandra-0.7/lib/jetty-util-6.1.21.jar
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1064170r1=1064169r2=1064170view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Jan 27 16:06:12 2011
@@ -3,6 +3,7 @@
* add JVM shutdownhook to sync commitlog (CASSANDRA-1919)
* allow nodes to be up without being part of normal traffic (CASSANDRA-1951)
* fix CLI show keyspaces with null options on NTS (CASSANDRA-2049)
+ * remove jetty dependency (CASSANDRA-2050)
0.7.1
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java?rev=1064170r1=1064169r2=1064170view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Thu Jan 27 16:06:12 2011
@@ -45,7 +45,6 @@ import org.apache.cassandra.db.migration
import org.apache.cassandra.utils.CLibrary;
import org.apache.cassandra.utils.FBUtilities;
import org.apache.cassandra.utils.Mx4jTool;
-import org.mortbay.thread.ThreadPool;
/**
* The codeCassandraDaemon/code is an abstraction for a Cassandra daemon
@@ -349,7 +348,7 @@ public abstract class AbstractCassandraD
* A subclass of Java's ThreadPoolExecutor which implements Jetty's
ThreadPool
* interface (for integration with Avro), and performs ClientState cleanup.
*/
-public static class CleaningThreadPool extends ThreadPoolExecutor
implements ThreadPool
+public static class CleaningThreadPool extends ThreadPoolExecutor
{
private ThreadLocalClientState state;
public CleaningThreadPool(ThreadLocalClientState state, int
minWorkerThread, int maxWorkerThreads)
@@ -365,42 +364,6 @@ public abstract class AbstractCassandraD
state.get().logout();
}
-/*/
-/** The following are cribbed from org.mortbay.thread.concurrent */
-/*/
-
-public boolean dispatch(Runnable job)
-{
-try
-{
-execute(job);
-return true;
-}
-catch(RejectedExecutionException e)
-{
-logger.error(Failed to dispatch thread:, e);
-return false;
-}
-}
-public int getIdleThreads()
-{
-return getPoolSize()-getActiveCount();
-}
-
-public int getThreads()
-{
-return getPoolSize();
-}
-
-public boolean isLowOnThreads()
-{
-return getActiveCount()=getMaximumPoolSize();
-}
-
-public void join() throws InterruptedException
-{
-this.awaitTermination(Long.MAX_VALUE,TimeUnit.MILLISECONDS);
-}
}
}
[jira] Resolved: (CASSANDRA-2050) AbstractDaemon unnecessarily uses jetty interface
[ https://issues.apache.org/jira/browse/CASSANDRA-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2050. --- Resolution: Fixed Reviewer: stuhood (was: urandom) committed w/ removal of lib/jetty* (which svn diff won't include in a patch) AbstractDaemon unnecessarily uses jetty interface - Key: CASSANDRA-2050 URL: https://issues.apache.org/jira/browse/CASSANDRA-2050 Project: Cassandra Issue Type: Task Components: API Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.7.2 Attachments: 2050.txt AbstractDaemon's CleaningThreadPool need not implement this jetty interface. Removing this would allow us to remove jetty dependency altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064178 - in /cassandra/branches/cassandra-0.7: CHANGES.txt lib/jetty-6.1.21.jar lib/jetty-util-6.1.21.jar
Author: jbellis Date: Thu Jan 27 16:18:52 2011 New Revision: 1064178 URL: http://svn.apache.org/viewvc?rev=1064178view=rev Log: add back jetty jars until trunk Added: cassandra/branches/cassandra-0.7/lib/jetty-6.1.21.jar - copied unchanged from r1064169, cassandra/branches/cassandra-0.7/lib/jetty-6.1.21.jar cassandra/branches/cassandra-0.7/lib/jetty-util-6.1.21.jar - copied unchanged from r1064169, cassandra/branches/cassandra-0.7/lib/jetty-util-6.1.21.jar Modified: cassandra/branches/cassandra-0.7/CHANGES.txt Modified: cassandra/branches/cassandra-0.7/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1064178r1=1064177r2=1064178view=diff == --- cassandra/branches/cassandra-0.7/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Jan 27 16:18:52 2011 @@ -3,7 +3,7 @@ * add JVM shutdownhook to sync commitlog (CASSANDRA-1919) * allow nodes to be up without being part of normal traffic (CASSANDRA-1951) * fix CLI show keyspaces with null options on NTS (CASSANDRA-2049) - * remove jetty dependency (CASSANDRA-2050) + * remove jetty dependency from AbstractCassandraDaemon (CASSANDRA-2050) 0.7.1
svn commit: r1064181 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Author: jbellis
Date: Thu Jan 27 16:22:07 2011
New Revision: 1064181
URL: http://svn.apache.org/viewvc?rev=1064181view=rev
Log:
revert 2050 entirely
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1064181r1=1064180r2=1064181view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Jan 27 16:22:07 2011
@@ -3,7 +3,6 @@
* add JVM shutdownhook to sync commitlog (CASSANDRA-1919)
* allow nodes to be up without being part of normal traffic (CASSANDRA-1951)
* fix CLI show keyspaces with null options on NTS (CASSANDRA-2049)
- * remove jetty dependency from AbstractCassandraDaemon (CASSANDRA-2050)
0.7.1
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java?rev=1064181r1=1064180r2=1064181view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Thu Jan 27 16:22:07 2011
@@ -45,6 +45,7 @@ import org.apache.cassandra.db.migration
import org.apache.cassandra.utils.CLibrary;
import org.apache.cassandra.utils.FBUtilities;
import org.apache.cassandra.utils.Mx4jTool;
+import org.mortbay.thread.ThreadPool;
/**
* The codeCassandraDaemon/code is an abstraction for a Cassandra daemon
@@ -348,7 +349,7 @@ public abstract class AbstractCassandraD
* A subclass of Java's ThreadPoolExecutor which implements Jetty's
ThreadPool
* interface (for integration with Avro), and performs ClientState cleanup.
*/
-public static class CleaningThreadPool extends ThreadPoolExecutor
+public static class CleaningThreadPool extends ThreadPoolExecutor
implements ThreadPool
{
private ThreadLocalClientState state;
public CleaningThreadPool(ThreadLocalClientState state, int
minWorkerThread, int maxWorkerThreads)
@@ -364,6 +365,42 @@ public abstract class AbstractCassandraD
state.get().logout();
}
+/*/
+/** The following are cribbed from org.mortbay.thread.concurrent */
+/*/
+
+public boolean dispatch(Runnable job)
+{
+try
+{
+execute(job);
+return true;
+}
+catch(RejectedExecutionException e)
+{
+logger.error(Failed to dispatch thread:, e);
+return false;
+}
+}
+public int getIdleThreads()
+{
+return getPoolSize()-getActiveCount();
+}
+
+public int getThreads()
+{
+return getPoolSize();
+}
+
+public boolean isLowOnThreads()
+{
+return getActiveCount()=getMaximumPoolSize();
+}
+
+public void join() throws InterruptedException
+{
+this.awaitTermination(Long.MAX_VALUE,TimeUnit.MILLISECONDS);
+}
}
}
svn commit: r1064182 - in /cassandra/trunk: ./ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/cli/
Author: jbellis Date: Thu Jan 27 16:22:48 2011 New Revision: 1064182 URL: http://svn.apache.org/viewvc?rev=1064182view=rev Log: merge from 0.7 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jan 27 16:22:48 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1055311,1056121,1057932 -/cassandra/branches/cassandra-0.7:1026516-1063928 +/cassandra/branches/cassandra-0.7:1026516-1064181 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3:774578-796573 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1064182r1=1064181r2=1064182view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Jan 27 16:22:48 2011 @@ -12,6 +12,7 @@ * fix potential overflow in nodetool cfstats (CASSANDRA-2057) * add JVM shutdownhook to sync commitlog (CASSANDRA-1919) * allow nodes to be up without being part of normal traffic (CASSANDRA-1951) + * fix CLI show keyspaces with null options on NTS (CASSANDRA-2049) 0.7.1 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jan 27 16:22:48 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1055311,1056121,1057932 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1063928 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1064181 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/cassandra/service/Cassandra.java:774578-796573 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jan 27 16:22:48 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1055311,1056121,1057932 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1063928 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1064181 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/cassandra/service/column_t.java:774578-792198 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jan 27 16:22:48 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java:922689-1052356,1052358-1053452,1053454,1053456-1055311,1056121,1057932 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java:1026516-1063928 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java:1026516-1064181
[jira] Updated: (CASSANDRA-2050) AbstractDaemon unnecessarily uses jetty interface
[ https://issues.apache.org/jira/browse/CASSANDRA-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2050: -- Fix Version/s: (was: 0.7.2) 0.8 this breaks stuff in 0.7, moved to 0.8 AbstractDaemon unnecessarily uses jetty interface - Key: CASSANDRA-2050 URL: https://issues.apache.org/jira/browse/CASSANDRA-2050 Project: Cassandra Issue Type: Task Components: API Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.8 Attachments: 2050.txt AbstractDaemon's CleaningThreadPool need not implement this jetty interface. Removing this would allow us to remove jetty dependency altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064183 - in /cassandra/trunk: lib/jetty-6.1.24.jar lib/jetty-util-6.1.24.jar src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Author: jbellis
Date: Thu Jan 27 16:24:07 2011
New Revision: 1064183
URL: http://svn.apache.org/viewvc?rev=1064183view=rev
Log:
r/m jetty
patch by Nate McCall; reviewed by stuhood for CASSANDRA-2050
Removed:
cassandra/trunk/lib/jetty-6.1.24.jar
cassandra/trunk/lib/jetty-util-6.1.24.jar
Modified:
cassandra/trunk/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Modified:
cassandra/trunk/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java?rev=1064183r1=1064182r2=1064183view=diff
==
---
cassandra/trunk/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
(original)
+++
cassandra/trunk/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Thu Jan 27 16:24:07 2011
@@ -45,7 +45,6 @@ import org.apache.cassandra.db.migration
import org.apache.cassandra.utils.CLibrary;
import org.apache.cassandra.utils.FBUtilities;
import org.apache.cassandra.utils.Mx4jTool;
-import org.mortbay.thread.ThreadPool;
/**
* The codeCassandraDaemon/code is an abstraction for a Cassandra daemon
@@ -349,7 +348,7 @@ public abstract class AbstractCassandraD
* A subclass of Java's ThreadPoolExecutor which implements Jetty's
ThreadPool
* interface (for integration with Avro), and performs ClientState cleanup.
*/
-public static class CleaningThreadPool extends ThreadPoolExecutor
implements ThreadPool
+public static class CleaningThreadPool extends ThreadPoolExecutor
{
private ThreadLocalClientState state;
public CleaningThreadPool(ThreadLocalClientState state, int
minWorkerThread, int maxWorkerThreads)
@@ -365,42 +364,6 @@ public abstract class AbstractCassandraD
state.get().logout();
}
-/*/
-/** The following are cribbed from org.mortbay.thread.concurrent */
-/*/
-
-public boolean dispatch(Runnable job)
-{
-try
-{
-execute(job);
-return true;
-}
-catch(RejectedExecutionException e)
-{
-logger.error(Failed to dispatch thread:, e);
-return false;
-}
-}
-public int getIdleThreads()
-{
-return getPoolSize()-getActiveCount();
-}
-
-public int getThreads()
-{
-return getPoolSize();
-}
-
-public boolean isLowOnThreads()
-{
-return getActiveCount()=getMaximumPoolSize();
-}
-
-public void join() throws InterruptedException
-{
-this.awaitTermination(Long.MAX_VALUE,TimeUnit.MILLISECONDS);
-}
}
}
[jira] Created: (CASSANDRA-2066) 2 (more) Misuses of ByteBuffer relative gets
2 (more) Misuses of ByteBuffer relative gets Key: CASSANDRA-2066 URL: https://issues.apache.org/jira/browse/CASSANDRA-2066 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 0.7.1 In RandomPartitioner and SerDeUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2066) 2 (more) Misuses of ByteBuffer relative gets
[ https://issues.apache.org/jira/browse/CASSANDRA-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2066: Attachment: 0001-Fix-2-misuses-of-ByteBuffer-relative-gets.patch Patch attached agains 0.7 branch. I include a slight optimisation of ByteBufferUtil.getArray() too, that will avoid a copy at least in some current use of RandomPartitionner.factory().fromByteArray() (and possibly other places) 2 (more) Misuses of ByteBuffer relative gets Key: CASSANDRA-2066 URL: https://issues.apache.org/jira/browse/CASSANDRA-2066 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 0.7.1 Attachments: 0001-Fix-2-misuses-of-ByteBuffer-relative-gets.patch In RandomPartitioner and SerDeUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064186 - in /cassandra/branches/cassandra-0.7: ./ src/java/org/apache/cassandra/dht/ src/java/org/apache/cassandra/hadoop/ src/java/org/apache/cassandra/io/ src/java/org/apache/cassandra
Author: jbellis
Date: Thu Jan 27 16:36:51 2011
New Revision: 1064186
URL: http://svn.apache.org/viewvc?rev=1064186view=rev
Log:
fix possibleByteBuffer race conditions
patch by slebresne; reviewed by jbellis for CASSANDRA-2066
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/SerDeUtils.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1064186r1=1064185r2=1064186view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Jan 27 16:36:51 2011
@@ -3,6 +3,7 @@
* add JVM shutdownhook to sync commitlog (CASSANDRA-1919)
* allow nodes to be up without being part of normal traffic (CASSANDRA-1951)
* fix CLI show keyspaces with null options on NTS (CASSANDRA-2049)
+ * fix possible ByteBuffer race conditions (CASSANDRA-2066)
0.7.1
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java?rev=1064186r1=1064185r2=1064186view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
Thu Jan 27 16:36:51 2011
@@ -98,11 +98,7 @@ public class RandomPartitioner implement
public TokenBigInteger fromByteArray(ByteBuffer bytes)
{
-byte[] b = new byte[bytes.remaining()];
-bytes.get(b);
-bytes.rewind();
-
-return new BigIntegerToken(new BigInteger(b));
+return new BigIntegerToken(new
BigInteger(ByteBufferUtil.getArray(bytes)));
}
public String toString(TokenBigInteger bigIntegerToken)
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java?rev=1064186r1=1064185r2=1064186view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
Thu Jan 27 16:36:51 2011
@@ -40,7 +40,7 @@ import org.apache.hadoop.mapreduce.TaskA
import org.apache.thrift.TException;
import org.apache.thrift.transport.TSocket;
-import static org.apache.cassandra.io.SerDeUtils.copy;
+import org.apache.cassandra.utils.ByteBufferUtil;
/**
* The codeColumnFamilyRecordWriter/code maps the output lt;key, valuegt;
@@ -169,7 +169,7 @@ implements org.apache.hadoop.mapred.Reco
org.apache.cassandra.avro.SlicePredicate apred =
amut.deletion.predicate;
if (amut.deletion.super_column != null)
// super column
-deletion.setSuper_column(copy(amut.deletion.super_column));
+
deletion.setSuper_column(ByteBufferUtil.getArray(amut.deletion.super_column));
else if (apred.column_names != null)
{
// column names
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/SerDeUtils.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/SerDeUtils.java?rev=1064186r1=1064185r2=1064186view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/SerDeUtils.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/SerDeUtils.java
Thu Jan 27 16:36:51 2011
@@ -45,14 +45,6 @@ public final class SerDeUtils
// unbuffered decoders
private final static DecoderFactory DIRECT_DECODERS = new
DecoderFactory().configureDirectDecoder(true);
-public static byte[] copy(ByteBuffer buff)
-{
-byte[] bytes = new byte[buff.remaining()];
-buff.get(bytes);
-buff.rewind();
-return bytes;
-}
-
/**
* Deserializes a single object based on the given Schema.
* @param writer writer's schema
Modified:
[jira] Commented: (CASSANDRA-2050) AbstractDaemon unnecessarily uses jetty interface
[ https://issues.apache.org/jira/browse/CASSANDRA-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987637#action_12987637 ] Hudson commented on CASSANDRA-2050: --- Integrated in Cassandra-0.7 #219 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/219/]) AbstractDaemon unnecessarily uses jetty interface - Key: CASSANDRA-2050 URL: https://issues.apache.org/jira/browse/CASSANDRA-2050 Project: Cassandra Issue Type: Task Components: API Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.8 Attachments: 2050.txt AbstractDaemon's CleaningThreadPool need not implement this jetty interface. Removing this would allow us to remove jetty dependency altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2058) Nodes periodically spike in load
[ https://issues.apache.org/jira/browse/CASSANDRA-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987642#action_12987642 ] Brandon Williams commented on CASSANDRA-2058: - 0.6 version looks good, RR, HH, and DES work, no more CPU spikes under heavy load. Nodes periodically spike in load Key: CASSANDRA-2058 URL: https://issues.apache.org/jira/browse/CASSANDRA-2058 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6.10 Reporter: David King Assignee: Jonathan Ellis Attachments: 2058-0.7.txt, 2058.txt, cassandra.pmc01.log.bz2, cassandra.pmc14.log.bz2, graph a.png, graph b.png (Filing as a placeholder bug as I gather information.) At ~10p 24 Jan, I upgraded our 20-node cluster from 0.6.8-0.6.10, turned on the DES, and moved some CFs from one KS into another (drain whole cluster, take it down, move files, change schema, put it back up). Since then, I've had four storms whereby a node's load will shoot to 700+ (400% CPU on a 4-cpu machine) and become totally unresponsive. After a moment or two like that, its neighbour dies too, and the failure cascades around the ring. Unfortunately because of the high load I'm not able to get into the machine to pull a thread dump to see wtf it's doing as it happens. I've also had an issue where a single node spikes up to high load, but recovers. This may or may not be the same issue from which the nodes don't recover as above, but both are new behaviour -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064193 - in /cassandra/branches/cassandra-0.6: ./ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/net/ src/java/org/apache/cassandra/service/ src/java/org/apache/cassandr
Author: jbellis
Date: Thu Jan 27 16:53:44 2011
New Revision: 1064193
URL: http://svn.apache.org/viewvc?rev=1064193view=rev
Log:
reduce garbage generated by MessagingServiceto prevent loadspikes
patch by jbellis; reviewed by brandonwilliams and tjake for CASSANDRA-2058
Modified:
cassandra/branches/cassandra-0.6/CHANGES.txt
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/HintedHandOffManager.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/AsyncResult.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/Header.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/Message.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/MessagingService.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/ResponseVerbHandler.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/service/ConsistencyChecker.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/service/QuorumResponseHandler.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/service/StorageProxy.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/service/WriteResponseHandler.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/utils/ExpiringMap.java
Modified: cassandra/branches/cassandra-0.6/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/CHANGES.txt?rev=1064193r1=1064192r2=1064193view=diff
==
--- cassandra/branches/cassandra-0.6/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.6/CHANGES.txt Thu Jan 27 16:53:44 2011
@@ -1,3 +1,8 @@
+0.6.11
+ * reduce garbage generated by MessagingService to prevent load spikes
+ (CASSANDRA-2058)
+
+
0.6.10
* buffer network stack to avoid inefficient small TCP messages while avoiding
the nagle/delayed ack problem (CASSANDRA-1896)
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/HintedHandOffManager.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/HintedHandOffManager.java?rev=1064193r1=1064192r2=1064193view=diff
==
---
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/HintedHandOffManager.java
(original)
+++
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/db/HintedHandOffManager.java
Thu Jan 27 16:53:44 2011
@@ -130,7 +130,7 @@ public class HintedHandOffManager
rm.add(cf);
Message message = rm.makeRowMutationMessage();
WriteResponseHandler responseHandler = new
WriteResponseHandler(1, tableName);
-MessagingService.instance.sendRR(message, new InetAddress[] {
endPoint }, responseHandler);
+MessagingService.instance.sendRR(message, endPoint,
responseHandler);
try
{
responseHandler.get();
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/AsyncResult.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/AsyncResult.java?rev=1064193r1=1064192r2=1064193view=diff
==
---
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/AsyncResult.java
(original)
+++
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/AsyncResult.java
Thu Jan 27 16:53:44 2011
@@ -121,8 +121,6 @@ class AsyncResult implements IAsyncResul
{
lock_.unlock();
}
-
-MessagingService.removeRegisteredCallback(response.getMessageId());
}
public InetAddress getFrom()
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/Header.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/Header.java?rev=1064193r1=1064192r2=1064193view=diff
==
---
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/Header.java
(original)
+++
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/Header.java
Thu Jan 27 16:53:44 2011
@@ -95,11 +95,6 @@ public class Header
return messageId_;
}
-void setMessageId(String id)
-{
-messageId_ = id;
-}
-
byte[] getDetail(Object key)
{
return details_.get(key);
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/Message.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/net/Message.java?rev=1064193r1=1064192r2=1064193view=diff
[jira] Commented: (CASSANDRA-2066) 2 (more) Misuses of ByteBuffer relative gets
[ https://issues.apache.org/jira/browse/CASSANDRA-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987643#action_12987643 ] Hudson commented on CASSANDRA-2066: --- Integrated in Cassandra-0.7 #220 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/220/]) fix possibleByteBuffer race conditions patch by slebresne; reviewed by jbellis for CASSANDRA-2066 2 (more) Misuses of ByteBuffer relative gets Key: CASSANDRA-2066 URL: https://issues.apache.org/jira/browse/CASSANDRA-2066 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 0.7.2 Attachments: 0001-Fix-2-misuses-of-ByteBuffer-relative-gets.patch In RandomPartitioner and SerDeUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2058) Nodes periodically spike in load
[ https://issues.apache.org/jira/browse/CASSANDRA-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2058: -- Affects Version/s: 0.7.1 Fix Version/s: 0.7.1 0.6.11 committed 0.6 version Nodes periodically spike in load Key: CASSANDRA-2058 URL: https://issues.apache.org/jira/browse/CASSANDRA-2058 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6.10, 0.7.1 Reporter: David King Assignee: Jonathan Ellis Fix For: 0.6.11, 0.7.1 Attachments: 2058-0.7.txt, 2058.txt, cassandra.pmc01.log.bz2, cassandra.pmc14.log.bz2, graph a.png, graph b.png (Filing as a placeholder bug as I gather information.) At ~10p 24 Jan, I upgraded our 20-node cluster from 0.6.8-0.6.10, turned on the DES, and moved some CFs from one KS into another (drain whole cluster, take it down, move files, change schema, put it back up). Since then, I've had four storms whereby a node's load will shoot to 700+ (400% CPU on a 4-cpu machine) and become totally unresponsive. After a moment or two like that, its neighbour dies too, and the failure cascades around the ring. Unfortunately because of the high load I'm not able to get into the machine to pull a thread dump to see wtf it's doing as it happens. I've also had an issue where a single node spikes up to high load, but recovers. This may or may not be the same issue from which the nodes don't recover as above, but both are new behaviour -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1997) Cassandra-Maven-Plugin
[ https://issues.apache.org/jira/browse/CASSANDRA-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987651#action_12987651 ] Eric Evans commented on CASSANDRA-1997: --- contrib/ has not worked well for us, and we're currently in the process of removing it. See CASSANDRA-1805. Cassandra-Maven-Plugin -- Key: CASSANDRA-1997 URL: https://issues.apache.org/jira/browse/CASSANDRA-1997 Project: Cassandra Issue Type: New Feature Reporter: Stephen Connolly Attachments: CASSANDRA-1997-v2.patch, cassandra-maven-plugin.0.7.patch, cassandra-maven-plugin.tar.gz A maven plugin to allow controlling a test instance of cassandra from within maven builds -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2058) Nodes periodically spike in load
[ https://issues.apache.org/jira/browse/CASSANDRA-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987655#action_12987655 ] Hudson commented on CASSANDRA-2058: --- Integrated in Cassandra-0.6 #52 (See [https://hudson.apache.org/hudson/job/Cassandra-0.6/52/]) reduce garbage generated by MessagingServiceto prevent loadspikes patch by jbellis; reviewed by brandonwilliams and tjake for CASSANDRA-2058 Nodes periodically spike in load Key: CASSANDRA-2058 URL: https://issues.apache.org/jira/browse/CASSANDRA-2058 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6.10, 0.7.1 Reporter: David King Assignee: Jonathan Ellis Fix For: 0.6.11, 0.7.1 Attachments: 2058-0.7.txt, 2058.txt, cassandra.pmc01.log.bz2, cassandra.pmc14.log.bz2, graph a.png, graph b.png (Filing as a placeholder bug as I gather information.) At ~10p 24 Jan, I upgraded our 20-node cluster from 0.6.8-0.6.10, turned on the DES, and moved some CFs from one KS into another (drain whole cluster, take it down, move files, change schema, put it back up). Since then, I've had four storms whereby a node's load will shoot to 700+ (400% CPU on a 4-cpu machine) and become totally unresponsive. After a moment or two like that, its neighbour dies too, and the failure cascades around the ring. Unfortunately because of the high load I'm not able to get into the machine to pull a thread dump to see wtf it's doing as it happens. I've also had an issue where a single node spikes up to high load, but recovers. This may or may not be the same issue from which the nodes don't recover as above, but both are new behaviour -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1956) Convert row cache to row+filter cache
[ https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Doubleday updated CASSANDRA-1956: Attachment: (was: 0001-row-cache-filter.patch) Convert row cache to row+filter cache - Key: CASSANDRA-1956 URL: https://issues.apache.org/jira/browse/CASSANDRA-1956 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Stu Hood Assignee: Daniel Doubleday Fix For: 0.7.2 Changing the row cache to a row+filter cache would make it much more useful. We currently have to warn against using the row cache with wide rows, where the read pattern is typically a peek at the head, but this usecase would be perfect supported by a cache that stored only columns matching the filter. Possible implementations: * (copout) Cache a single filter per row, and leave the cache key as is * Cache a list of filters per row, leaving the cache key as is: this is likely to have some gotchas for weird usage patterns, and it requires the list overheard * Change the cache key to rowkey+filterid: basically ideal, but you need a secondary index to lookup cache entries by rowkey so that you can keep them in sync with the memtable * others? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1956) Convert row cache to row+filter cache
[ https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Doubleday updated CASSANDRA-1956: Attachment: 0001-row-cache-filter.patch Allow filter to invalidate row TailRowCacheFilter invalidates cache if a column within its range is deleted Convert row cache to row+filter cache - Key: CASSANDRA-1956 URL: https://issues.apache.org/jira/browse/CASSANDRA-1956 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Stu Hood Assignee: Daniel Doubleday Fix For: 0.7.2 Attachments: 0001-row-cache-filter.patch Changing the row cache to a row+filter cache would make it much more useful. We currently have to warn against using the row cache with wide rows, where the read pattern is typically a peek at the head, but this usecase would be perfect supported by a cache that stored only columns matching the filter. Possible implementations: * (copout) Cache a single filter per row, and leave the cache key as is * Cache a list of filters per row, leaving the cache key as is: this is likely to have some gotchas for weird usage patterns, and it requires the list overheard * Change the cache key to rowkey+filterid: basically ideal, but you need a secondary index to lookup cache entries by rowkey so that you can keep them in sync with the memtable * others? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064231 - in /cassandra/branches/cassandra-0.6: build.xml debian/changelog
Author: eevans
Date: Thu Jan 27 17:54:19 2011
New Revision: 1064231
URL: http://svn.apache.org/viewvc?rev=1064231view=rev
Log:
updated versioning 0.6.11 release
Modified:
cassandra/branches/cassandra-0.6/build.xml
cassandra/branches/cassandra-0.6/debian/changelog
Modified: cassandra/branches/cassandra-0.6/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/build.xml?rev=1064231r1=1064230r2=1064231view=diff
==
--- cassandra/branches/cassandra-0.6/build.xml (original)
+++ cassandra/branches/cassandra-0.6/build.xml Thu Jan 27 17:54:19 2011
@@ -42,7 +42,7 @@
property name=test.name value=*Test/
property name=test.unit.src value=${test.dir}/unit/
property name=dist.dir value=${build.dir}/dist/
-property name=version value=0.6.10/
+property name=version value=0.6.11/
property name=final.name value=${ant.project.name}-${version}/
property name=ivy.version value=2.1.0 /
property name=ivy.url
Modified: cassandra/branches/cassandra-0.6/debian/changelog
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/debian/changelog?rev=1064231r1=1064230r2=1064231view=diff
==
--- cassandra/branches/cassandra-0.6/debian/changelog (original)
+++ cassandra/branches/cassandra-0.6/debian/changelog Thu Jan 27 17:54:19 2011
@@ -1,3 +1,9 @@
+cassandra (0.6.11) unstable; urgency=low
+
+ * New stable point release.
+
+ -- Eric Evans eev...@apache.org Thu, 27 Jan 2011 11:40:17 -0600
+
cassandra (0.6.10) unstable; urgency=low
* New stable point release.
[jira] Updated: (CASSANDRA-2058) Nodes periodically spike in load
[ https://issues.apache.org/jira/browse/CASSANDRA-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2058: Attachment: 2058-0.7-v2.txt 0.7 v2 fixes the DES by incorporating the approach from CASSANDRA-2004 and having it register with MS directly and removing ILP. However, it does not receive timings for the local node. Nodes periodically spike in load Key: CASSANDRA-2058 URL: https://issues.apache.org/jira/browse/CASSANDRA-2058 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6.10, 0.7.1 Reporter: David King Assignee: Jonathan Ellis Fix For: 0.6.11, 0.7.1 Attachments: 2058-0.7-v2.txt, 2058-0.7.txt, 2058.txt, cassandra.pmc01.log.bz2, cassandra.pmc14.log.bz2, graph a.png, graph b.png (Filing as a placeholder bug as I gather information.) At ~10p 24 Jan, I upgraded our 20-node cluster from 0.6.8-0.6.10, turned on the DES, and moved some CFs from one KS into another (drain whole cluster, take it down, move files, change schema, put it back up). Since then, I've had four storms whereby a node's load will shoot to 700+ (400% CPU on a 4-cpu machine) and become totally unresponsive. After a moment or two like that, its neighbour dies too, and the failure cascades around the ring. Unfortunately because of the high load I'm not able to get into the machine to pull a thread dump to see wtf it's doing as it happens. I've also had an issue where a single node spikes up to high load, but recovers. This may or may not be the same issue from which the nodes don't recover as above, but both are new behaviour -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064246 - in /cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator: DynamicEndpointSnitch.java DynamicEndpointSnitchMBean.java
Author: brandonwilliams
Date: Thu Jan 27 18:33:13 2011
New Revision: 1064246
URL: http://svn.apache.org/viewvc?rev=1064246view=rev
Log:
Add ability to dump DES timings
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java?rev=1064246r1=1064245r2=1064246view=diff
==
---
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
(original)
+++
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
Thu Jan 27 18:33:13 2011
@@ -174,6 +174,21 @@ public class DynamicEndpointSnitch exten
{
return scores;
}
+
+public ListDouble dumpTimings(String hostname) throws
UnknownHostException
+{
+InetAddress host = InetAddress.getByName(hostname);
+ArrayListDouble timings = new ArrayListDouble();
+AdaptiveLatencyTracker window = windows.get(host);
+if (window != null)
+{
+for (double time: window)
+{
+timings.add(time);
+}
+}
+return timings;
+}
}
/** a threadsafe version of BoundedStatsDeque+ArrivalWindow with modification
for arbitrary times **/
Modified:
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java?rev=1064246r1=1064245r2=1064246view=diff
==
---
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java
(original)
+++
cassandra/branches/cassandra-0.6/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java
Thu Jan 27 18:33:13 2011
@@ -20,8 +20,11 @@
package org.apache.cassandra.locator;
import java.net.InetAddress;
+import java.net.UnknownHostException;
import java.util.Map;
+import java.util.List;
public interface DynamicEndpointSnitchMBean {
public MapInetAddress, Double getScores();
+public ListDouble dumpTimings(String hostname) throws
UnknownHostException;
}
[jira] Updated: (CASSANDRA-2058) Nodes periodically spike in load
[ https://issues.apache.org/jira/browse/CASSANDRA-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2058: -- Attachment: 2058-0.7-v3.txt v3 adds latency tracking to LocalReadRunnable Nodes periodically spike in load Key: CASSANDRA-2058 URL: https://issues.apache.org/jira/browse/CASSANDRA-2058 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6.10, 0.7.1 Reporter: David King Assignee: Jonathan Ellis Fix For: 0.6.11, 0.7.1 Attachments: 2058-0.7-v2.txt, 2058-0.7-v3.txt, 2058-0.7.txt, 2058.txt, cassandra.pmc01.log.bz2, cassandra.pmc14.log.bz2, graph a.png, graph b.png (Filing as a placeholder bug as I gather information.) At ~10p 24 Jan, I upgraded our 20-node cluster from 0.6.8-0.6.10, turned on the DES, and moved some CFs from one KS into another (drain whole cluster, take it down, move files, change schema, put it back up). Since then, I've had four storms whereby a node's load will shoot to 700+ (400% CPU on a 4-cpu machine) and become totally unresponsive. After a moment or two like that, its neighbour dies too, and the failure cascades around the ring. Unfortunately because of the high load I'm not able to get into the machine to pull a thread dump to see wtf it's doing as it happens. I've also had an issue where a single node spikes up to high load, but recovers. This may or may not be the same issue from which the nodes don't recover as above, but both are new behaviour -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2008) CLI help incorrect in places
[ https://issues.apache.org/jira/browse/CASSANDRA-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987704#action_12987704 ] Jon Hermes commented on CASSANDRA-2008: --- The YAML should be correct, and http://wiki.apache.org/cassandra/StorageConfiguration should be ultimately correct. All should say the same things. CLI help incorrect in places Key: CASSANDRA-2008 URL: https://issues.apache.org/jira/browse/CASSANDRA-2008 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Aaron Morton Assignee: Aaron Morton Priority: Trivial Fix For: 0.7.2 Found some errors in the CLI help, such as these for create column family. - memtable_operations: Flush memtables after this many operations - memtable_throughput: ... or after this many bytes have been written - memtable_flush_after: ... or after this many seconds Should be millions of ops, MB's written and minutes not seconds. Have confirmed thats how the values are used. Will check all the help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1938) Use UUID as node identifiers in counters instead of IP addresses
[ https://issues.apache.org/jira/browse/CASSANDRA-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-1938: Attachment: 1938_discussion 0001-Use-uuid-instead-of-IP-for-counters.patch Patch attached. It passes basic testing (unit tests, system test and 'throwing a bunch of increments to a 3 nodes cluster' test). I don't think this is a trivial patch (though I could be stupid) so the more people have a look, the merrier and all feedback is welcome. I've also attached a companion text file with some (lengthy but hopefully helpful) explanations of how it works and which problems it solves (and how). Use UUID as node identifiers in counters instead of IP addresses - Key: CASSANDRA-1938 URL: https://issues.apache.org/jira/browse/CASSANDRA-1938 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 0.8 Attachments: 0001-Use-uuid-instead-of-IP-for-counters.patch, 1938_discussion Original Estimate: 56h Remaining Estimate: 56h The use of IP addresses as node identifiers in the partition of a given counter is fragile. Changes of the node's IP addresses can result in data loss. This patch proposes to use UUIDs instead. NOTE: this breaks the on-disk file format (for counters) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2067) refactor o.a.c.utils.UUIDGen to allow creating type 1 UUIDs for a given time
refactor o.a.c.utils.UUIDGen to allow creating type 1 UUIDs for a given time Key: CASSANDRA-2067 URL: https://issues.apache.org/jira/browse/CASSANDRA-2067 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Eric Evans Fix For: 0.8 CASSANDRA-2027 creates the need to generate type 1 UUIDs using arbitrary date/times. IMO, this would be a good opportunity to replace o.a.c.utils.UUIDGen with the class that Gary Dusbabek wrote for Flewton (https://github.com/flewton/flewton/blob/master/src/com/rackspace/flewton/util/UUIDGen.java), which is better/more comprehensive. We can even eliminate the dependency on JUG. Patches to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2067) refactor o.a.c.utils.UUIDGen to allow creating type 1 UUIDs for a given time
[ https://issues.apache.org/jira/browse/CASSANDRA-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987713#action_12987713 ] Eric Evans commented on CASSANDRA-2067: --- The patches have followed. refactor o.a.c.utils.UUIDGen to allow creating type 1 UUIDs for a given time Key: CASSANDRA-2067 URL: https://issues.apache.org/jira/browse/CASSANDRA-2067 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Eric Evans Fix For: 0.8 CASSANDRA-2027 creates the need to generate type 1 UUIDs using arbitrary date/times. IMO, this would be a good opportunity to replace o.a.c.utils.UUIDGen with the class that Gary Dusbabek wrote for Flewton (https://github.com/flewton/flewton/blob/master/src/com/rackspace/flewton/util/UUIDGen.java), which is better/more comprehensive. We can even eliminate the dependency on JUG. Patches to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2027) term definitions
[
https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2027:
--
Attachment: v1-0003-remove-JUG-jar-and-references.txt
v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt
v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.txt
term definitions
Key: CASSANDRA-2027
URL: https://issues.apache.org/jira/browse/CASSANDRA-2027
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Attachments:
v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.txt,
v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt,
v1-0003-remove-JUG-jar-and-references.txt
Original Estimate: 0h
Remaining Estimate: 0h
h3. String
Anything between double-quotes. Node-side this is just converted to bytes,
so it could really be used to represent *any* type so long as it is
appropriately encoded.
Examples:
{code:style=SQL}
SELECT name FROM cf;
UPDATE cf SET name = value WHERE KEY = key;
{code}
h3. UTF-8
A double-quoted string literal that is prefixed with a u to indicated that
it should be encoded to bytes using the utf-8 charset node-side.
Examples:
{code:style=SQL}
SELECT uname FROM cf;
UPDATE cf SET uname = uvalue WHERE KEY = key;
{code}
h3. Integer
An undecorated numeric literal, converted to a 4-byte int node-side.
Examples:
{code:style=SQL}
SELECT 10..100 FROM cf WHERE KEY = key;
UPDATE cf SET 1000 = thousand, 100 = hundred WHERE KEY = key;
{code}
h3. Long
A numeric literal suffixed with an L, converted to an 8-byte long node-side.
Examples:
{code:style=SQL}
SELECT 10L..100L FROM cf WHERE KEY = key;
UPDATE cf SET 1000L = thousand, 100L = hundred WHERE KEY = key;
{code}
h3. UUID
A string-formatted UUID supplied as an argument to a ctor/function formated
string ({{uuid(uuid string)}}). Node-side this is converted back to the
corresponding UUID.
Examples:
{code:style=SQL}
SELECT uuid(5f989e95-ae07-4425-b84a-6876ba106c66) FROM cf WHERE KEY = key;
UPDATE cf SET uuid(5621b93d-d3a2-4d22-8a59-bdb93202b6cb) = username WHERE
KEY = key;
{code}
h3. TimeUUID (UUID Type 1)
A string-formatted time-based UUID (type 1) supplied as an argument to a
ctor/function formated string ({{timeuuid(uuid string)}}). Node-side this
is converted back to the corresponding UUID. In addition to a
string-formatted UUID, it should also be possible to supply dates in a
variety of formats which will result in a new UUID being created node-side.
Examples:
{code:style=SQL}
SELECT timeuuid(2011-01-01)..timeuuid(2010-01-21) FROM cf WHERE KEY = key;
UPDATE cf SET timeuuid(now) = 1000L WHERE KEY = key;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2067) refactor o.a.c.utils.UUIDGen to allow creating type 1 UUIDs for a given time
[ https://issues.apache.org/jira/browse/CASSANDRA-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2067: -- Attachment: v1-0003-remove-JUG-jar-and-references.txt v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt v1-0001-CASSANDRA-2067-o.a.c.utils.UUIDGen-adapted-from-flewto.txt refactor o.a.c.utils.UUIDGen to allow creating type 1 UUIDs for a given time Key: CASSANDRA-2067 URL: https://issues.apache.org/jira/browse/CASSANDRA-2067 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Eric Evans Fix For: 0.8 Attachments: v1-0001-CASSANDRA-2067-o.a.c.utils.UUIDGen-adapted-from-flewto.txt, v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt, v1-0003-remove-JUG-jar-and-references.txt CASSANDRA-2027 creates the need to generate type 1 UUIDs using arbitrary date/times. IMO, this would be a good opportunity to replace o.a.c.utils.UUIDGen with the class that Gary Dusbabek wrote for Flewton (https://github.com/flewton/flewton/blob/master/src/com/rackspace/flewton/util/UUIDGen.java), which is better/more comprehensive. We can even eliminate the dependency on JUG. Patches to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2027) term definitions
[
https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2027:
--
Attachment: (was: v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt)
term definitions
Key: CASSANDRA-2027
URL: https://issues.apache.org/jira/browse/CASSANDRA-2027
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Attachments:
v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.txt
Original Estimate: 0h
Remaining Estimate: 0h
h3. String
Anything between double-quotes. Node-side this is just converted to bytes,
so it could really be used to represent *any* type so long as it is
appropriately encoded.
Examples:
{code:style=SQL}
SELECT name FROM cf;
UPDATE cf SET name = value WHERE KEY = key;
{code}
h3. UTF-8
A double-quoted string literal that is prefixed with a u to indicated that
it should be encoded to bytes using the utf-8 charset node-side.
Examples:
{code:style=SQL}
SELECT uname FROM cf;
UPDATE cf SET uname = uvalue WHERE KEY = key;
{code}
h3. Integer
An undecorated numeric literal, converted to a 4-byte int node-side.
Examples:
{code:style=SQL}
SELECT 10..100 FROM cf WHERE KEY = key;
UPDATE cf SET 1000 = thousand, 100 = hundred WHERE KEY = key;
{code}
h3. Long
A numeric literal suffixed with an L, converted to an 8-byte long node-side.
Examples:
{code:style=SQL}
SELECT 10L..100L FROM cf WHERE KEY = key;
UPDATE cf SET 1000L = thousand, 100L = hundred WHERE KEY = key;
{code}
h3. UUID
A string-formatted UUID supplied as an argument to a ctor/function formated
string ({{uuid(uuid string)}}). Node-side this is converted back to the
corresponding UUID.
Examples:
{code:style=SQL}
SELECT uuid(5f989e95-ae07-4425-b84a-6876ba106c66) FROM cf WHERE KEY = key;
UPDATE cf SET uuid(5621b93d-d3a2-4d22-8a59-bdb93202b6cb) = username WHERE
KEY = key;
{code}
h3. TimeUUID (UUID Type 1)
A string-formatted time-based UUID (type 1) supplied as an argument to a
ctor/function formated string ({{timeuuid(uuid string)}}). Node-side this
is converted back to the corresponding UUID. In addition to a
string-formatted UUID, it should also be possible to supply dates in a
variety of formats which will result in a new UUID being created node-side.
Examples:
{code:style=SQL}
SELECT timeuuid(2011-01-01)..timeuuid(2010-01-21) FROM cf WHERE KEY = key;
UPDATE cf SET timeuuid(now) = 1000L WHERE KEY = key;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2027) term definitions
[
https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2027:
--
Attachment: (was: v1-0003-remove-JUG-jar-and-references.txt)
term definitions
Key: CASSANDRA-2027
URL: https://issues.apache.org/jira/browse/CASSANDRA-2027
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Attachments:
v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.txt
Original Estimate: 0h
Remaining Estimate: 0h
h3. String
Anything between double-quotes. Node-side this is just converted to bytes,
so it could really be used to represent *any* type so long as it is
appropriately encoded.
Examples:
{code:style=SQL}
SELECT name FROM cf;
UPDATE cf SET name = value WHERE KEY = key;
{code}
h3. UTF-8
A double-quoted string literal that is prefixed with a u to indicated that
it should be encoded to bytes using the utf-8 charset node-side.
Examples:
{code:style=SQL}
SELECT uname FROM cf;
UPDATE cf SET uname = uvalue WHERE KEY = key;
{code}
h3. Integer
An undecorated numeric literal, converted to a 4-byte int node-side.
Examples:
{code:style=SQL}
SELECT 10..100 FROM cf WHERE KEY = key;
UPDATE cf SET 1000 = thousand, 100 = hundred WHERE KEY = key;
{code}
h3. Long
A numeric literal suffixed with an L, converted to an 8-byte long node-side.
Examples:
{code:style=SQL}
SELECT 10L..100L FROM cf WHERE KEY = key;
UPDATE cf SET 1000L = thousand, 100L = hundred WHERE KEY = key;
{code}
h3. UUID
A string-formatted UUID supplied as an argument to a ctor/function formated
string ({{uuid(uuid string)}}). Node-side this is converted back to the
corresponding UUID.
Examples:
{code:style=SQL}
SELECT uuid(5f989e95-ae07-4425-b84a-6876ba106c66) FROM cf WHERE KEY = key;
UPDATE cf SET uuid(5621b93d-d3a2-4d22-8a59-bdb93202b6cb) = username WHERE
KEY = key;
{code}
h3. TimeUUID (UUID Type 1)
A string-formatted time-based UUID (type 1) supplied as an argument to a
ctor/function formated string ({{timeuuid(uuid string)}}). Node-side this
is converted back to the corresponding UUID. In addition to a
string-formatted UUID, it should also be possible to supply dates in a
variety of formats which will result in a new UUID being created node-side.
Examples:
{code:style=SQL}
SELECT timeuuid(2011-01-01)..timeuuid(2010-01-21) FROM cf WHERE KEY = key;
UPDATE cf SET timeuuid(now) = 1000L WHERE KEY = key;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2027) term definitions
[
https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2027:
--
Attachment: (was:
v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.txt)
term definitions
Key: CASSANDRA-2027
URL: https://issues.apache.org/jira/browse/CASSANDRA-2027
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Fix For: 0.8
Original Estimate: 0h
Remaining Estimate: 0h
h3. String
Anything between double-quotes. Node-side this is just converted to bytes,
so it could really be used to represent *any* type so long as it is
appropriately encoded.
Examples:
{code:style=SQL}
SELECT name FROM cf;
UPDATE cf SET name = value WHERE KEY = key;
{code}
h3. UTF-8
A double-quoted string literal that is prefixed with a u to indicated that
it should be encoded to bytes using the utf-8 charset node-side.
Examples:
{code:style=SQL}
SELECT uname FROM cf;
UPDATE cf SET uname = uvalue WHERE KEY = key;
{code}
h3. Integer
An undecorated numeric literal, converted to a 4-byte int node-side.
Examples:
{code:style=SQL}
SELECT 10..100 FROM cf WHERE KEY = key;
UPDATE cf SET 1000 = thousand, 100 = hundred WHERE KEY = key;
{code}
h3. Long
A numeric literal suffixed with an L, converted to an 8-byte long node-side.
Examples:
{code:style=SQL}
SELECT 10L..100L FROM cf WHERE KEY = key;
UPDATE cf SET 1000L = thousand, 100L = hundred WHERE KEY = key;
{code}
h3. UUID
A string-formatted UUID supplied as an argument to a ctor/function formated
string ({{uuid(uuid string)}}). Node-side this is converted back to the
corresponding UUID.
Examples:
{code:style=SQL}
SELECT uuid(5f989e95-ae07-4425-b84a-6876ba106c66) FROM cf WHERE KEY = key;
UPDATE cf SET uuid(5621b93d-d3a2-4d22-8a59-bdb93202b6cb) = username WHERE
KEY = key;
{code}
h3. TimeUUID (UUID Type 1)
A string-formatted time-based UUID (type 1) supplied as an argument to a
ctor/function formated string ({{timeuuid(uuid string)}}). Node-side this
is converted back to the corresponding UUID. In addition to a
string-formatted UUID, it should also be possible to supply dates in a
variety of formats which will result in a new UUID being created node-side.
Examples:
{code:style=SQL}
SELECT timeuuid(2011-01-01)..timeuuid(2010-01-21) FROM cf WHERE KEY = key;
UPDATE cf SET timeuuid(now) = 1000L WHERE KEY = key;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2067) refactor o.a.c.utils.UUIDGen to allow creating type 1 UUIDs for a given time
[ https://issues.apache.org/jira/browse/CASSANDRA-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2067: -- Reviewer: brandon.williams refactor o.a.c.utils.UUIDGen to allow creating type 1 UUIDs for a given time Key: CASSANDRA-2067 URL: https://issues.apache.org/jira/browse/CASSANDRA-2067 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Eric Evans Fix For: 0.8 Attachments: v1-0001-CASSANDRA-2067-o.a.c.utils.UUIDGen-adapted-from-flewto.txt, v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt, v1-0003-remove-JUG-jar-and-references.txt CASSANDRA-2027 creates the need to generate type 1 UUIDs using arbitrary date/times. IMO, this would be a good opportunity to replace o.a.c.utils.UUIDGen with the class that Gary Dusbabek wrote for Flewton (https://github.com/flewton/flewton/blob/master/src/com/rackspace/flewton/util/UUIDGen.java), which is better/more comprehensive. We can even eliminate the dependency on JUG. Patches to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2068) Improvements for Multi-tenant clusters
Improvements for Multi-tenant clusters -- Key: CASSANDRA-2068 URL: https://issues.apache.org/jira/browse/CASSANDRA-2068 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor It would be helpful if we could actually set some limits per CF to help Multi-tenant clusters. Here are some ideas I was thinking: (per CF) 1. Set an upper bound (max) for count when slicing or multi/get calls 2. Set an upper bound (max) for how much data in bytes can be returned (64KB, 512KB, 1MB, etc) This would introduce new exceptions that can be thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Cassandra Wiki] Update of MultiTenant by Chris Goffinet
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The MultiTenant page has been changed by Chris Goffinet. http://wiki.apache.org/cassandra/MultiTenant?action=diffrev1=23rev2=24 -- * Track per-user/per-keyspace statistics [[https://issues.apache.org/jira/browse/CASSANDRA-841|CASSANDRA-841]] * Improve load balancing to take into account load in terms of operations - probably add no. of operations performed on top of disk space used [[https://issues.apache.org/jira/browse/CASSANDRA-1037|CASSANDRA-1037]] * Provide relative memory usage settings for Memtables (and eventually caches) out of configurable totals [[https://issues.apache.org/jira/browse/CASSANDRA-2006|CASSANDRA-2006]] + * Set limits per CF to help prevent OOMing nodes [[https://issues.apache.org/jira/browse/CASSANDRA-2068|CASSANDRA-2068]] == Completed tickets having to do with multi-tenancy == * Ability to lock down schemas for Column Families - [[https://issues.apache.org/jira/browse/CASSANDRA-1554|CASSANDRA-1554]]
[jira] Commented: (CASSANDRA-1956) Convert row cache to row+filter cache
[ https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987739#action_12987739 ] Stu Hood commented on CASSANDRA-1956: - These are cached. If one of them gets deleted it would not be able to return a valid response. Ahh, sorry: quite right. Invalidation sounds like the best option there. I'll try and review this more closely in the next week, but I'm not sure I like the filter as a configuration option, as opposed to any of the ideas in the summary. Convert row cache to row+filter cache - Key: CASSANDRA-1956 URL: https://issues.apache.org/jira/browse/CASSANDRA-1956 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Stu Hood Assignee: Daniel Doubleday Fix For: 0.7.2 Attachments: 0001-row-cache-filter.patch Changing the row cache to a row+filter cache would make it much more useful. We currently have to warn against using the row cache with wide rows, where the read pattern is typically a peek at the head, but this usecase would be perfect supported by a cache that stored only columns matching the filter. Possible implementations: * (copout) Cache a single filter per row, and leave the cache key as is * Cache a list of filters per row, leaving the cache key as is: this is likely to have some gotchas for weird usage patterns, and it requires the list overheard * Change the cache key to rowkey+filterid: basically ideal, but you need a secondary index to lookup cache entries by rowkey so that you can keep them in sync with the memtable * others? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2061) Missing logging for some exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987750#action_12987750
]
Stu Hood commented on CASSANDRA-2061:
-
* 2061.txt doesn't completely remove RetryingSTPE.java, and doesn't replace the
usage in CFStore
* 2061-0.7.txt doesn't apply to the 0.7 branch
Also, will we need a separate patch for trunk?
Missing logging for some exceptions
---
Key: CASSANDRA-2061
URL: https://issues.apache.org/jira/browse/CASSANDRA-2061
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Stu Hood
Fix For: 0.7.2
Attachments: 2061-0.7.txt, 2061.txt
{quote}Since you are using ScheduledThreadPoolExecutor.schedule(), the
exception was swallowed by the FutureTask.
You will have to perform a get() method on the ScheduledFuture, and you will
get ExecutionException if there was any exception occured in run().{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1997) Cassandra-Maven-Plugin
[ https://issues.apache.org/jira/browse/CASSANDRA-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated CASSANDRA-1997: Attachment: CASSANDRA-1997-v3.patch Updated patch to add to tools (it would be first addition) and not contrib Cassandra-Maven-Plugin -- Key: CASSANDRA-1997 URL: https://issues.apache.org/jira/browse/CASSANDRA-1997 Project: Cassandra Issue Type: New Feature Reporter: Stephen Connolly Attachments: CASSANDRA-1997-v2.patch, CASSANDRA-1997-v3.patch, cassandra-maven-plugin.0.7.patch, cassandra-maven-plugin.tar.gz A maven plugin to allow controlling a test instance of cassandra from within maven builds -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064325 - /cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g
Author: eevans Date: Thu Jan 27 21:57:12 2011 New Revision: 1064325 URL: http://svn.apache.org/viewvc?rev=1064325view=rev Log: CASSANDRA-1709 allow underscores in IDENT Patch by eevans for CASSANDRA-1709 Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g?rev=1064325r1=1064324r2=1064325view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g (original) +++ cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g Thu Jan 27 21:57:12 2011 @@ -301,7 +301,7 @@ LONG ; IDENT -: LETTER (LETTER | DIGIT)* +: LETTER (LETTER | DIGIT | '_')* ; WS
svn commit: r1064326 - in /cassandra/trunk: src/java/org/apache/cassandra/cql/ test/system/
Author: eevans
Date: Thu Jan 27 21:57:20 2011
New Revision: 1064326
URL: http://svn.apache.org/viewvc?rev=1064326view=rev
Log:
CQL: keyspace creation
Patch by eevans for CASSANDRA-1709
Added:
cassandra/trunk/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
Modified:
cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g
cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
cassandra/trunk/src/java/org/apache/cassandra/cql/StatementType.java
cassandra/trunk/test/system/test_cql.py
Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g?rev=1064326r1=1064325r2=1064326view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g (original)
+++ cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g Thu Jan 27 21:57:20
2011
@@ -46,6 +46,7 @@ query returns [CQLStatement stmnt]
| useStatement { $stmnt = new CQLStatement(StatementType.USE,
$useStatement.keyspace); }
| truncateStatement { $stmnt = new CQLStatement(StatementType.TRUNCATE,
$truncateStatement.cfam); }
| deleteStatement { $stmnt = new CQLStatement(StatementType.DELETE,
$deleteStatement.expr); }
+| createKeyspaceStatement { $stmnt = new
CQLStatement(StatementType.CREATE_KEYSPACE, $createKeyspaceStatement.expr); }
;
// USE KEYSPACE;
@@ -161,6 +162,20 @@ deleteStatement returns [DeleteStatement
}
;
+/** CREATE KEYSPACE KEYSPACE WITH attr1 = value1 AND attr2 = value2; */
+createKeyspaceStatement returns [CreateKeyspaceStatement expr]
+: {
+ MapString, String attrs = new HashMapString, String();
+ }
+ K_CREATE K_KEYSPACE keyspace=IDENT
+ K_WITH a1=( COMPIDENT | IDENT ) '=' v1=( STRING_LITERAL | INTEGER )
{ attrs.put($a1.text, $v1.text); }
+ ( K_AND aN=( COMPIDENT | IDENT ) '=' vN=( STRING_LITERAL | INTEGER )
{ attrs.put($aN.text, $vN.text); } )*
+ endStmnt
+ {
+ return new CreateKeyspaceStatement($keyspace.text, attrs);
+ }
+;
+
// TODO: date/time, utf8
term returns [Term item]
: ( t=STRING_LITERAL | t=LONG )
@@ -245,6 +260,8 @@ K_BATCH: B A T C H;
K_TRUNCATE:T R U N C A T E;
K_DELETE: D E L E T E;
K_IN: I N;
+K_CREATE: C R E A T E;
+K_KEYSPACE:K E Y S P A C E;
// Case-insensitive alpha characters
fragment A: ('a'|'A');
@@ -304,6 +321,10 @@ IDENT
: LETTER (LETTER | DIGIT | '_')*
;
+COMPIDENT
+: IDENT ( ':' IDENT)*
+;
+
WS
: (' ' | '\t' | '\n' | '\r')+ { $channel = HIDDEN; }
;
Added:
cassandra/trunk/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java?rev=1064326view=auto
==
---
cassandra/trunk/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
(added)
+++
cassandra/trunk/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
Thu Jan 27 21:57:20 2011
@@ -0,0 +1,82 @@
+package org.apache.cassandra.cql;
+
+import java.util.HashMap;
+import java.util.Map;
+import org.apache.cassandra.thrift.InvalidRequestException;
+
+/** A codeCREATE KEYSPACE/code statement parsed from a CQL query. */
+public class CreateKeyspaceStatement
+{
+private final String name;
+private final MapString, String attrs;
+private String strategyClass;
+private int replicationFactor;
+private MapString, String strategyOptions = new HashMapString,
String();
+
+/**
+ * Creates a new codeCreateKeyspaceStatement/code instance for a given
+ * keyspace name and keyword arguments.
+ *
+ * @param name the name of the keyspace to create
+ * @param attrs map of the raw keyword arguments that followed the
codeWITH/code keyword.
+ */
+public CreateKeyspaceStatement(String name, MapString, String attrs)
+{
+this.name = name;
+this.attrs = attrs;
+}
+
+/**
+ * The codeCqlParser/code only goes as far as extracting the keyword
arguments
+ * from these statements, so this method is responsible for processing and
+ * validating, and must be called prior to access.
+ *
+ * @throws InvalidRequestException if arguments are missing or unacceptable
+ */
+public void validate() throws InvalidRequestException
+{
+// required
+if (!attrs.containsKey(strategy_class))
+throw new InvalidRequestException(missing required argument
\strategy_class\);
+strategyClass = attrs.get(strategy_class);
+
+// required
+if (!attrs.containsKey(replication_factor))
+throw new InvalidRequestException(missing required argument
\replication_factor\);
+
+
svn commit: r1064327 - in /cassandra/trunk/doc/cql: CQL.html CQL.textile
Author: eevans Date: Thu Jan 27 21:57:24 2011 New Revision: 1064327 URL: http://svn.apache.org/viewvc?rev=1064327view=rev Log: update doco for CREATE KEYSPACE Patch by eevans for CASSANDRA-1709 Modified: cassandra/trunk/doc/cql/CQL.html cassandra/trunk/doc/cql/CQL.textile Modified: cassandra/trunk/doc/cql/CQL.html URL: http://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?rev=1064327r1=1064326r2=1064327view=diff == --- cassandra/trunk/doc/cql/CQL.html (original) +++ cassandra/trunk/doc/cql/CQL.html Thu Jan 27 21:57:24 2011 @@ -1,4 +1,4 @@ -?xml version='1.0' encoding='utf-8' ?!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;html xmlns=http://www.w3.org/1999/xhtml;headmeta http-equiv=Content-Type content=text/html; charset=utf-8//headbodyh1 id=CassandraQueryLanguageCQLv0.99.1Cassandra Query Language (CQL) v0.99.1/h1h2 id=TableofContentsTable of Contents/h2ol style=list-style: none;lia href=#CassandraQueryLanguageCQLv0.99.1Cassandra Query Language (CQL) v0.99.1/aol style=list-style: none;lia href=#TableofContentsTable of Contents/a/lilia href=#USEUSE/a/lilia href=#SELECTSELECT/aol style=list-style: none;lia href=#SpecifyingColumnsSpecifying Columns/a/lilia href=#ColumnFamilyColumn Family/a/lilia href=#ConsistencyLevelConsistency Level/a/lilia href=#FilteringrowsFiltering rows/a/lilia href=#LimitsLimits/a/li/ol/li lia href=#UPDATEUPDATE/aol style=list-style: none;lia href=#ColumnFamily2Column Family/a/lilia href=#ConsistencyLevel2Consistency Level/a/lilia href=#SpecifyingColumnsandRowSpecifying Columns and Row/a/li/ol/lilia href=#DELETEDELETE/aol style=list-style: none;lia href=#SpecifyingColumns2Specifying Columns/a/lilia href=#ColumnFamily3Column Family/a/lilia href=#ConsistencyLevel3Consistency Level/a/lilia href=#deleterowsSpecifying Rows/a/li/ol/lilia href=#TRUNCATETRUNCATE/a/lilia href=#CommonIdiomsCommon Idioms/aol style=list-style: none;lia href=#consistencySpecifying Consistency/a/lilia href=#termsTerm specification/aol style=list-style: none;lia href=#StringLiteralsString Literals/a/lilia href=#IntegerslongsIntegers / longs/a/li/ol/li/ol/li/ol/li/olh2 id=USEUSE/h2piSynopsis:/i/ppre codeUSE lt;KEYSPACEgt;; +?xml version='1.0' encoding='utf-8' ?!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;html xmlns=http://www.w3.org/1999/xhtml;headmeta http-equiv=Content-Type content=text/html; charset=utf-8//headbodyh1 id=CassandraQueryLanguageCQLv0.99.1Cassandra Query Language (CQL) v0.99.1/h1h2 id=TableofContentsTable of Contents/h2ol style=list-style: none;lia href=#CassandraQueryLanguageCQLv0.99.1Cassandra Query Language (CQL) v0.99.1/aol style=list-style: none;lia href=#TableofContentsTable of Contents/a/lilia href=#USEUSE/a/lilia href=#SELECTSELECT/aol style=list-style: none;lia href=#SpecifyingColumnsSpecifying Columns/a/lilia href=#ColumnFamilyColumn Family/a/lilia href=#ConsistencyLevelConsistency Level/a/lilia href=#FilteringrowsFiltering rows/a/lilia href=#LimitsLimits/a/li/ol/li lia href=#UPDATEUPDATE/aol style=list-style: none;lia href=#ColumnFamily2Column Family/a/lilia href=#ConsistencyLevel2Consistency Level/a/lilia href=#SpecifyingColumnsandRowSpecifying Columns and Row/a/li/ol/lilia href=#DELETEDELETE/aol style=list-style: none;lia href=#SpecifyingColumns2Specifying Columns/a/lilia href=#ColumnFamily3Column Family/a/lilia href=#ConsistencyLevel3Consistency Level/a/lilia href=#deleterowsSpecifying Rows/a/li/ol/lilia href=#TRUNCATETRUNCATE/a/lilia href=#CREATEKEYSPACECREATE KEYSPACE/a/lilia href=#CommonIdiomsCommon Idioms/aol style=list-style: none;lia href=#consistencySpecifying Consistency/a/lilia href=#termsTerm specification/aol style=list-style: none;lia href=#StringLiteralsString Literals/a/lilia href=#IntegerslongsIntegers / longs/a/li/ol/li/ol/li/ol/li /olh2 id=USEUSE/h2piSynopsis:/i/pprecodeUSE lt;KEYSPACEgt;; /code/prepA codeUSE/code statement consists of the codeUSE/code keyword, followed by a valid keyspace name. Its purpose is to assign the per-connection, current working keyspace. All subsequent keyspace-specific actions will be performed in the context of the supplied value./ph2 id=SELECTSELECT/h2piSynopsis:/i/pprecodeSELECT [FIRST N] [REVERSED] lt;SELECT EXPRgt; FROM lt;COLUMN FAMILYgt; [USING lt;CONSISTENCYgt;] [WHERE lt;CLAUSEgt;] [LIMIT N]; /code/prepA codeSELECT/code is used to read one or more records from a Cassandra column family. It returns a result-set of rows, where each row consists of a key and a collection of columns corresponding to the query./ph3 id=SpecifyingColumnsSpecifying Columns/h3precodeSELECT [FIRST N] [REVERSED] name1, name2, name3 FROM ... @@ -21,10 +21,12 @@ APPLY BATCH /code/prepWhen batching UPDATEs, a single consistency level is used
svn commit: r1064328 - /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
Author: eevans
Date: Thu Jan 27 21:57:30 2011
New Revision: 1064328
URL: http://svn.apache.org/viewvc?rev=1064328view=rev
Log:
log CQL statement type
Patch by eevans for CASSANDRA-1709
Modified:
cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java?rev=1064328r1=1064327r2=1064328view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java Thu
Jan 27 21:57:30 2011
@@ -328,6 +328,8 @@ public class QueryProcessor
CqlResult avroResult = new CqlResult();
+logger.debug(CQL statement type: {}, statement.type.toString());
+
switch (statement.type)
{
case SELECT:
[jira] Updated: (CASSANDRA-1709) CQL keyspace and column family management
[ https://issues.apache.org/jira/browse/CASSANDRA-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-1709: -- Attachment: (was: v2-0002-CQL-keyspace-creation.txt) CQL keyspace and column family management - Key: CASSANDRA-1709 URL: https://issues.apache.org/jira/browse/CASSANDRA-1709 Project: Cassandra Issue Type: Sub-task Components: API Affects Versions: 0.8 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Fix For: 0.8 Original Estimate: 0h Remaining Estimate: 0h CQL specification and implementation for schema management. This corresponds to the following RPC methods: * system_add_column_family() * system_add_keyspace() * system_drop_keyspace() * system_update_keyspace() * system_update_columnfamily() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1709) CQL keyspace and column family management
[ https://issues.apache.org/jira/browse/CASSANDRA-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-1709: -- Attachment: (was: v2-0001-CASSANDRA-1709-allow-underscores-in-IDENT.txt) CQL keyspace and column family management - Key: CASSANDRA-1709 URL: https://issues.apache.org/jira/browse/CASSANDRA-1709 Project: Cassandra Issue Type: Sub-task Components: API Affects Versions: 0.8 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Fix For: 0.8 Original Estimate: 0h Remaining Estimate: 0h CQL specification and implementation for schema management. This corresponds to the following RPC methods: * system_add_column_family() * system_add_keyspace() * system_drop_keyspace() * system_update_keyspace() * system_update_columnfamily() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1709) CQL keyspace and column family management
[ https://issues.apache.org/jira/browse/CASSANDRA-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-1709: -- Attachment: (was: v2-0004-log-CQL-statement-type.txt) CQL keyspace and column family management - Key: CASSANDRA-1709 URL: https://issues.apache.org/jira/browse/CASSANDRA-1709 Project: Cassandra Issue Type: Sub-task Components: API Affects Versions: 0.8 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Fix For: 0.8 Original Estimate: 0h Remaining Estimate: 0h CQL specification and implementation for schema management. This corresponds to the following RPC methods: * system_add_column_family() * system_add_keyspace() * system_drop_keyspace() * system_update_keyspace() * system_update_columnfamily() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1709) CQL keyspace and column family management
[ https://issues.apache.org/jira/browse/CASSANDRA-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-1709: -- Attachment: (was: v2-0003-update-doco-for-CREATE-KEYSPACE.txt) CQL keyspace and column family management - Key: CASSANDRA-1709 URL: https://issues.apache.org/jira/browse/CASSANDRA-1709 Project: Cassandra Issue Type: Sub-task Components: API Affects Versions: 0.8 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Fix For: 0.8 Original Estimate: 0h Remaining Estimate: 0h CQL specification and implementation for schema management. This corresponds to the following RPC methods: * system_add_column_family() * system_add_keyspace() * system_drop_keyspace() * system_update_keyspace() * system_update_columnfamily() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2063) bug with test
[ https://issues.apache.org/jira/browse/CASSANDRA-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987789#action_12987789 ] Jonathan Ellis commented on CASSANDRA-2063: --- i'm kind of surprised that import is the only thing keeping 2.4 from running, but +1 bug with test - Key: CASSANDRA-2063 URL: https://issues.apache.org/jira/browse/CASSANDRA-2063 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Environment: RHL. Python 2.4.3 Reporter: Amit Cahanovich Assignee: Eric Evans Priority: Minor Fix For: 0.7.2 Attachments: v1-0001-CASSANDRA-2063-Python2.4-friendly-imports.txt Original Estimate: 0.17h Remaining Estimate: 0.17h when executing nosetests (e.g: nosetests test/system/test_avro_system.py), you get the following error: mod = load_module(part_fqname, fh, filename, desc) File /tmp/apache-cassandra-0.7.0-src/test/system/test_avro_system.py, line 19 from . import AvroTester ^ SyntaxError: invalid syntax All *.py scripts should be changed to be from __init__ import (AvroTester) instead of from . import AvroTester -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2069) Read repair causes tremendous GC pressure
[ https://issues.apache.org/jira/browse/CASSANDRA-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2069: -- Fix Version/s: 0.7.2 Read repair causes tremendous GC pressure - Key: CASSANDRA-2069 URL: https://issues.apache.org/jira/browse/CASSANDRA-2069 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.1 Reporter: Brandon Williams Fix For: 0.7.2 To reproduce: start a three node cluster, insert 1M rows with stress.java and rf=2. Take one down, delete its data, then bring it back up and issue 1M reads against it. After the run is done you will see at least 1 STW long enough to mark the node as dead, often 4 or 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2069) Read repair causes tremendous GC pressure
[ https://issues.apache.org/jira/browse/CASSANDRA-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987790#action_12987790 ] Jonathan Ellis commented on CASSANDRA-2069: --- is this also true for 0.6? Read repair causes tremendous GC pressure - Key: CASSANDRA-2069 URL: https://issues.apache.org/jira/browse/CASSANDRA-2069 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.1 Reporter: Brandon Williams Fix For: 0.7.2 To reproduce: start a three node cluster, insert 1M rows with stress.java and rf=2. Take one down, delete its data, then bring it back up and issue 1M reads against it. After the run is done you will see at least 1 STW long enough to mark the node as dead, often 4 or 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1709) CQL keyspace and column family management
[ https://issues.apache.org/jira/browse/CASSANDRA-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987797#action_12987797 ] Hudson commented on CASSANDRA-1709: --- Integrated in Cassandra #696 (See [https://hudson.apache.org/hudson/job/Cassandra/696/]) log CQL statement type Patch by eevans for CASSANDRA-1709 update doco for CREATE KEYSPACE Patch by eevans for CASSANDRA-1709 CQL: keyspace creation Patch by eevans for CASSANDRA-1709 CASSANDRA-1709 allow underscores in IDENT Patch by eevans for CASSANDRA-1709 CQL keyspace and column family management - Key: CASSANDRA-1709 URL: https://issues.apache.org/jira/browse/CASSANDRA-1709 Project: Cassandra Issue Type: Sub-task Components: API Affects Versions: 0.8 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Fix For: 0.8 Original Estimate: 0h Remaining Estimate: 0h CQL specification and implementation for schema management. This corresponds to the following RPC methods: * system_add_column_family() * system_add_keyspace() * system_drop_keyspace() * system_update_keyspace() * system_update_columnfamily() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2070) replace ExpiringMap with google collections MapMaker
replace ExpiringMap with google collections MapMaker Key: CASSANDRA-2070 URL: https://issues.apache.org/jira/browse/CASSANDRA-2070 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Trivial Fix For: 0.7.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064342 - in /cassandra/branches/cassandra-0.7/test/system: test_avro_meta.py test_avro_standard.py test_avro_super.py test_avro_system.py test_thrift_server.py
Author: eevans Date: Thu Jan 27 22:42:21 2011 New Revision: 1064342 URL: http://svn.apache.org/viewvc?rev=1064342view=rev Log: CASSANDRA-2063 Python2.4-friendly imports Patch by eevans for CASSANDRA-2063 Modified: cassandra/branches/cassandra-0.7/test/system/test_avro_meta.py cassandra/branches/cassandra-0.7/test/system/test_avro_standard.py cassandra/branches/cassandra-0.7/test/system/test_avro_super.py cassandra/branches/cassandra-0.7/test/system/test_avro_system.py cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py Modified: cassandra/branches/cassandra-0.7/test/system/test_avro_meta.py URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/system/test_avro_meta.py?rev=1064342r1=1064341r2=1064342view=diff == --- cassandra/branches/cassandra-0.7/test/system/test_avro_meta.py (original) +++ cassandra/branches/cassandra-0.7/test/system/test_avro_meta.py Thu Jan 27 22:42:21 2011 @@ -15,7 +15,7 @@ # See the License for the specific language governing permissions and # limitations under the License. -from . import AvroTester +from __init__ import AvroTester import avro_utils from avro.ipc import AvroRemoteException Modified: cassandra/branches/cassandra-0.7/test/system/test_avro_standard.py URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/system/test_avro_standard.py?rev=1064342r1=1064341r2=1064342view=diff == --- cassandra/branches/cassandra-0.7/test/system/test_avro_standard.py (original) +++ cassandra/branches/cassandra-0.7/test/system/test_avro_standard.py Thu Jan 27 22:42:21 2011 @@ -15,7 +15,7 @@ # See the License for the specific language governing permissions and # limitations under the License. -from . import AvroTester +from __init__ import AvroTester import avro_utils from time import time import struct Modified: cassandra/branches/cassandra-0.7/test/system/test_avro_super.py URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/system/test_avro_super.py?rev=1064342r1=1064341r2=1064342view=diff == --- cassandra/branches/cassandra-0.7/test/system/test_avro_super.py (original) +++ cassandra/branches/cassandra-0.7/test/system/test_avro_super.py Thu Jan 27 22:42:21 2011 @@ -15,7 +15,7 @@ # See the License for the specific language governing permissions and # limitations under the License. -from . import AvroTester +from __init__ import AvroTester from avro.ipc import AvroRemoteException import avro_utils import time Modified: cassandra/branches/cassandra-0.7/test/system/test_avro_system.py URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/system/test_avro_system.py?rev=1064342r1=1064341r2=1064342view=diff == --- cassandra/branches/cassandra-0.7/test/system/test_avro_system.py (original) +++ cassandra/branches/cassandra-0.7/test/system/test_avro_system.py Thu Jan 27 22:42:21 2011 @@ -16,7 +16,7 @@ # limitations under the License. import avro_utils -from . import AvroTester +from __init__ import AvroTester from avro.ipc import AvroRemoteException # cheat a little until these are moved into avro_utils. Modified: cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py?rev=1064342r1=1064341r2=1064342view=diff == --- cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py (original) +++ cassandra/branches/cassandra-0.7/test/system/test_thrift_server.py Thu Jan 27 22:42:21 2011 @@ -19,8 +19,8 @@ import os, sys, time, struct -from . import root, ThriftTester -from . import thrift_client as client +from __init__ import root, ThriftTester +from __init__ import thrift_client as client from thrift.Thrift import TApplicationException from ttypes import *
[jira] Commented: (CASSANDRA-2063) bug with test
[ https://issues.apache.org/jira/browse/CASSANDRA-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987806#action_12987806 ] Eric Evans commented on CASSANDRA-2063: --- Yeah, same here. Maybe OP didn't make it past this (I don't have 2.4 handy to test with). Anyway, committed. bug with test - Key: CASSANDRA-2063 URL: https://issues.apache.org/jira/browse/CASSANDRA-2063 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Environment: RHL. Python 2.4.3 Reporter: Amit Cahanovich Assignee: Eric Evans Priority: Minor Fix For: 0.7.2 Attachments: v1-0001-CASSANDRA-2063-Python2.4-friendly-imports.txt Original Estimate: 0.17h Remaining Estimate: 0.17h when executing nosetests (e.g: nosetests test/system/test_avro_system.py), you get the following error: mod = load_module(part_fqname, fh, filename, desc) File /tmp/apache-cassandra-0.7.0-src/test/system/test_avro_system.py, line 19 from . import AvroTester ^ SyntaxError: invalid syntax All *.py scripts should be changed to be from __init__ import (AvroTester) instead of from . import AvroTester -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-2058) Nodes periodically spike in load
[ https://issues.apache.org/jira/browse/CASSANDRA-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2058. --- Resolution: Fixed Reviewer: brandon.williams committed to 0.7 and trunk Nodes periodically spike in load Key: CASSANDRA-2058 URL: https://issues.apache.org/jira/browse/CASSANDRA-2058 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6.10, 0.7.1 Reporter: David King Assignee: Jonathan Ellis Fix For: 0.6.11, 0.7.1 Attachments: 2058-0.7-v2.txt, 2058-0.7-v3.txt, 2058-0.7.txt, 2058.txt, cassandra.pmc01.log.bz2, cassandra.pmc14.log.bz2, graph a.png, graph b.png (Filing as a placeholder bug as I gather information.) At ~10p 24 Jan, I upgraded our 20-node cluster from 0.6.8-0.6.10, turned on the DES, and moved some CFs from one KS into another (drain whole cluster, take it down, move files, change schema, put it back up). Since then, I've had four storms whereby a node's load will shoot to 700+ (400% CPU on a 4-cpu machine) and become totally unresponsive. After a moment or two like that, its neighbour dies too, and the failure cascades around the ring. Unfortunately because of the high load I'm not able to get into the machine to pull a thread dump to see wtf it's doing as it happens. I've also had an issue where a single node spikes up to high load, but recovers. This may or may not be the same issue from which the nodes don't recover as above, but both are new behaviour -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064343 - in /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator: DynamicEndpointSnitch.java DynamicEndpointSnitchMBean.java
Author: brandonwilliams
Date: Thu Jan 27 22:46:15 2011
New Revision: 1064343
URL: http://svn.apache.org/viewvc?rev=1064343view=rev
Log:
Add ability to dump DES timings
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java?rev=1064343r1=1064342r2=1064343view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
Thu Jan 27 22:46:15 2011
@@ -20,6 +20,7 @@ package org.apache.cassandra.locator;
import java.lang.management.ManagementFactory;
import java.net.InetAddress;
+import java.net.UnknownHostException;
import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.LinkedBlockingDeque;
@@ -252,6 +253,20 @@ public class DynamicEndpointSnitch exten
return subsnitch.getClass().getName();
}
+public ListDouble dumpTimings(String hostname) throws
UnknownHostException
+{
+InetAddress host = InetAddress.getByName(hostname);
+ArrayListDouble timings = new ArrayListDouble();
+AdaptiveLatencyTracker window = windows.get(host);
+if (window != null)
+{
+for (double time: window)
+{
+timings.add(time);
+}
+}
+return timings;
+}
}
@@ -307,4 +322,5 @@ class AdaptiveLatencyTracker extends Abs
}
return log;
}
+
}
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java?rev=1064343r1=1064342r2=1064343view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/locator/DynamicEndpointSnitchMBean.java
Thu Jan 27 22:46:15 2011
@@ -20,7 +20,9 @@
package org.apache.cassandra.locator;
import java.net.InetAddress;
+import java.net.UnknownHostException;
import java.util.Map;
+import java.util.List;
public interface DynamicEndpointSnitchMBean {
public MapInetAddress, Double getScores();
@@ -28,4 +30,5 @@ public interface DynamicEndpointSnitchMB
public int getResetInterval();
public double getBadnessThreshold();
public String getSubsnitchClassName();
+public ListDouble dumpTimings(String hostname) throws
UnknownHostException;
}
[jira] Commented: (CASSANDRA-2063) bug with test
[ https://issues.apache.org/jira/browse/CASSANDRA-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987816#action_12987816 ] Hudson commented on CASSANDRA-2063: --- Integrated in Cassandra-0.7 #222 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/222/]) CASSANDRA-2063 Python2.4-friendly imports Patch by eevans for CASSANDRA-2063 bug with test - Key: CASSANDRA-2063 URL: https://issues.apache.org/jira/browse/CASSANDRA-2063 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Environment: RHL. Python 2.4.3 Reporter: Amit Cahanovich Assignee: Eric Evans Priority: Minor Fix For: 0.7.2 Attachments: v1-0001-CASSANDRA-2063-Python2.4-friendly-imports.txt Original Estimate: 0.17h Remaining Estimate: 0.17h when executing nosetests (e.g: nosetests test/system/test_avro_system.py), you get the following error: mod = load_module(part_fqname, fh, filename, desc) File /tmp/apache-cassandra-0.7.0-src/test/system/test_avro_system.py, line 19 from . import AvroTester ^ SyntaxError: invalid syntax All *.py scripts should be changed to be from __init__ import (AvroTester) instead of from . import AvroTester -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2071) RP.describeOwnership() does some bad math
RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2071) RP.describeOwnership() does some bad math
[ https://issues.apache.org/jira/browse/CASSANDRA-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2071: -- Attachment: 2071.txt Fixes the math by using a closed form in all cases. Now returns: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 0.2384833 RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Attachments: 2071.txt If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2071) RP.describeOwnership() does some bad math
[ https://issues.apache.org/jira/browse/CASSANDRA-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2071: -- Attachment: (was: 2071.txt) RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Attachments: 2071.txt If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2071) RP.describeOwnership() does some bad math
[ https://issues.apache.org/jira/browse/CASSANDRA-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Hermes updated CASSANDRA-2071: -- Attachment: 2071.txt Whoops, wrong file. RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Attachments: 2071.txt If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1551) create tell me what nodes you have hints for jmx api
[ https://issues.apache.org/jira/browse/CASSANDRA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987832#action_12987832 ] Brandon Williams commented on CASSANDRA-1551: - deleteHintsForEndpoint doesn't seem to actually delete hints now. create tell me what nodes you have hints for jmx api -- Key: CASSANDRA-1551 URL: https://issues.apache.org/jira/browse/CASSANDRA-1551 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Jon Hermes Priority: Minor Fix For: 0.7.2 Attachments: 1551-v2.txt, 1551-v3.txt, 1551.txt Original Estimate: 4h Remaining Estimate: 4h we can do this efficiently in 0.7 due to new HH schema. in 0.6 this would require scanning all hints so probably not worth it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064360 - /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
Author: brandonwilliams
Date: Thu Jan 27 23:36:26 2011
New Revision: 1064360
URL: http://svn.apache.org/viewvc?rev=1064360view=rev
Log:
Fix RP.describeOwnership()
Patch by Jon Hermes, reviewed by brandonwilliams for CASSANDRA-2071
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java?rev=1064360r1=1064359r2=1064360view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/dht/RandomPartitioner.java
Thu Jan 27 23:36:26 2011
@@ -148,15 +148,14 @@ public class RandomPartitioner implement
Token start = (Token)i.next(); BigInteger ti =
((BigIntegerToken)start).token; // The first token and its value
Token t; BigInteger tim1 = ti;
// The last token and its value (after loop)
while (i.hasNext()) {
-t = (Token)i.next(); ti = ((BigIntegerToken)t).token;
// The next token and its value
-float x = new
BigDecimal(ti.subtract(tim1)).divide(r).floatValue(); // %age = T(i) -
T(i-1) / R
-ownerships.put(t, x);
// save (T(i) - %age)
-tim1 = ti;
// - advance loop
+t = (Token)i.next(); ti = ((BigIntegerToken)t).token;
// The next token and its value
+float x = new
BigDecimal(ti.subtract(tim1).add(ri).mod(ri)).divide(r).floatValue(); // %age =
((T(i) - T(i-1) + R) % R) / R
+ownerships.put(t, x);
// save (T(i) - %age)
+tim1 = ti;
// - advance loop
}
-// The start token's range extends backward to the last token,
which is why both were saved
-// above. The simple calculation for this is: T(start) - T(end) +
r % r / r.
-// (In the 1-case, this produces 0% instead of 100%.)
-ownerships.put(start, new
BigDecimal(((BigIntegerToken)start).token.subtract(ti).add(ri).mod(ri)).divide(r).floatValue());
+// The start token's range extends backward to the last token,
which is why both were saved above.
+float x = new
BigDecimal(((BigIntegerToken)start).token.subtract(ti).add(ri).mod(ri)).divide(r).floatValue();
+ownerships.put(start, x);
}
return ownerships;
}
svn commit: r1064361 - /cassandra/branches/cassandra-0.7/CHANGES.txt
Author: jbellis Date: Thu Jan 27 23:37:30 2011 New Revision: 1064361 URL: http://svn.apache.org/viewvc?rev=1064361view=rev Log: update CHANGES Modified: cassandra/branches/cassandra-0.7/CHANGES.txt Modified: cassandra/branches/cassandra-0.7/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1064361r1=1064360r2=1064361view=diff == --- cassandra/branches/cassandra-0.7/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Jan 27 23:37:30 2011 @@ -6,6 +6,7 @@ * fix possible ByteBuffer race conditions (CASSANDRA-2066) * reduce garbage generated by MessagingService to prevent load spikes (CASSANDRA-2058) + * fix math in RandomPartitioner.describeOwnership (CASSANDRA-2071) 0.7.1
[jira] Commented: (CASSANDRA-2058) Nodes periodically spike in load
[ https://issues.apache.org/jira/browse/CASSANDRA-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987835#action_12987835 ] Mike Malone commented on CASSANDRA-2058: Jake/Jonathan, FWIW, I re-implemented ExpiringMap with MapMaker using an eviction listener (but mostly maintaining the ExpiringMap API) a little while back while investigating some messaging service issues we were seeing. The patch is against 0.6.8, but here's the code if you wanna try it out: https://gist.github.com/a2f645c69ca8f44ccff3 It could definitely be simplified more by someone willing to make more widespread code changes. Actually, I think using MapMaker directly and getting rid of ExpiringMap would probably be best. *shrug* Nodes periodically spike in load Key: CASSANDRA-2058 URL: https://issues.apache.org/jira/browse/CASSANDRA-2058 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6.10, 0.7.1 Reporter: David King Assignee: Jonathan Ellis Fix For: 0.6.11, 0.7.1 Attachments: 2058-0.7-v2.txt, 2058-0.7-v3.txt, 2058-0.7.txt, 2058.txt, cassandra.pmc01.log.bz2, cassandra.pmc14.log.bz2, graph a.png, graph b.png (Filing as a placeholder bug as I gather information.) At ~10p 24 Jan, I upgraded our 20-node cluster from 0.6.8-0.6.10, turned on the DES, and moved some CFs from one KS into another (drain whole cluster, take it down, move files, change schema, put it back up). Since then, I've had four storms whereby a node's load will shoot to 700+ (400% CPU on a 4-cpu machine) and become totally unresponsive. After a moment or two like that, its neighbour dies too, and the failure cascades around the ring. Unfortunately because of the high load I'm not able to get into the machine to pull a thread dump to see wtf it's doing as it happens. I've also had an issue where a single node spikes up to high load, but recovers. This may or may not be the same issue from which the nodes don't recover as above, but both are new behaviour -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2071) RP.describeOwnership() does some bad math
[ https://issues.apache.org/jira/browse/CASSANDRA-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987836#action_12987836 ] Hudson commented on CASSANDRA-2071: --- Integrated in Cassandra-0.7 #223 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/223/]) Fix RP.describeOwnership() Patch by Jon Hermes, reviewed by brandonwilliams for CASSANDRA-2071 RP.describeOwnership() does some bad math - Key: CASSANDRA-2071 URL: https://issues.apache.org/jira/browse/CASSANDRA-2071 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.7.1 Attachments: 2071.txt If the input isn't sorted correctly for some reason, then describeOwnership() fails to calculate the ownership %ages correctly. Repro is 2 nodes with these tokens, you get these fractions: 49000620740128447720217646403197156812 : 0.7615167 770141183460469231731687303715884105727 : 4.2384834 423% ownership is obviously broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2058) Nodes periodically spike in load
[ https://issues.apache.org/jira/browse/CASSANDRA-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987838#action_12987838 ] Jonathan Ellis commented on CASSANDRA-2058: --- bq. I think using MapMaker directly and getting rid of ExpiringMap would probably be best Agreed, opened CASSANDRA-2070 for that Nodes periodically spike in load Key: CASSANDRA-2058 URL: https://issues.apache.org/jira/browse/CASSANDRA-2058 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6.10, 0.7.1 Reporter: David King Assignee: Jonathan Ellis Fix For: 0.6.11, 0.7.1 Attachments: 2058-0.7-v2.txt, 2058-0.7-v3.txt, 2058-0.7.txt, 2058.txt, cassandra.pmc01.log.bz2, cassandra.pmc14.log.bz2, graph a.png, graph b.png (Filing as a placeholder bug as I gather information.) At ~10p 24 Jan, I upgraded our 20-node cluster from 0.6.8-0.6.10, turned on the DES, and moved some CFs from one KS into another (drain whole cluster, take it down, move files, change schema, put it back up). Since then, I've had four storms whereby a node's load will shoot to 700+ (400% CPU on a 4-cpu machine) and become totally unresponsive. After a moment or two like that, its neighbour dies too, and the failure cascades around the ring. Unfortunately because of the high load I'm not able to get into the machine to pull a thread dump to see wtf it's doing as it happens. I've also had an issue where a single node spikes up to high load, but recovers. This may or may not be the same issue from which the nodes don't recover as above, but both are new behaviour -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2070) replace ExpiringMap with google collections MapMaker
[ https://issues.apache.org/jira/browse/CASSANDRA-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987840#action_12987840 ] Jonathan Ellis commented on CASSANDRA-2070: --- Mike Malone linked a patch he wrote against 0.6.8 over in CASSANDRA-2058 replace ExpiringMap with google collections MapMaker Key: CASSANDRA-2070 URL: https://issues.apache.org/jira/browse/CASSANDRA-2070 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Trivial Fix For: 0.7.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2072) Race condition during decommission
Race condition during decommission -- Key: CASSANDRA-2072 URL: https://issues.apache.org/jira/browse/CASSANDRA-2072 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Brandon Williams Priority: Minor Occasionally when decommissioning a node, there is a race condition that occurs where another node will never remove the token and thus propagate it again with a state of down. With CASSANDRA-1900 we can solve this, but it shouldn't occur in the first place. Given nodes A, B, and C, if you decommission B it will stream to A and C. When complete, B will decommission and receive this stacktrace: ERROR 00:02:40,282 Fatal exception in thread Thread[Thread-5,5,main] java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut down at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:62) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at org.apache.cassandra.net.MessagingService.receive(MessagingService.java:387) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:91 At this point A will show it is removing B's token, but C will not and instead it's failure detector will report that B is dead, and nodetool ring on C shows A in a leaving/down state. In another gossip round, C will propagate this state back to A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2072) Race condition during decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2072: Description: Occasionally when decommissioning a node, there is a race condition that occurs where another node will never remove the token and thus propagate it again with a state of down. With CASSANDRA-1900 we can solve this, but it shouldn't occur in the first place. Given nodes A, B, and C, if you decommission B it will stream to A and C. When complete, B will decommission and receive this stacktrace: ERROR 00:02:40,282 Fatal exception in thread Thread[Thread-5,5,main] java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut down at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:62) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at org.apache.cassandra.net.MessagingService.receive(MessagingService.java:387) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:91 At this point A will show it is removing B's token, but C will not and instead its failure detector will report that B is dead, and nodetool ring on C shows B in a leaving/down state. In another gossip round, C will propagate this state back to A. was: Occasionally when decommissioning a node, there is a race condition that occurs where another node will never remove the token and thus propagate it again with a state of down. With CASSANDRA-1900 we can solve this, but it shouldn't occur in the first place. Given nodes A, B, and C, if you decommission B it will stream to A and C. When complete, B will decommission and receive this stacktrace: ERROR 00:02:40,282 Fatal exception in thread Thread[Thread-5,5,main] java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut down at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:62) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at org.apache.cassandra.net.MessagingService.receive(MessagingService.java:387) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:91 At this point A will show it is removing B's token, but C will not and instead it's failure detector will report that B is dead, and nodetool ring on C shows A in a leaving/down state. In another gossip round, C will propagate this state back to A. Race condition during decommission -- Key: CASSANDRA-2072 URL: https://issues.apache.org/jira/browse/CASSANDRA-2072 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Brandon Williams Priority: Minor Occasionally when decommissioning a node, there is a race condition that occurs where another node will never remove the token and thus propagate it again with a state of down. With CASSANDRA-1900 we can solve this, but it shouldn't occur in the first place. Given nodes A, B, and C, if you decommission B it will stream to A and C. When complete, B will decommission and receive this stacktrace: ERROR 00:02:40,282 Fatal exception in thread Thread[Thread-5,5,main] java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut down at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:62) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at org.apache.cassandra.net.MessagingService.receive(MessagingService.java:387) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:91 At this point A will show it is removing B's token, but C will not and instead its failure detector will report that B is dead, and nodetool ring on C shows B in a leaving/down state. In another gossip round, C will propagate this state back to A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-2072) Race condition during decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-2072: --- Assignee: Brandon Williams Race condition during decommission -- Key: CASSANDRA-2072 URL: https://issues.apache.org/jira/browse/CASSANDRA-2072 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Occasionally when decommissioning a node, there is a race condition that occurs where another node will never remove the token and thus propagate it again with a state of down. With CASSANDRA-1900 we can solve this, but it shouldn't occur in the first place. Given nodes A, B, and C, if you decommission B it will stream to A and C. When complete, B will decommission and receive this stacktrace: ERROR 00:02:40,282 Fatal exception in thread Thread[Thread-5,5,main] java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut down at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:62) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at org.apache.cassandra.net.MessagingService.receive(MessagingService.java:387) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:91 At this point A will show it is removing B's token, but C will not and instead its failure detector will report that B is dead, and nodetool ring on C shows B in a leaving/down state. In another gossip round, C will propagate this state back to A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1064371 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/io/sstable/SSTableDeletingReference.java
Author: jbellis Date: Fri Jan 28 00:09:44 2011 New Revision: 1064371 URL: http://svn.apache.org/viewvc?rev=1064371view=rev Log: fix deletionof sstable non-data components patch by jbellis; reviewed by stuhood for CASSANDRA-2059 Modified: cassandra/branches/cassandra-0.7/CHANGES.txt cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableDeletingReference.java Modified: cassandra/branches/cassandra-0.7/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1064371r1=1064370r2=1064371view=diff == --- cassandra/branches/cassandra-0.7/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.7/CHANGES.txt Fri Jan 28 00:09:44 2011 @@ -7,6 +7,7 @@ * reduce garbage generated by MessagingService to prevent load spikes (CASSANDRA-2058) * fix math in RandomPartitioner.describeOwnership (CASSANDRA-2071) + * fix deletion of sstable non-data components (CASSANDRA-2059) 0.7.1 Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableDeletingReference.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableDeletingReference.java?rev=1064371r1=1064370r2=1064371view=diff == --- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableDeletingReference.java (original) +++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableDeletingReference.java Fri Jan 28 00:09:44 2011 @@ -23,9 +23,11 @@ import java.io.File; import java.io.IOException; import java.lang.ref.PhantomReference; import java.lang.ref.ReferenceQueue; +import java.util.Collections; import java.util.Set; import java.util.concurrent.TimeUnit; +import com.google.common.collect.Sets; import org.slf4j.Logger; import org.slf4j.LoggerFactory; @@ -91,8 +93,7 @@ public class SSTableDeletingReference ex } } // let the remainder be cleaned up by delete -components.remove(Component.DATA); -SSTable.delete(desc, components); +SSTable.delete(desc, Sets.difference(components, Collections.singleton(Component.DATA))); tracker.spaceReclaimed(size); } }
[jira] Commented: (CASSANDRA-2059) SSTableDeletingReference only deletes data files
[ https://issues.apache.org/jira/browse/CASSANDRA-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987859#action_12987859 ] Hudson commented on CASSANDRA-2059: --- Integrated in Cassandra-0.7 #224 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/224/]) fix deletionof sstable non-data components patch by jbellis; reviewed by stuhood for CASSANDRA-2059 SSTableDeletingReference only deletes data files Key: CASSANDRA-2059 URL: https://issues.apache.org/jira/browse/CASSANDRA-2059 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.7.2 Attachments: 2059.txt Ching-Cheng Chen reports on the mailing list: In SSTableDeletingReference, it try this operation components.remove(Component.DATA); before STable.delete(desc, components); However, the components was reference to the components object which was created inside SSTable by this.components = Collections.unmodifiableSet(dataComponents); As you can see, you can't try the remove operation on that components object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2062) Use more efficient merge algorithm
[
https://issues.apache.org/jira/browse/CASSANDRA-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-2062:
Attachment: 0006-Port-RowIterator.txt
Missed a usage in RowIterator.
Use more efficient merge algorithm
--
Key: CASSANDRA-2062
URL: https://issues.apache.org/jira/browse/CASSANDRA-2062
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.2
Attachments: 0001-Improved-iterator-for-merging-sorted-iterators.txt,
0002-Quickie-instrumentation-for-comparisons.txt,
0003-Replace-Collating-with-Merge-in-CompactionIterator.txt,
0004-Port-LazilyCompactedRow-ReducingKeyIterator-RangeSlice.txt,
0005-Remove-temporary-instrumentation-and-CollatingIterator.txt,
0006-Port-RowIterator.txt
For {{M}} iterators containing {{N}} total items,
commons.collections.CollatingIterator performs a {{O(M*N)}} merge, and calls
hasNext multiple times per returned value. We can do better.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
