[jira] [Commented] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[ https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592054#comment-13592054 ] Jonathan Ellis commented on CASSANDRA-5051: --- WFM. > Allow automatic cleanup after gc_grace > -- > > Key: CASSANDRA-5051 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5051 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Labels: vnodes > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-5051.patch, 5051-v2.txt > > > When using vnodes, after adding a new node you have to run cleanup on all the > machines, because you don't know which are affected and chances are it was > most if not all of them. As an alternative to this intensive process, we > could allow cleanup during compaction if the data is older than gc_grace (or > perhaps some other time period since people tend to use gc_grace hacks to get > rid of tombstones.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "Jesus2464" by Jesus2464
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Jesus2464" page has been changed by Jesus2464: http://wiki.apache.org/cassandra/Jesus2464 New page: Wassp People !! I am HILARY CASEY. I am staying at Kissimmee.<> I have a job as Military. I like Jet Engines. My daddy name is Cllifford and he is a Flautist. My mom is a Blacksmith.<> <> My webpage: [[http://www.dressesd.com|bridesmaids dresses]]
[Cassandra Wiki] Trivial Update of "FrontPage" by MichaelaV
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "FrontPage" page has been changed by MichaelaV: http://wiki.apache.org/cassandra/FrontPage?action=diff&rev1=85&rev2=86 + Yo guys !! The name is ALLISON ACEVEDO. I go to night school at The Bumpy Academy of Sturdy People situated in Madison.<> + I am self employed as a Presenter. I also like to Nature Walking. My dad name is Dan and he is a Occupational Therapist. My mummy is a Chaplain.<> + <> + Feel free to surf to my webpage [[http://cheap-beatsbydre.blinkweb.com|dr dre earphones]] - ## Please edit system and help pages ONLY in the moinmaster wiki! For more - ## information, please see MoinMaster:MoinPagesEditorGroup. - ##master-page:FrontPage - #format wiki - #language en - #pragma section-numbers off - = Cassandra Wiki = - Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store. Cassandra brings together the distributed systems technologies from [[http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf|Dynamo]] and the data model from Google's [[http://research.google.com/archive/bigtable-osdi06.pdf|BigTable]]. Like Dynamo, Cassandra is [[http://www.allthingsdistributed.com/2008/12/eventually_consistent.html|eventually consistent]]. Like !BigTable, Cassandra provides a !ColumnFamily-based data model richer than typical key/value systems. - Cassandra was open sourced by Facebook in 2008, where it was designed by Avinash Lakshman (one of the authors of Amazon's Dynamo) and Prashant Malik ( Facebook Engineer ). In a lot of ways you can think of Cassandra as Dynamo 2.0 or a marriage of Dynamo and !BigTable. Cassandra is in production use at Facebook but is still under heavy development. - - == General Information == - * [[http://cassandra.apache.org/|Official Cassandra Website]] (download, bug-tracking, mailing-lists, etc) - * [[ArticlesAndPresentations|Articles and Presentations]] about Cassandra. - * [[DataModel|A description of the Cassandra data model]] - * [[CassandraLimitations|Cassandra Limitations]]: where Cassandra is not a good fit - - == Application developer and operator documentation == - * [[GettingStarted|Getting Started]] - * [[http://www.datastax.com/docs|Datastax's Cassandra documentation]] - * [[ClientOptions|Client options: ways to access Cassandra]] -- interfaces for Ruby, Python, Scala and more - * [[IntegrationPoints]] -- list of ways Cassandra is integrated with other projects/products - * [[Administration Tools]] -- list of administrative tools to configure / admin your Cassandra instance - * [[RunningCassandra|Running Cassandra]] - * [[ArchitectureOverview|Architecture Overview]] - * [[UseCases|Simple Use Cases and Solutions]] -- please help complete - * [[FAQ]] - * [[Counters]] - * [[SecondaryIndexes]] - * [[NodeTool]] - - == Advanced Setup and Tuning == - * [[StorageConfiguration|Configuration]] - * [[MultinodeCluster|Creating a multi-node cluster]] - * [[Operations]] - * [[Embedding]] - * [[MemtableThresholds|Memtable Thresholds]] and other [[PerformanceTuning|Performance Tuning]] - * [[CassandraHardware|Cassandra Hardware]] - * [[CloudConfig|Configuration on Rackspace or Amazon Web Services]] - * [[LargeDataSetConsiderations|Large data set considerations]] - - == Client library developer information == - * [[API|Thrift API Documentation]] (In progress) - - == Cassandra developer Documentation == - * [[HowToBuild|How To Build]] - * [[HowToDebug|How to Debug in Eclipse]] - * ArchitectureInternals - * [[CLI Design]] - * [[HowToContribute|How To Contribute?]] - * [[HowToCommit|How To Commit?]] - * [[HowToPublishReleases|How To Release]] (Note: currently a work in progress) (Note: only relevant to Cassandra Committers) - - == Mailing lists == - * Users: u...@cassandra.apache.org [[mailto:user-subscr...@cassandra.apache.org|(subscribe)]] [[http://www.mail-archive.com/user@cassandra.apache.org/|(archives)]] [[http://www.mail-archive.com/cassandra-user@incubator.apache.org/|(incubator archives)]] - * Developers: d...@cassandra.apache.org [[mailto:dev-subscr...@cassandra.apache.org|(subscribe)]] [[http://www.mail-archive.com/dev@cassandra.apache.org/|(archives)]] [[http://www.mail-archive.com/cassandra-dev@incubator.apache.org/|(incubator archives)]] - * Commits: commits@cassandra.apache.org [[mailto:commits-subscr...@cassandra.apache.org|(subscribe)]] - - == Related Information == - * [[http://incubator.apache.org/thrift|Thrift]], used by Cassandra for client access - * RelatedProjects: Projects using or extending Cassandra - - == Thanks == - * YourKit is kindly supporting open source projects with its full-featured Java Profiler. YourKit, LLC is the creator of innovative and intelligent tools for profiling Java and .NET applications. Take a look at YourKit's leading software products: [[http://www.yourkit.com/java/profile
[jira] [Updated] (CASSANDRA-5302) Fix nodetool ring and status output format for IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5302:
--
Reviewer: brandon.williams
> Fix nodetool ring and status output format for IPv6 addresses
> -
>
> Key: CASSANDRA-5302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5302
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Michał Michalski
>Assignee: Michał Michalski
>Priority: Trivial
> Attachments: 5302.patch
>
>
> My pedantic nature can't stand having unaligned columns in nodetool outputs,
> which happens when IP addresses are IPv6 ones:
> {noformat}michal@aperture$ nodetool -h myhost status
> Datacenter: DC1
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Owns (effective) Host ID
>TokenRack
> UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
> d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
> rack2
> UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
> 0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
> rack1
> {noformat}
> I'm attaching a patch that fixes this problem for nodetool status / ring
> commands. It does it by picking first item in nodes list (for nodetool ring
> it's first node in general, for nodetool status it's first node in each DC)
> and uses its length as a field length for output.
> It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC
> and the lenghts of addresses are equal. Let me know if there's the case when
> it's not valid.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5271) Create tool to drop sstables to level 0
[ https://issues.apache.org/jira/browse/CASSANDRA-5271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5271: -- Reviewer: yukim > Create tool to drop sstables to level 0 > --- > > Key: CASSANDRA-5271 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5271 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Trivial > Labels: tools > Fix For: 2.0 > > Attachments: 0001-Add-tool-to-drop-sstables-back-to-level-0.patch, > 0001-Add-tool-to-drop-sstables-back-to-level-0-v2.patch, > 0001-Add-tool-to-drop-sstables-back-to-level-0-v3.patch > > > after CASSANDRA-4872 we need a way to reset all sstables to level 0, > previously we did this by removing the .json file from the data-directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5307) Update Message IDs to be ints instead of strings
Jonathan Ellis created CASSANDRA-5307: - Summary: Update Message IDs to be ints instead of strings Key: CASSANDRA-5307 URL: https://issues.apache.org/jira/browse/CASSANDRA-5307 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: rename constants to uppercase
Updated Branches: refs/heads/trunk 4f0c4b7a2 -> 1a473094c rename constants to uppercase Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1a473094 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1a473094 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1a473094 Branch: refs/heads/trunk Commit: 1a473094c170e24a8c763fb811e5e8c2bc8ed268 Parents: 4f0c4b7 Author: Jonathan Ellis Authored: Sat Mar 2 13:31:21 2013 -0600 Committer: Jonathan Ellis Committed: Mon Mar 4 11:40:52 2013 +0100 -- .../org/apache/cassandra/cql/QueryProcessor.java |2 +- .../org/apache/cassandra/cql/StatementType.java|8 +--- 2 files changed, 6 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a473094/src/java/org/apache/cassandra/cql/QueryProcessor.java -- diff --git a/src/java/org/apache/cassandra/cql/QueryProcessor.java b/src/java/org/apache/cassandra/cql/QueryProcessor.java index 8233429..e2fba6f 100644 --- a/src/java/org/apache/cassandra/cql/QueryProcessor.java +++ b/src/java/org/apache/cassandra/cql/QueryProcessor.java @@ -366,7 +366,7 @@ public class QueryProcessor String keyspace = null; // Some statements won't have (or don't need) a keyspace (think USE, or CREATE). -if (statement.type != StatementType.SELECT && StatementType.requiresKeyspace.contains(statement.type)) +if (statement.type != StatementType.SELECT && StatementType.REQUIRES_KEYSPACE.contains(statement.type)) keyspace = clientState.getKeyspace(); CqlResult result = new CqlResult(); http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a473094/src/java/org/apache/cassandra/cql/StatementType.java -- diff --git a/src/java/org/apache/cassandra/cql/StatementType.java b/src/java/org/apache/cassandra/cql/StatementType.java index 6f5afbe..94db6a3 100644 --- a/src/java/org/apache/cassandra/cql/StatementType.java +++ b/src/java/org/apache/cassandra/cql/StatementType.java @@ -24,7 +24,9 @@ public enum StatementType SELECT, INSERT, UPDATE, BATCH, USE, TRUNCATE, DELETE, CREATE_KEYSPACE, CREATE_COLUMNFAMILY, CREATE_INDEX, DROP_INDEX, DROP_KEYSPACE, DROP_COLUMNFAMILY, ALTER_TABLE; -// Statement types that don't require a keyspace to be set. -private static final EnumSet topLevel = EnumSet.of(USE, CREATE_KEYSPACE, DROP_KEYSPACE); -public static final EnumSet requiresKeyspace = EnumSet.complementOf(topLevel); +/** Statement types that don't require a keyspace to be set */ +private static final EnumSet TOP_LEVEL = EnumSet.of(USE, CREATE_KEYSPACE, DROP_KEYSPACE); + +/** Statement types that require a keyspace to be set */ +public static final EnumSet REQUIRES_KEYSPACE = EnumSet.complementOf(TOP_LEVEL); }
[jira] [Updated] (CASSANDRA-5307) Update Message IDs to be ints instead of strings
[ https://issues.apache.org/jira/browse/CASSANDRA-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5307: -- Attachment: 5307.txt Straightforward change, except that streaming replies used to use OTC.write, but we can't turn the UUID sessions into an int. Turns out that wasn't used anyway though, so refactored into FST.sendReply, which has better symmetry with FST.receiveReply. > Update Message IDs to be ints instead of strings > > > Key: CASSANDRA-5307 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5307 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 2.0 > > Attachments: 5307.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "JulianeMc" by JulianeMc
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "JulianeMc" page has been changed by JulianeMc: http://wiki.apache.org/cassandra/JulianeMc New page: Yo bros !! My name is LASHANDRA VILLARREAL. I study at The Gentle Boarding School located in San Jose.<> I am self employed as a Webmaster. My hobby is Meditation. My daddy name is Brett and he is a Correspondent. My mummy is a Internist.<> <> My blog :: [[http://www.reachbeatsbydre.com|beats monster]]
[2/3] git commit: replace ipv6 colons in jmx object names patch by Michał Michalski; reviewed by jbellis for CASSANDRA-5298
replace ipv6 colons in jmx object names
patch by MichaÅ Michalski; reviewed by jbellis for CASSANDRA-5298
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3a3f1d94
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3a3f1d94
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3a3f1d94
Branch: refs/heads/trunk
Commit: 3a3f1d947462c7c5bdefd661f9e5c9738eab5c31
Parents: 8261aa0
Author: Jonathan Ellis
Authored: Mon Mar 4 11:45:16 2013 +0100
Committer: Jonathan Ellis
Committed: Mon Mar 4 11:45:16 2013 +0100
--
CHANGES.txt|1 +
.../cassandra/metrics/ConnectionMetrics.java |4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3a3f1d94/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fd6547f..a6b2cff 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.2.3
+ * replace ipv6 colons in jmx object names (CASSANDRA-5298)
* Avoid allocating SSTableBoundedScanner during repair when the range does
not intersect the sstable (CASSANDRA-5249)
* Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3a3f1d94/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
--
diff --git a/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
b/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
index 1a93022..5493505 100644
--- a/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
@@ -63,7 +63,9 @@ public class ConnectionMetrics
*/
public ConnectionMetrics(InetAddress ip, final OutboundTcpConnectionPool
connectionPool)
{
-address = ip.getHostAddress();
+// ipv6 addresses will contain colons, which are invalid in a JMX
ObjectName
+address = ip.getHostAddress().replaceAll(":", ".");
+
commandPendingTasks = Metrics.newGauge(new MetricName(GROUP_NAME,
TYPE_NAME, "CommandPendingTasks", address), new Gauge()
{
public Integer value()
[1/3] git commit: replace ipv6 colons in jmx object names patch by Michał Michalski; reviewed by jbellis for CASSANDRA-5298
replace ipv6 colons in jmx object names
patch by MichaÅ Michalski; reviewed by jbellis for CASSANDRA-5298
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3a3f1d94
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3a3f1d94
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3a3f1d94
Branch: refs/heads/cassandra-1.2
Commit: 3a3f1d947462c7c5bdefd661f9e5c9738eab5c31
Parents: 8261aa0
Author: Jonathan Ellis
Authored: Mon Mar 4 11:45:16 2013 +0100
Committer: Jonathan Ellis
Committed: Mon Mar 4 11:45:16 2013 +0100
--
CHANGES.txt|1 +
.../cassandra/metrics/ConnectionMetrics.java |4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3a3f1d94/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fd6547f..a6b2cff 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.2.3
+ * replace ipv6 colons in jmx object names (CASSANDRA-5298)
* Avoid allocating SSTableBoundedScanner during repair when the range does
not intersect the sstable (CASSANDRA-5249)
* Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3a3f1d94/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
--
diff --git a/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
b/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
index 1a93022..5493505 100644
--- a/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/ConnectionMetrics.java
@@ -63,7 +63,9 @@ public class ConnectionMetrics
*/
public ConnectionMetrics(InetAddress ip, final OutboundTcpConnectionPool
connectionPool)
{
-address = ip.getHostAddress();
+// ipv6 addresses will contain colons, which are invalid in a JMX
ObjectName
+address = ip.getHostAddress().replaceAll(":", ".");
+
commandPendingTasks = Metrics.newGauge(new MetricName(GROUP_NAME,
TYPE_NAME, "CommandPendingTasks", address), new Gauge()
{
public Integer value()
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/cassandra-1.2 8261aa083 -> 3a3f1d947 refs/heads/trunk 1a473094c -> 25a31be4f Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/25a31be4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/25a31be4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/25a31be4 Branch: refs/heads/trunk Commit: 25a31be4fe076ba36bd6a44cc3b3d2ba8134c7a9 Parents: 1a47309 3a3f1d9 Author: Jonathan Ellis Authored: Mon Mar 4 11:45:23 2013 +0100 Committer: Jonathan Ellis Committed: Mon Mar 4 11:45:23 2013 +0100 -- CHANGES.txt|1 + .../cassandra/metrics/ConnectionMetrics.java |4 +++- 2 files changed, 4 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/25a31be4/CHANGES.txt -- diff --cc CHANGES.txt index 120f8a4,a6b2cff..9d7ed1d --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,18 -1,5 +1,19 @@@ +1.3 + * Move sstable level information into the Stats component, removing the + need for a separate Manifest file (CASSANDRA-4872) + * avoid serializing to byte[] on commitlog append (CASSANDRA-5199) + * make index_interval configurable per columnfamily (CASSANDRA-3961) + * add default_tim_to_live (CASSANDRA-3974) + * add memtable_flush_period_in_ms (CASSANDRA-4237) + * replace supercolumns internally by composites (CASSANDRA-3237, 5123) + * upgrade thrift to 0.9.0 (CASSANDRA-3719) + * drop unnecessary keyspace from user-defined compaction API (CASSANDRA-5139) + * more robust solution to incomplete compactions + counters (CASSANDRA-5151) + * Change order of directory searching for c*.in.sh (CASSANDRA-3983) + + 1.2.3 + * replace ipv6 colons in jmx object names (CASSANDRA-5298) * Avoid allocating SSTableBoundedScanner during repair when the range does not intersect the sstable (CASSANDRA-5249) * Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292)
[jira] [Updated] (CASSANDRA-5298) MalformedObjectNameException in ConnectionMetrics for IPv6 nodes because of ":" characters
[
https://issues.apache.org/jira/browse/CASSANDRA-5298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5298:
--
Reviewer: jbellis
Priority: Minor (was: Major)
Affects Version/s: (was: 1.2.1)
1.2.0
Fix Version/s: 1.2.3
> MalformedObjectNameException in ConnectionMetrics for IPv6 nodes because of
> ":" characters
> --
>
> Key: CASSANDRA-5298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5298
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Michał Michalski
>Assignee: Michał Michalski
>Priority: Minor
> Fix For: 1.2.3
>
> Attachments: ipv6-connection-metrics-replaceAll.patch,
> ipv6-connection-metrics-URLEncoder.patch
>
>
> After upgrading node to 1.2.1, during C* startup, for all ConnectionMetrics I
> get exception like this one:
> {noformat} WARN [GossipStage:1] 2013-02-27 12:14:55,431 JmxReporter.java
> (line 388) Error processing
> org.apache.cassandra.metrics:type=Connection,scope=2001:4c28:20:177:0:1:2:4,name=Timeouts
> javax.management.MalformedObjectNameException: Invalid character ':' in value
> part of property
> at javax.management.ObjectName.construct(ObjectName.java:602)
> at javax.management.ObjectName.(ObjectName.java:1403)
> at
> com.yammer.metrics.reporting.JmxReporter.onMetricAdded(JmxReporter.java:386)
> at
> com.yammer.metrics.core.MetricsRegistry.notifyMetricAdded(MetricsRegistry.java:516)
> at
> com.yammer.metrics.core.MetricsRegistry.getOrAdd(MetricsRegistry.java:491)
> at
> com.yammer.metrics.core.MetricsRegistry.newMeter(MetricsRegistry.java:240)
> at com.yammer.metrics.Metrics.newMeter(Metrics.java:245)
> at
> org.apache.cassandra.metrics.ConnectionMetrics.(ConnectionMetrics.java:102)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.(OutboundTcpConnectionPool.java:53)
> at
> org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:481)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:489)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:612)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:581)
> at
> org.apache.cassandra.gms.GossipDigestSynVerbHandler.doVerb(GossipDigestSynVerbHandler.java:85)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> (...){noformat}
> Looking at ObjectName source code (e.g.
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/javax/management/ObjectName.java
> ) I can see that ":" is not a valid character, so my idea for solving this
> problem is to use one of the following:
> 1) URLEncode.encode() - seems to be more "proper" solution, but produces a
> bit unreadable metric scope like: MBean
> org.apache.cassandra.metrics:type=Connection,scope=2001%3A4c28%3A10%3A168%3A0%3A2%3A3%3A6,name=CommandCompletedTasks
> 2) .replaceAll() - we can simply replace ":" with "." which wouldn't
> give us valid IPv6 address, but will be much more readable.
> Second one seems to be a better choice for me, but I attach two patches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "HarleyLed" by HarleyLed
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "HarleyLed" page has been changed by HarleyLed: http://wiki.apache.org/cassandra/HarleyLed New page: Hello !! I am KIM ROWE. I live in Marysville. I and my sister go to The Bountiful Boarding School of Colorful Education located in Marysville.<> I am working as Forester. My dad name is Benjamen and he is a Bartender. My mother is a Servant.<> <> Also visit my blog - [[http://www.chanelbagsbuild.com|chanel handbags]]
[jira] [Created] (CASSANDRA-5308) cassandra with leveled comaction quickly runs out of free space with tons of tmp files
Illarion Kovalchuk created CASSANDRA-5308: - Summary: cassandra with leveled comaction quickly runs out of free space with tons of tmp files Key: CASSANDRA-5308 URL: https://issues.apache.org/jira/browse/CASSANDRA-5308 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.10, 1.1.9 Environment: Cluster with 4 nodes running cassandra 1.1.10 Reporter: Illarion Kovalchuk Fix For: 1.1.11 We were performing a massive upload of data to our cluster and found, that one of the nodes is ruuning out of free space nodetool ring didn't show any extra usage, but df -h / on the problamatic node shown us 95% of used space, while other nodes were all around 50% Eventually, we discovered that there's an abnormous peak of tmp files in one of our CF's: 753'906'319'257 bytes of data in 26811 files. Rebooting the node caused all that files to get deleted and node went back to normal. One of the symptoms: when the node started to misbehave and collect the temp files, it started to flush the memtables due to lot of heap used. See attached info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5308) cassandra with leveled comaction quickly runs out of free space with tons of tmp files
[ https://issues.apache.org/jira/browse/CASSANDRA-5308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Illarion Kovalchuk updated CASSANDRA-5308: -- Attachment: cassandra-1.1.10-tmpfiles-symptoms.txt > cassandra with leveled comaction quickly runs out of free space with tons of > tmp files > -- > > Key: CASSANDRA-5308 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5308 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.9, 1.1.10 > Environment: Cluster with 4 nodes running cassandra 1.1.10 >Reporter: Illarion Kovalchuk > Fix For: 1.1.11 > > Attachments: cassandra-1.1.10-tmpfiles-symptoms.txt > > > We were performing a massive upload of data to our cluster and found, that > one of the nodes is ruuning out of free space > nodetool ring didn't show any extra usage, but df -h / on the problamatic > node shown us 95% of used space, while other nodes were all around 50% > Eventually, we discovered that there's an abnormous peak of tmp files in one > of our CF's: 753'906'319'257 bytes of data in 26811 files. > Rebooting the node caused all that files to get deleted and node went back to > normal. > One of the symptoms: when the node started to misbehave and collect the temp > files, it started to flush the memtables due to lot of heap used. > See attached info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5308) cassandra with leveled comaction quickly runs out of free space with tons of tmp files
[ https://issues.apache.org/jira/browse/CASSANDRA-5308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Illarion Kovalchuk updated CASSANDRA-5308: -- Affects Version/s: (was: 1.1.9) > cassandra with leveled comaction quickly runs out of free space with tons of > tmp files > -- > > Key: CASSANDRA-5308 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5308 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.10 > Environment: Cluster with 4 nodes running cassandra 1.1.10 >Reporter: Illarion Kovalchuk > Fix For: 1.1.11 > > Attachments: cassandra-1.1.10-tmpfiles-symptoms.txt > > > We were performing a massive upload of data to our cluster and found, that > one of the nodes is ruuning out of free space > nodetool ring didn't show any extra usage, but df -h / on the problamatic > node shown us 95% of used space, while other nodes were all around 50% > Eventually, we discovered that there's an abnormous peak of tmp files in one > of our CF's: 753'906'319'257 bytes of data in 26811 files. > Rebooting the node caused all that files to get deleted and node went back to > normal. > One of the symptoms: when the node started to misbehave and collect the temp > files, it started to flush the memtables due to lot of heap used. > See attached info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5308) cassandra with leveled comaction quickly runs out of free space with tons of tmp files
Illarion Kovalchuk created CASSANDRA-5308: - Summary: cassandra with leveled comaction quickly runs out of free space with tons of tmp files Key: CASSANDRA-5308 URL: https://issues.apache.org/jira/browse/CASSANDRA-5308 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.10, 1.1.9 Environment: Cluster with 4 nodes running cassandra 1.1.10 Reporter: Illarion Kovalchuk Fix For: 1.1.11 We were performing a massive upload of data to our cluster and found, that one of the nodes is ruuning out of free space nodetool ring didn't show any extra usage, but df -h / on the problamatic node shown us 95% of used space, while other nodes were all around 50% Eventually, we discovered that there's an abnormous peak of tmp files in one of our CF's: 753'906'319'257 bytes of data in 26811 files. Rebooting the node caused all that files to get deleted and node went back to normal. One of the symptoms: when the node started to misbehave and collect the temp files, it started to flush the memtables due to lot of heap used. See attached info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5309) Issue in cassandra-cli and cqlsh
Jayadevan created CASSANDRA-5309:
Summary: Issue in cassandra-cli and cqlsh
Key: CASSANDRA-5309
URL: https://issues.apache.org/jira/browse/CASSANDRA-5309
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0
Environment: Linus (CentOS), 64 bit.
Reporter: Jayadevan
Priority: Minor
Fix For: 1.2.0
If I create a tabel using cqlsh, that table does not show when I do a describe
in cassandra-cli. For example, I create a table in cqlsh.
cqlsh:system> CREATE KEYSPACE testkp WITH replication =
{'class':'SimpleStrategy', 'replication_factor':2};
cqlsh:testkp> CREATE TABLE test (
... k int PRIMARY KEY,
... v1 int,
... v2 int
... );
cqlsh:testkp>
In cassandra-cli, I get this
[default@testkp] show schema;
create keyspace testkp
with placement_strategy = 'SimpleStrategy'
and strategy_options = {replication_factor : 2}
and durable_writes = true;
use testkp;
[default@testkp] describe;
Keyspace: testkp:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:2]
Column Families:
No Column Family is show. But if I do
[default@testkp] create column family test;
Cannot add already existing column family "test" to keyspace "testkp"
[default@testkp] list test;
Using default limit of 100
Using default column limit of 100
---
RowKey: 1
=> (column=, value=, timestamp=1362395851188000)
=> (column=v1, value=0002, timestamp=1362395851188000)
=> (column=v2, value=0003, timestamp=1362395851188000)
1 Row Returned.
Elapsed time: 105 msec(s).
So obviously the table/column family is there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5309) Issue in cassandra-cli and cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayadevan updated CASSANDRA-5309:
-
Description:
If I create a table using cqlsh, that table does not show when I do a describe
in cassandra-cli. For example, I create a table in cqlsh.
cqlsh:system> CREATE KEYSPACE testkp WITH replication =
{'class':'SimpleStrategy', 'replication_factor':2};
cqlsh:testkp> CREATE TABLE test (
... k int PRIMARY KEY,
... v1 int,
... v2 int
... );
cqlsh:testkp>
In cassandra-cli, I get this
[default@testkp] show schema;
create keyspace testkp
with placement_strategy = 'SimpleStrategy'
and strategy_options = {replication_factor : 2}
and durable_writes = true;
use testkp;
[default@testkp] describe;
Keyspace: testkp:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:2]
Column Families:
No Column Family is show. But if I do
[default@testkp] create column family test;
Cannot add already existing column family "test" to keyspace "testkp"
[default@testkp] list test;
Using default limit of 100
Using default column limit of 100
---
RowKey: 1
=> (column=, value=, timestamp=1362395851188000)
=> (column=v1, value=0002, timestamp=1362395851188000)
=> (column=v2, value=0003, timestamp=1362395851188000)
1 Row Returned.
Elapsed time: 105 msec(s).
So obviously the table/column family is there.
was:
If I create a tabel using cqlsh, that table does not show when I do a describe
in cassandra-cli. For example, I create a table in cqlsh.
cqlsh:system> CREATE KEYSPACE testkp WITH replication =
{'class':'SimpleStrategy', 'replication_factor':2};
cqlsh:testkp> CREATE TABLE test (
... k int PRIMARY KEY,
... v1 int,
... v2 int
... );
cqlsh:testkp>
In cassandra-cli, I get this
[default@testkp] show schema;
create keyspace testkp
with placement_strategy = 'SimpleStrategy'
and strategy_options = {replication_factor : 2}
and durable_writes = true;
use testkp;
[default@testkp] describe;
Keyspace: testkp:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:2]
Column Families:
No Column Family is show. But if I do
[default@testkp] create column family test;
Cannot add already existing column family "test" to keyspace "testkp"
[default@testkp] list test;
Using default limit of 100
Using default column limit of 100
---
RowKey: 1
=> (column=, value=, timestamp=1362395851188000)
=> (column=v1, value=0002, timestamp=1362395851188000)
=> (column=v2, value=0003, timestamp=1362395851188000)
1 Row Returned.
Elapsed time: 105 msec(s).
So obviously the table/column family is there.
> Issue in cassandra-cli and cqlsh
>
>
> Key: CASSANDRA-5309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5309
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.2.0
> Environment: Linus (CentOS), 64 bit.
>Reporter: Jayadevan
>Priority: Minor
> Fix For: 1.2.0
>
>
> If I create a table using cqlsh, that table does not show when I do a
> describe in cassandra-cli. For example, I create a table in cqlsh.
> cqlsh:system> CREATE KEYSPACE testkp WITH replication =
> {'class':'SimpleStrategy', 'replication_factor':2};
> cqlsh:testkp> CREATE TABLE test (
> ... k int PRIMARY KEY,
> ... v1 int,
> ... v2 int
> ... );
> cqlsh:testkp>
> In cassandra-cli, I get this
> [default@testkp] show schema;
> create keyspace testkp
> with placement_strategy = 'SimpleStrategy'
> and strategy_options = {replication_factor : 2}
> and durable_writes = true;
> use testkp;
> [default@testkp] describe;
> Keyspace: testkp:
> Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
> Durable Writes: true
> Options: [replication_factor:2]
> Column Families:
> No Column Family is show. But if I do
> [default@testkp] create column family test;
> Cannot add already existing column family "test" to keyspace "testkp"
> [default@testkp] list test;
> Using default limit of 100
> Using default column limit of 100
> ---
> RowKey: 1
> => (column=, value=, timestamp=1362395851188000)
> => (column=v1, value=0002, timestamp=1362395851188000)
> => (column=v2, value=0003, timestamp=1362395851188000)
> 1 Row Returned.
> Elapsed time: 105 msec(s).
> So obviously the table/column family is there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5309) Issue in cassandra-cli and cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayadevan updated CASSANDRA-5309:
-
Description:
If I create a table using cqlsh, that table does not show when I do a describe
in cassandra-cli. For example, I create a table in cqlsh.
cqlsh:system> CREATE KEYSPACE testkp WITH replication =
{'class':'SimpleStrategy', 'replication_factor':2};
cqlsh:testkp> CREATE TABLE test (
... k int PRIMARY KEY,
... v1 int,
... v2 int
... );
cqlsh:testkp>
In cassandra-cli, I get this
[default@testkp] show schema;
create keyspace testkp
with placement_strategy = 'SimpleStrategy'
and strategy_options = {replication_factor : 2}
and durable_writes = true;
use testkp;
[default@testkp] describe;
Keyspace: testkp:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:2]
Column Families:
No Column Family is shown. But if I do
[default@testkp] create column family test;
Cannot add already existing column family "test" to keyspace "testkp"
[default@testkp] list test;
Using default limit of 100
Using default column limit of 100
---
RowKey: 1
=> (column=, value=, timestamp=1362395851188000)
=> (column=v1, value=0002, timestamp=1362395851188000)
=> (column=v2, value=0003, timestamp=1362395851188000)
1 Row Returned.
Elapsed time: 105 msec(s).
So obviously the table/column family is there.
was:
If I create a table using cqlsh, that table does not show when I do a describe
in cassandra-cli. For example, I create a table in cqlsh.
cqlsh:system> CREATE KEYSPACE testkp WITH replication =
{'class':'SimpleStrategy', 'replication_factor':2};
cqlsh:testkp> CREATE TABLE test (
... k int PRIMARY KEY,
... v1 int,
... v2 int
... );
cqlsh:testkp>
In cassandra-cli, I get this
[default@testkp] show schema;
create keyspace testkp
with placement_strategy = 'SimpleStrategy'
and strategy_options = {replication_factor : 2}
and durable_writes = true;
use testkp;
[default@testkp] describe;
Keyspace: testkp:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:2]
Column Families:
No Column Family is show. But if I do
[default@testkp] create column family test;
Cannot add already existing column family "test" to keyspace "testkp"
[default@testkp] list test;
Using default limit of 100
Using default column limit of 100
---
RowKey: 1
=> (column=, value=, timestamp=1362395851188000)
=> (column=v1, value=0002, timestamp=1362395851188000)
=> (column=v2, value=0003, timestamp=1362395851188000)
1 Row Returned.
Elapsed time: 105 msec(s).
So obviously the table/column family is there.
> Issue in cassandra-cli and cqlsh
>
>
> Key: CASSANDRA-5309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5309
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.2.0
> Environment: Linus (CentOS), 64 bit.
>Reporter: Jayadevan
>Priority: Minor
> Fix For: 1.2.0
>
>
> If I create a table using cqlsh, that table does not show when I do a
> describe in cassandra-cli. For example, I create a table in cqlsh.
> cqlsh:system> CREATE KEYSPACE testkp WITH replication =
> {'class':'SimpleStrategy', 'replication_factor':2};
> cqlsh:testkp> CREATE TABLE test (
> ... k int PRIMARY KEY,
> ... v1 int,
> ... v2 int
> ... );
> cqlsh:testkp>
> In cassandra-cli, I get this
> [default@testkp] show schema;
> create keyspace testkp
> with placement_strategy = 'SimpleStrategy'
> and strategy_options = {replication_factor : 2}
> and durable_writes = true;
> use testkp;
> [default@testkp] describe;
> Keyspace: testkp:
> Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
> Durable Writes: true
> Options: [replication_factor:2]
> Column Families:
> No Column Family is shown. But if I do
> [default@testkp] create column family test;
> Cannot add already existing column family "test" to keyspace "testkp"
> [default@testkp] list test;
> Using default limit of 100
> Using default column limit of 100
> ---
> RowKey: 1
> => (column=, value=, timestamp=1362395851188000)
> => (column=v1, value=0002, timestamp=1362395851188000)
> => (column=v2, value=0003, timestamp=1362395851188000)
> 1 Row Returned.
> Elapsed time: 105 msec(s).
> So obviously the table/column family is there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5301) Clean up bash scripts in bin/ and tools/bin/
[ https://issues.apache.org/jira/browse/CASSANDRA-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-5301: --- Attachment: CASSANDRA-5301-v1.patch patch that breaks out common code into configaware.in.sh that is installed in the same directory as the actualy executable scripts problems is that we should probably not install include-files in /usr/bin etc, and if we drop it into say /usr/share/cassandra we would just have to try the various locations in the tool scripts again, the same code we just removed so i'd probably close this as WONTFIX unless we want to do a real overhaul and perhaps have a wrapper script to all the small tools? something like "cassandra-tool sstablelevelreset aa bb" > Clean up bash scripts in bin/ and tools/bin/ > > > Key: CASSANDRA-5301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5301 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Trivial > Attachments: CASSANDRA-5301-v1.patch > > > there is alot of copy-and-pasting going on in the scripts in bin/ and > tools/bin/, create a script to include in the various tool-scripts, it should > do classpath and config file detection etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5302) Fix nodetool ring and status output format for IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michał Michalski updated CASSANDRA-5302:
Description:
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture$ nodetool -h myhost status
Datacenter: DC1
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
TokenRack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are "similar". Alternative I'm considering is finding
the longest address - it will be 100% accurate.
was:
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture$ nodetool -h myhost status
Datacenter: DC1
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
TokenRack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are equal. Let me know if there's the case when it's
not valid.
> Fix nodetool ring and status output format for IPv6 addresses
> -
>
> Key: CASSANDRA-5302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5302
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Michał Michalski
>Assignee: Michał Michalski
>Priority: Trivial
> Attachments: 5302.patch
>
>
> My pedantic nature can't stand having unaligned columns in nodetool outputs,
> which happens when IP addresses are IPv6 ones:
> {noformat}michal@aperture$ nodetool -h myhost status
> Datacenter: DC1
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Owns (effective) Host ID
>TokenRack
> UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
> d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
> rack2
> UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
> 0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
> rack1
> {noformat}
> I'm attaching a patch that fixes this problem for nodetool status / ring
> commands. It does it by picking first item in nodes list (for nodetool ring
> it's first node in general, for nodetool status it's first node in each DC)
> and uses its length as a field length for output.
> It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC
> and the lenghts of addresses are "similar". Alternative I'm considering is
> finding the longest address - it will be 100% accurate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5302) Fix nodetool ring and status output format for IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michał Michalski updated CASSANDRA-5302:
Description:
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture$ nodetool -h myhost status
Datacenter: DC1
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
TokenRack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are "similar". The alternative I'm considering too is
finding the longest address - it will be 100% accurate.
was:
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture$ nodetool -h myhost status
Datacenter: DC1
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
TokenRack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are "similar". Alternative I'm considering is finding
the longest address - it will be 100% accurate.
> Fix nodetool ring and status output format for IPv6 addresses
> -
>
> Key: CASSANDRA-5302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5302
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Michał Michalski
>Assignee: Michał Michalski
>Priority: Trivial
> Attachments: 5302.patch
>
>
> My pedantic nature can't stand having unaligned columns in nodetool outputs,
> which happens when IP addresses are IPv6 ones:
> {noformat}michal@aperture$ nodetool -h myhost status
> Datacenter: DC1
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Owns (effective) Host ID
>TokenRack
> UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
> d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
> rack2
> UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
> 0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
> rack1
> {noformat}
> I'm attaching a patch that fixes this problem for nodetool status / ring
> commands. It does it by picking first item in nodes list (for nodetool ring
> it's first node in general, for nodetool status it's first node in each DC)
> and uses its length as a field length for output.
> It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC
> and the lenghts of addresses are "similar". The alternative I'm considering
> too is finding the longest address - it will be 100% accurate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5289) DatabaseDescriptor.hasExistingNoSystemTables return true even with only system keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592183#comment-13592183
]
Jason Brown commented on CASSANDRA-5289:
Honestly, you could debate whether we need that check at all. In either case,
all we do after calling hasExistingNoSystemTables() is tell the user to create
some CFs - I think that should be obvious by now :). I think we can just
eliminate that method and the not overwhelmingly helpful logging, and have
startup be nanoseonds more efficient.
> DatabaseDescriptor.hasExistingNoSystemTables return true even with only
> system keyspace
> ---
>
> Key: CASSANDRA-5289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5289
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jackson Chung
>Priority: Minor
> Attachments: 5289.diff
>
>
> The hasExistingNoSystemTables method in DatabaseDescriptor checks for
> directory only.
> On a new start, system KS would be created. This method current return true
> because of it, resulting incorrect/confusing log:
> logger.info("Found table data in data directories. Consider using the CLI to
> define your schema.") ;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5289) DatabaseDescriptor.hasExistingNoSystemTables return true even with only system keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Brown updated CASSANDRA-5289:
---
Reviewer: jasobrown
> DatabaseDescriptor.hasExistingNoSystemTables return true even with only
> system keyspace
> ---
>
> Key: CASSANDRA-5289
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5289
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jackson Chung
>Priority: Minor
> Attachments: 5289.diff
>
>
> The hasExistingNoSystemTables method in DatabaseDescriptor checks for
> directory only.
> On a new start, system KS would be created. This method current return true
> because of it, resulting incorrect/confusing log:
> logger.info("Found table data in data directories. Consider using the CLI to
> define your schema.") ;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5045) Add Configuration Loader to DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592195#comment-13592195 ] Jason Brown commented on CASSANDRA-5045: [~slebresne]Sylvain, if you can rebase again, I'll review the patch. > Add Configuration Loader to DatabaseDescriptor > -- > > Key: CASSANDRA-5045 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5045 > Project: Cassandra > Issue Type: New Feature >Reporter: Michael Guymon >Priority: Minor > Labels: patch > Attachments: > 0001-Add-configuration-loader-to-DatabaseDescriptor.patch, 5045-v2.txt > > > Based on feed back from CASSANDRA-4998 - > Added IConfigurationLoader that is used to load an external Config. When the > System Property cassandra.config.loader is defined with an implementing > class, DatabaseDescriptor with will that Config over loading the > cassandra.yaml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5045) Add Configuration Loader to DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592195#comment-13592195 ] Jason Brown edited comment on CASSANDRA-5045 at 3/4/13 1:32 PM: [~slebresne], if you can rebase again, I'll review the patch. was (Author: jasobrown): [~slebresne]Sylvain, if you can rebase again, I'll review the patch. > Add Configuration Loader to DatabaseDescriptor > -- > > Key: CASSANDRA-5045 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5045 > Project: Cassandra > Issue Type: New Feature >Reporter: Michael Guymon >Priority: Minor > Labels: patch > Attachments: > 0001-Add-configuration-loader-to-DatabaseDescriptor.patch, 5045-v2.txt > > > Based on feed back from CASSANDRA-4998 - > Added IConfigurationLoader that is used to load an external Config. When the > System Property cassandra.config.loader is defined with an implementing > class, DatabaseDescriptor with will that Config over loading the > cassandra.yaml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[ https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592203#comment-13592203 ] Jason Brown commented on CASSANDRA-5051: +1 on this ticket (and patch), as well. My devops guys asked about something like this recently, so it will be helpful. I see it's tagged for 2.0 only; the change to the code seems innocuous enough, is there a safety concern for not putting it into 1.2, as well? > Allow automatic cleanup after gc_grace > -- > > Key: CASSANDRA-5051 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5051 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Labels: vnodes > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-5051.patch, 5051-v2.txt > > > When using vnodes, after adding a new node you have to run cleanup on all the > machines, because you don't know which are affected and chances are it was > most if not all of them. As an alternative to this intensive process, we > could allow cleanup during compaction if the data is older than gc_grace (or > perhaps some other time period since people tend to use gc_grace hacks to get > rid of tombstones.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5308) cassandra with leveled comaction quickly runs out of free space with tons of tmp files
[ https://issues.apache.org/jira/browse/CASSANDRA-5308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592212#comment-13592212 ] Jonathan Ellis commented on CASSANDRA-5308: --- Did you check the log for errors? > cassandra with leveled comaction quickly runs out of free space with tons of > tmp files > -- > > Key: CASSANDRA-5308 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5308 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.10 > Environment: Cluster with 4 nodes running cassandra 1.1.10 >Reporter: Illarion Kovalchuk > Fix For: 1.1.11 > > Attachments: cassandra-1.1.10-tmpfiles-symptoms.txt > > > We were performing a massive upload of data to our cluster and found, that > one of the nodes is ruuning out of free space > nodetool ring didn't show any extra usage, but df -h / on the problamatic > node shown us 95% of used space, while other nodes were all around 50% > Eventually, we discovered that there's an abnormous peak of tmp files in one > of our CF's: 753'906'319'257 bytes of data in 26811 files. > Rebooting the node caused all that files to get deleted and node went back to > normal. > One of the symptoms: when the node started to misbehave and collect the temp > files, it started to flush the memtables due to lot of heap used. > See attached info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5309) Add a note to cassandra-cli "show schema" explaining that it is cql-oblivious
[
https://issues.apache.org/jira/browse/CASSANDRA-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5309:
--
Fix Version/s: (was: 1.2.0)
Assignee: Aleksey Yeschenko
Summary: Add a note to cassandra-cli "show schema" explaining that it
is cql-oblivious (was: Issue in cassandra-cli and cqlsh)
We should build a notice into the cli since this keeps coming up.
> Add a note to cassandra-cli "show schema" explaining that it is cql-oblivious
> -
>
> Key: CASSANDRA-5309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5309
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.2.0
> Environment: Linus (CentOS), 64 bit.
>Reporter: Jayadevan
>Assignee: Aleksey Yeschenko
>Priority: Minor
>
> If I create a table using cqlsh, that table does not show when I do a
> describe in cassandra-cli. For example, I create a table in cqlsh.
> cqlsh:system> CREATE KEYSPACE testkp WITH replication =
> {'class':'SimpleStrategy', 'replication_factor':2};
> cqlsh:testkp> CREATE TABLE test (
> ... k int PRIMARY KEY,
> ... v1 int,
> ... v2 int
> ... );
> cqlsh:testkp>
> In cassandra-cli, I get this
> [default@testkp] show schema;
> create keyspace testkp
> with placement_strategy = 'SimpleStrategy'
> and strategy_options = {replication_factor : 2}
> and durable_writes = true;
> use testkp;
> [default@testkp] describe;
> Keyspace: testkp:
> Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
> Durable Writes: true
> Options: [replication_factor:2]
> Column Families:
> No Column Family is shown. But if I do
> [default@testkp] create column family test;
> Cannot add already existing column family "test" to keyspace "testkp"
> [default@testkp] list test;
> Using default limit of 100
> Using default column limit of 100
> ---
> RowKey: 1
> => (column=, value=, timestamp=1362395851188000)
> => (column=v1, value=0002, timestamp=1362395851188000)
> => (column=v2, value=0003, timestamp=1362395851188000)
> 1 Row Returned.
> Elapsed time: 105 msec(s).
> So obviously the table/column family is there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[ https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592216#comment-13592216 ] Jonathan Ellis commented on CASSANDRA-5051: --- Brandon's pretty confident, but I'd rather not cram it into a minor release just in case there's something we missed. > Allow automatic cleanup after gc_grace > -- > > Key: CASSANDRA-5051 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5051 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Labels: vnodes > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-5051.patch, 5051-v2.txt > > > When using vnodes, after adding a new node you have to run cleanup on all the > machines, because you don't know which are affected and chances are it was > most if not all of them. As an alternative to this intensive process, we > could allow cleanup during compaction if the data is older than gc_grace (or > perhaps some other time period since people tend to use gc_grace hacks to get > rid of tombstones.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "TerryRale" by TerryRale
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "TerryRale" page has been changed by TerryRale: http://wiki.apache.org/cassandra/TerryRale New page: Hey fellas !! The name is VANESA JOHNSTON.<> I am 46. I study at The Refundable Finishing School located in New Haven. I work as a Blacksmith. My dad name is Bradley and he is a Artist. My momy is a Mechanician.<> <> My blog [[http://www.beatsheadphonereview.com|dr dre earphones]]
[jira] [Commented] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[ https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592219#comment-13592219 ] Jason Brown commented on CASSANDRA-5051: Yeah, I figured it was a safety concern :). Not a problem. > Allow automatic cleanup after gc_grace > -- > > Key: CASSANDRA-5051 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5051 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Labels: vnodes > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-5051.patch, 5051-v2.txt > > > When using vnodes, after adding a new node you have to run cleanup on all the > machines, because you don't know which are affected and chances are it was > most if not all of them. As an alternative to this intensive process, we > could allow cleanup during compaction if the data is older than gc_grace (or > perhaps some other time period since people tend to use gc_grace hacks to get > rid of tombstones.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "dr_dre_headphones_J3O1" by TerryRale
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "dr_dre_headphones_J3O1" page has been changed by TerryRale: http://wiki.apache.org/cassandra/dr_dre_headphones_J3O1 New page: Not one person would've notion, this is thought to not have any suspense fight against, [[http://www.majorchanelbags.com|chanel handbags]] along with this type of pleasantly surprised anyone gains ... ...<> <> Oh no, only a few consumers, [[http://www.majorchanelbags.com|http://www.majorchanelbags.com]] by earliest towards last not less than some individuals believe, victory belongs to the young grasp Ferre ... ...<> <> The thinking behind this unique, [[http://www.majorchanelbags.com|chanel replica]] gamblers experience won't allow dreary, Senna this approach ass precisely where that asshole hearsay, [[http://www.chanelpursesoutletbags.com|chanel bags]] how can that will Ferre the magician might triumph? 5 . *, likewise claimed hence thoroughly, an even twenty-two mage main difference [[http://www.chanelpursesoutletbags.com|http://www.chanelpursesoutletbags.com]] icon, there seems to be a new pervert referred to as neuropathy ... ...<> <> The adventure end results, Lin conquered elves infamous [[http://www.chanelpursesoutletbags.com|chanel bags]] get good at Vitas, as well as succeed in being a choice Sun's rays Royal team, produced [[http://www.beatsheadphonereview.com|beats by dre cheap]] an important development on the conflict, effectiveness is known for a [[http://www.beatsheadphonereview.com|http://www.beatsheadphonereview.com]] switch the earth the wrong way up transform, without doubt is definitely the number one receiver, combined with one other [[http://www.beatsheadphonereview.com|beats by dr dre cheap]] success stay at home good information, design is actually snicker close possibly not technique dental problems Senna
[jira] [Commented] (CASSANDRA-5309) Add a note to cassandra-cli "show schema" explaining that it is cql-oblivious
[
https://issues.apache.org/jira/browse/CASSANDRA-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592230#comment-13592230
]
Mihail Karp commented on CASSANDRA-5309:
created CF with cqlsh -3 not visible(and unusable) in thrift api (phpcassa and
cassandra-cli)
but CF created in phpcassa/cassandra-cli visible and accessible in cqlsh -3 and
phpcassa/cassandra-cli
C* 1.2.2
related to this ticket?
or this is feature?
> Add a note to cassandra-cli "show schema" explaining that it is cql-oblivious
> -
>
> Key: CASSANDRA-5309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5309
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.2.0
> Environment: Linus (CentOS), 64 bit.
>Reporter: Jayadevan
>Assignee: Aleksey Yeschenko
>Priority: Minor
>
> If I create a table using cqlsh, that table does not show when I do a
> describe in cassandra-cli. For example, I create a table in cqlsh.
> cqlsh:system> CREATE KEYSPACE testkp WITH replication =
> {'class':'SimpleStrategy', 'replication_factor':2};
> cqlsh:testkp> CREATE TABLE test (
> ... k int PRIMARY KEY,
> ... v1 int,
> ... v2 int
> ... );
> cqlsh:testkp>
> In cassandra-cli, I get this
> [default@testkp] show schema;
> create keyspace testkp
> with placement_strategy = 'SimpleStrategy'
> and strategy_options = {replication_factor : 2}
> and durable_writes = true;
> use testkp;
> [default@testkp] describe;
> Keyspace: testkp:
> Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
> Durable Writes: true
> Options: [replication_factor:2]
> Column Families:
> No Column Family is shown. But if I do
> [default@testkp] create column family test;
> Cannot add already existing column family "test" to keyspace "testkp"
> [default@testkp] list test;
> Using default limit of 100
> Using default column limit of 100
> ---
> RowKey: 1
> => (column=, value=, timestamp=1362395851188000)
> => (column=v1, value=0002, timestamp=1362395851188000)
> => (column=v2, value=0003, timestamp=1362395851188000)
> 1 Row Returned.
> Elapsed time: 105 msec(s).
> So obviously the table/column family is there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5309) Add a note to cassandra-cli "show schema" explaining that it is cql-oblivious
[
https://issues.apache.org/jira/browse/CASSANDRA-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592232#comment-13592232
]
Aleksey Yeschenko commented on CASSANDRA-5309:
--
This is the intended behavior.
> Add a note to cassandra-cli "show schema" explaining that it is cql-oblivious
> -
>
> Key: CASSANDRA-5309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5309
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.2.0
> Environment: Linus (CentOS), 64 bit.
>Reporter: Jayadevan
>Assignee: Aleksey Yeschenko
>Priority: Minor
>
> If I create a table using cqlsh, that table does not show when I do a
> describe in cassandra-cli. For example, I create a table in cqlsh.
> cqlsh:system> CREATE KEYSPACE testkp WITH replication =
> {'class':'SimpleStrategy', 'replication_factor':2};
> cqlsh:testkp> CREATE TABLE test (
> ... k int PRIMARY KEY,
> ... v1 int,
> ... v2 int
> ... );
> cqlsh:testkp>
> In cassandra-cli, I get this
> [default@testkp] show schema;
> create keyspace testkp
> with placement_strategy = 'SimpleStrategy'
> and strategy_options = {replication_factor : 2}
> and durable_writes = true;
> use testkp;
> [default@testkp] describe;
> Keyspace: testkp:
> Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
> Durable Writes: true
> Options: [replication_factor:2]
> Column Families:
> No Column Family is shown. But if I do
> [default@testkp] create column family test;
> Cannot add already existing column family "test" to keyspace "testkp"
> [default@testkp] list test;
> Using default limit of 100
> Using default column limit of 100
> ---
> RowKey: 1
> => (column=, value=, timestamp=1362395851188000)
> => (column=v1, value=0002, timestamp=1362395851188000)
> => (column=v2, value=0003, timestamp=1362395851188000)
> 1 Row Returned.
> Elapsed time: 105 msec(s).
> So obviously the table/column family is there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5308) cassandra with leveled comaction quickly runs out of free space with tons of tmp files
[ https://issues.apache.org/jira/browse/CASSANDRA-5308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592234#comment-13592234 ] Illarion Kovalchuk commented on CASSANDRA-5308: --- Yes, I expected the failures preventing compaction to finish to be there, but no - there were no errors. > cassandra with leveled comaction quickly runs out of free space with tons of > tmp files > -- > > Key: CASSANDRA-5308 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5308 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.10 > Environment: Cluster with 4 nodes running cassandra 1.1.10 >Reporter: Illarion Kovalchuk > Fix For: 1.1.11 > > Attachments: cassandra-1.1.10-tmpfiles-symptoms.txt > > > We were performing a massive upload of data to our cluster and found, that > one of the nodes is ruuning out of free space > nodetool ring didn't show any extra usage, but df -h / on the problamatic > node shown us 95% of used space, while other nodes were all around 50% > Eventually, we discovered that there's an abnormous peak of tmp files in one > of our CF's: 753'906'319'257 bytes of data in 26811 files. > Rebooting the node caused all that files to get deleted and node went back to > normal. > One of the symptoms: when the node started to misbehave and collect the temp > files, it started to flush the memtables due to lot of heap used. > See attached info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592241#comment-13592241 ] Sylvain Lebresne commented on CASSANDRA-5062: - [~jbellis] Still a bit confused by your diagram really. Mainly, it seems from what's above that your mostRecentCommitted is a Paxos proposal number, but then you seem to use it to decide whether to move from one round to the other. So does that mean that what you call round in those diagram is just a proposal number (in which case, I'm still confused on how you actually use Paxos to do CAS) or does it means a full instance of the Paxos algorithm (in which case, I haven't fully understood how you decide it's ok to start a new round without breaking correctness)? All that to say, if you have some pseud-code of the whole things, I'd be interested :). In the meantime, I've pushed my own reflection a bit too, fixing the impracticability I mention earlier (of an ever growing log basically). I wrote the thing down to convince myself this was working and get rid of foggy part. This is a largely a brain dump, though it does contain a fairly precise algorithm that as far as I can tell, work (but I could definitively have missed something). I put that brain at http://goo.gl/pnq4Z, in case that's of interest (it's *not* short, but I think it's fairly precise). That proposal definitively share a number of idea/similarity with Jonathan's one, but it's definitively not similar since it doesn't provide the same tradeoff (it doesn't allow mixing CAS and non-CAS operation for one, and is not "rate limited by clock resolution and clock skew", though I'm not sure what that means tbh). It's fairly simple to implement too. Anyway, just wanted to share my own reflexion. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3734) Support native link w/o JNA in Java7
[ https://issues.apache.org/jira/browse/CASSANDRA-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-3734: --- Attachment: 3734-v2.diff Now that we've made java7 the default for 2.0, there's no reason not to go ahead with this ticket. I've taken Peter's code and basically simplified it as we no longer need to keep the java6/jna piece around. I also kept Peter's createTemporaryDirectory() methods around on FileUtils even though I didn't find a parallel on CLibrary. > Support native link w/o JNA in Java7 > > > Key: CASSANDRA-3734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3734 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Peter Schuller >Priority: Minor > Fix For: 2.0 > > Attachments: 3734-v2.diff, CASSANDRA-3734-trunk-v1.txt > > > Java7 provides native support for hard links: > http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#createLink(java.nio.file.Path, > java.nio.file.Path) > We should prefer this method when Java7 is the host. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592282#comment-13592282 ] Cristian Opris commented on CASSANDRA-5062: --- FWIW, just to clarify my own examples, I can't speak for Jonathan: *version counter or most recent commit is NOT the paxos proposal number*. The Paxos proposal number I've ommitted in most of my examples except for the last more detailed one. Timeuuid is fine for proposal number. Also with regard to logging/no logging. I believe you only need to keep a log if you plan to replicate operations rather than state. Transfering state (as we discussed so far) does not require a log but makes it impractical to replicate large values, so this is the main trade off, I don't believe it's got anything to do with paxos. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5310) New authentication module does not wok in multi datacenters in case of network outage
jal created CASSANDRA-5310: -- Summary: New authentication module does not wok in multi datacenters in case of network outage Key: CASSANDRA-5310 URL: https://issues.apache.org/jira/browse/CASSANDRA-5310 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.2 Environment: Ubuntu 12.04 Cluster of 16 nodes in 2 datacenters (8 nodes in each datacenter) Reporter: jal With 1.2.2, I am using the new authentication backend PasswordAuthenticator with the authorizer CassandraAuthorizer In case of network outage, we are no more able to connect to Cassandra. Here is the error message we get when I want to connect through cqlsh: Traceback (most recent call last): File "./cqlsh", line 2262, in main(*read_options(sys.argv[1:], os.environ)) File "./cqlsh", line 2248, in main display_float_precision=options.float_precision) File "./cqlsh", line 483, in __init__ cql_version=cqlver, transport=transport) File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py", line 143, in connect File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py", line 59, in __init__ File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/thrifteries.py", line 157, in establish_connection File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py", line 455, in login File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py", line 476, in recv_login cql.cassandra.ttypes.AuthenticationException: AuthenticationException(why='org.apache.cassandra.exceptions.UnavailableException: Cannot achieve consistency level QUORUM') -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3753) Update CqlPreparedResult to provide type information
[ https://issues.apache.org/jira/browse/CASSANDRA-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592306#comment-13592306 ] Adriano Paggi commented on CASSANDRA-3753: -- The type names returned are partial for collection types. Returns just MapType without saying anything about the key-value types. A more intuitive response could be something like org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type) Just like in CqlResult -> schema -> value_types (returned by execute_cql3_query) Maybe this ticket should be re-opened? > Update CqlPreparedResult to provide type information > > > Key: CASSANDRA-3753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3753 > Project: Cassandra > Issue Type: Improvement > Components: API >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne >Priority: Critical > Labels: cql > Fix For: 1.1.0 > > Attachments: 0001-3753-cql3.patch, 0002-Thrift-gen-file-changes.patch > > > As discussed on CASSANDRA-3634, adding type information to a prepared > statement would allow more client-side error checking. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-5310) New authentication module does not wok in multi datacenters in case of network outage
[
https://issues.apache.org/jira/browse/CASSANDRA-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-5310.
---
Resolution: Not A Problem
The {{system_auth}} keyspace only has a single replica by default, since that's
all we can rely on being present everywhere. You are welcome to configure it
to replicate using NTS and as many replicas as you see fit.
> New authentication module does not wok in multi datacenters in case of
> network outage
> -
>
> Key: CASSANDRA-5310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5310
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.2
> Environment: Ubuntu 12.04
> Cluster of 16 nodes in 2 datacenters (8 nodes in each datacenter)
>Reporter: jal
>
> With 1.2.2, I am using the new authentication backend PasswordAuthenticator
> with the authorizer CassandraAuthorizer
> In case of network outage, we are no more able to connect to Cassandra.
> Here is the error message we get when I want to connect through cqlsh:
> Traceback (most recent call last):
> File "./cqlsh", line 2262, in
> main(*read_options(sys.argv[1:], os.environ))
> File "./cqlsh", line 2248, in main
> display_float_precision=options.float_precision)
> File "./cqlsh", line 483, in __init__
> cql_version=cqlver, transport=transport)
> File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py", line
> 143, in connect
> File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py",
> line 59, in __init__
> File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/thrifteries.py",
> line 157, in establish_connection
> File
> "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py",
> line 455, in login
> File
> "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py",
> line 476, in recv_login
> cql.cassandra.ttypes.AuthenticationException:
> AuthenticationException(why='org.apache.cassandra.exceptions.UnavailableException:
> Cannot achieve consistency level QUORUM')
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5310) New authentication module does not wok in multi datacenters in case of network outage
[ https://issues.apache.org/jira/browse/CASSANDRA-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592330#comment-13592330 ] jal commented on CASSANDRA-5310: If I use NTS and set a replication of 6 for example (3 replicas in DC1, 3 replicas in DC2), I still have the problem, because the authentication module works in QUORUM consistency, and needs to read the user on 4 nodes (probably 3 nodes in the local DC, and at least 1 node in the second datacenter). If there is a network outage, you will never be able to read the user in the remote center, and you will not get the QUORUM. This happen everytime I want to open a new connection. This also probably happen after 2000 millisec. (default duration of the permissions_validity_in_ms) if your connection is already open. > New authentication module does not wok in multi datacenters in case of > network outage > - > > Key: CASSANDRA-5310 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5310 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.2 > Environment: Ubuntu 12.04 > Cluster of 16 nodes in 2 datacenters (8 nodes in each datacenter) >Reporter: jal > > With 1.2.2, I am using the new authentication backend PasswordAuthenticator > with the authorizer CassandraAuthorizer > In case of network outage, we are no more able to connect to Cassandra. > Here is the error message we get when I want to connect through cqlsh: > Traceback (most recent call last): > File "./cqlsh", line 2262, in > main(*read_options(sys.argv[1:], os.environ)) > File "./cqlsh", line 2248, in main > display_float_precision=options.float_precision) > File "./cqlsh", line 483, in __init__ > cql_version=cqlver, transport=transport) > File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py", line > 143, in connect > File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py", > line 59, in __init__ > File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/thrifteries.py", > line 157, in establish_connection > File > "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py", > line 455, in login > File > "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py", > line 476, in recv_login > cql.cassandra.ttypes.AuthenticationException: > AuthenticationException(why='org.apache.cassandra.exceptions.UnavailableException: > Cannot achieve consistency level QUORUM') -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Support null values in PreparedStatements parameters
Updated Branches:
refs/heads/cassandra-1.2 3a3f1d947 -> ef574569a
Support null values in PreparedStatements parameters
patch by slebresne; reviewed by iamaleksey for CASSANDRA-5081
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef574569
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef574569
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef574569
Branch: refs/heads/cassandra-1.2
Commit: ef574569a23d33e18c3d9893a323a891a96215db
Parents: 3a3f1d9
Author: Sylvain Lebresne
Authored: Mon Mar 4 17:58:16 2013 +0100
Committer: Sylvain Lebresne
Committed: Mon Mar 4 17:58:16 2013 +0100
--
CHANGES.txt|1 +
src/java/org/apache/cassandra/cql3/Constants.java | 20 ++--
src/java/org/apache/cassandra/cql3/Lists.java | 18 ++-
src/java/org/apache/cassandra/cql3/Maps.java | 15 -
src/java/org/apache/cassandra/cql3/Sets.java |7 ++-
.../cassandra/cql3/functions/FunctionCall.java |9 +++-
.../cassandra/cql3/statements/SelectStatement.java | 40 --
.../cassandra/cql3/statements/UpdateStatement.java | 15 -
8 files changed, 103 insertions(+), 22 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef574569/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a6b2cff..c1ae2b9 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -7,6 +7,7 @@
* Fix insufficient validation of UPDATE queries against counter cfs
(CASSANDRA-5300)
* Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285)
+ * Handle null values when executing prepared statement (CASSANDRA-5081)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef574569/src/java/org/apache/cassandra/cql3/Constants.java
--
diff --git a/src/java/org/apache/cassandra/cql3/Constants.java
b/src/java/org/apache/cassandra/cql3/Constants.java
index 60098be..f630869 100644
--- a/src/java/org/apache/cassandra/cql3/Constants.java
+++ b/src/java/org/apache/cassandra/cql3/Constants.java
@@ -254,7 +254,8 @@ public abstract class Constants
try
{
ByteBuffer value = values.get(bindIndex);
-receiver.type.validate(value);
+if (value != null)
+receiver.type.validate(value);
return value;
}
catch (MarshalException e)
@@ -265,7 +266,8 @@ public abstract class Constants
public Value bind(List values) throws
InvalidRequestException
{
-return new Constants.Value(bindAndGet(values));
+ByteBuffer bytes = bindAndGet(values);
+return bytes == null ? null : new Constants.Value(bytes);
}
}
@@ -279,7 +281,8 @@ public abstract class Constants
public void execute(ByteBuffer rowKey, ColumnFamily cf,
ColumnNameBuilder prefix, UpdateParameters params) throws
InvalidRequestException
{
ByteBuffer cname = columnName == null ? prefix.build() :
prefix.add(columnName.key).build();
-cf.addColumn(params.makeColumn(cname,
t.bindAndGet(params.variables)));
+ByteBuffer value = t.bindAndGet(params.variables);
+cf.addColumn(value == null ? params.makeTombstone(cname) :
params.makeColumn(cname, value));
}
}
@@ -292,7 +295,10 @@ public abstract class Constants
public void execute(ByteBuffer rowKey, ColumnFamily cf,
ColumnNameBuilder prefix, UpdateParameters params) throws
InvalidRequestException
{
-long increment =
ByteBufferUtil.toLong(t.bindAndGet(params.variables));
+ByteBuffer bytes = t.bindAndGet(params.variables);
+if (bytes == null)
+throw new InvalidRequestException("Invalid null value for
counter increment");
+long increment = ByteBufferUtil.toLong(bytes);
ByteBuffer cname = columnName == null ? prefix.build() :
prefix.add(columnName.key).build();
cf.addCounter(new QueryPath(cf.metadata().cfName, null, cname),
increment);
}
@@ -307,7 +313,11 @@ public abstract class Constants
public void execute(ByteBuffer rowKey, ColumnFamily cf,
ColumnNameBuilder prefix, UpdateParameters params) throws
InvalidRequestException
{
-long increment =
ByteBufferUtil.toLong(t.bindAndGet(params.variables));
+ByteBuffer bytes = t.bindAndGet(params.variables);
+if (bytes == null)
+
[jira] [Commented] (CASSANDRA-3430) Break Big Compaction Lock apart
[ https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592356#comment-13592356 ] Sylvain Lebresne commented on CASSANDRA-3430: - Sounds reasonable on principle. A few remarks/comments however: * I believe the reason the assertion in runWithCompactionsDisabled fails in CompactionsTest is because when a strategy is paused, compaction can still be submitted, they will just exit right away in CompactionTask. But sstables are marked compacting before that happens. In other words, pausing don't guaranteed we won't mark sstable compacting, just that they won't really compact (so they will be marked and unmark almost right away). So maybe we could move the isActive check earlier (this would have my preference, but I'm not sure where without dublicating the check), or we should remove the assertion . * During truncate, we only stop compactions on the main CF. We should also stop it for indexes too. * We used to ensure that Scrub, SSTableRewrite and Cleanup were running on *all* sstable (at the time it ran). This is no longer the case, being compacted sstable will now be excluded. Is that on purpose? It's clearly fine for SSTableRewrite given it's use case. Cleanup is more problematic, though if we get read of manual cleanup for 2.0, that's fixes that :). Less sure about scrub. Scrub can detect corruption that normal compaction wouldn't see, so if scrub skips being compacted sstable, it's harder to ensure all sstables have been scrubbed. * We still get the truncateAt outside of the "protected" block. Meaning, we could still have a memtable flushed and compacted with old sstable between the grab of truncateAt and when we interrupt compaction (sure, we've make that even more unlickely but not "impossible"). But I think we can more truncateAt inside the truncateRunnable now to fix that once and for all. * This makes CFS.truncate() blocking, and thus having it return a Future is misleading. We should probably rename it truncateBlocking and have it return void. Or we keep it asynchronous by pushing the runWithCompactionsDisabled on some executor. * We might want to move the 'collector.finishCompaction(ci)' in CompactionTask up in it's finally block. If sound like an IO error could let a task "in compaction" which would then block the wait in runWithCompactionsDisabled. * Concerning that wait in runWithCompactionsDisabled, wouldn't it make sense to move it inside interruptCompactionFor? * One slightly changed tradeoff is that a major compaction may kill almost done compactions. Not a big deal really (a good idea in fact, at least for truncate), but may be worth an entry in the NEWS file. * The truncate comment is CFS is not up to date (mentions CompactionManager.submitTruncate). > Break Big Compaction Lock apart > --- > > Key: CASSANDRA-3430 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3430 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Labels: compaction > Fix For: 2.0 > > Attachments: 3430-1.0.txt, 3430-1.1.txt, 3430-v2.txt, 3430-v3.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5302) Fix nodetool ring and status output format for IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592367#comment-13592367
]
Brandon Williams commented on CASSANDRA-5302:
-
To be pedantic in return, this breaks the case where any ipv4/6 string
representation isn't uniform across the nodes. For instance:
{noformat}
10.179.64.227 rack1 Up Normal 70.02 KB33.33%
-3074457345618258603
10.179.111.137 rack1 Up Normal 45.96 KB33.33%
3074457345618258602
10.179.65.102 rack1 Up Normal 57.91 KB33.33%
-9223372036854775808
{noformat}
The middle address has one more character in the third quad, so it is offset by
one.
> Fix nodetool ring and status output format for IPv6 addresses
> -
>
> Key: CASSANDRA-5302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5302
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Michał Michalski
>Assignee: Michał Michalski
>Priority: Trivial
> Attachments: 5302.patch
>
>
> My pedantic nature can't stand having unaligned columns in nodetool outputs,
> which happens when IP addresses are IPv6 ones:
> {noformat}michal@aperture$ nodetool -h myhost status
> Datacenter: DC1
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Owns (effective) Host ID
>TokenRack
> UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
> d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
> rack2
> UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
> 0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
> rack1
> {noformat}
> I'm attaching a patch that fixes this problem for nodetool status / ring
> commands. It does it by picking first item in nodes list (for nodetool ring
> it's first node in general, for nodetool status it's first node in each DC)
> and uses its length as a field length for output.
> It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC
> and the lenghts of addresses are "similar". The alternative I'm considering
> too is finding the longest address - it will be 100% accurate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5304) Support 2ndary indexed columns in UPDATE and DELETE
[ https://issues.apache.org/jira/browse/CASSANDRA-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5304: Summary: Support 2ndary indexed columns in UPDATE and DELETE (was: Clarify error message when delete predicate does not specify the PK) > Support 2ndary indexed columns in UPDATE and DELETE > --- > > Key: CASSANDRA-5304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5304 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.2 >Reporter: Joachim Haagen Skeie >Priority: Minor > > I have a Column Family with the following index: > CREATE INDEX live_stat_is_calculated ON live_statistics (iscalculated) > Then, I would like to delete records based on this index via CQL3 query: > delete from live_statistics where iscalculated = true; > But Cassandra returns the following error: > PRIMARY KEY part iscalculated found in SET part -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-5310) New authentication module does not wok in multi datacenters in case of network outage
[ https://issues.apache.org/jira/browse/CASSANDRA-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko reassigned CASSANDRA-5310: Assignee: Aleksey Yeschenko > New authentication module does not wok in multi datacenters in case of > network outage > - > > Key: CASSANDRA-5310 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5310 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.2 > Environment: Ubuntu 12.04 > Cluster of 16 nodes in 2 datacenters (8 nodes in each datacenter) >Reporter: jal >Assignee: Aleksey Yeschenko > > With 1.2.2, I am using the new authentication backend PasswordAuthenticator > with the authorizer CassandraAuthorizer > In case of network outage, we are no more able to connect to Cassandra. > Here is the error message we get when I want to connect through cqlsh: > Traceback (most recent call last): > File "./cqlsh", line 2262, in > main(*read_options(sys.argv[1:], os.environ)) > File "./cqlsh", line 2248, in main > display_float_precision=options.float_precision) > File "./cqlsh", line 483, in __init__ > cql_version=cqlver, transport=transport) > File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py", line > 143, in connect > File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py", > line 59, in __init__ > File "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/thrifteries.py", > line 157, in establish_connection > File > "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py", > line 455, in login > File > "./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py", > line 476, in recv_login > cql.cassandra.ttypes.AuthenticationException: > AuthenticationException(why='org.apache.cassandra.exceptions.UnavailableException: > Cannot achieve consistency level QUORUM') -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5304) Support 2ndary indexed columns in UPDATE and DELETE
[ https://issues.apache.org/jira/browse/CASSANDRA-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5304: Issue Type: Wish (was: Bug) > Support 2ndary indexed columns in UPDATE and DELETE > --- > > Key: CASSANDRA-5304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5304 > Project: Cassandra > Issue Type: Wish > Components: Core >Affects Versions: 1.2.2 >Reporter: Joachim Haagen Skeie >Priority: Minor > > I have a Column Family with the following index: > CREATE INDEX live_stat_is_calculated ON live_statistics (iscalculated) > Then, I would like to delete records based on this index via CQL3 query: > delete from live_statistics where iscalculated = true; > But Cassandra returns the following error: > PRIMARY KEY part iscalculated found in SET part -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5304) Support 2ndary indexed columns in UPDATE and DELETE
[ https://issues.apache.org/jira/browse/CASSANDRA-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592381#comment-13592381 ] Sylvain Lebresne commented on CASSANDRA-5304: - Sorry, I'm changing the title of this back because I told Joachim to create that ticket and I wasn't thinking of the error message. Namely, we don't support 2ndary indexed columns in UPDATE and DELETE where clauses, and I believe that's a legit feature request. Do we want to implement it is another question. We could do it slightly more efficiently than what use can do today (by reading first, then updating/deleting second) as we could push that to the replica directly (hence saving round-trips, and not just between client and server, but internally too). That being said, it would hairy to implement and while it would be faster than doing it client side, it wouldn't be order of magnitude faster either, so maybe it's better to let user do it client-side and be aware of what that involves. Nonetheless, even if we close as won't fix for those reasons, I wanted to have the issue here as public record, because I suspect this is a feature request that might come back. As for the error message itself, I'm happy to ninja-fix it, except that from reading the code I have no clue how a delete query could have sent you this error message. The error message you should have gotten is "Non PRIMARY KEY iscalculated found in where clause", which is at least true (if not very explanatory). Are you sure a delete give you that error message? > Support 2ndary indexed columns in UPDATE and DELETE > --- > > Key: CASSANDRA-5304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5304 > Project: Cassandra > Issue Type: Wish > Components: Core >Affects Versions: 1.2.2 >Reporter: Joachim Haagen Skeie >Priority: Minor > > I have a Column Family with the following index: > CREATE INDEX live_stat_is_calculated ON live_statistics (iscalculated) > Then, I would like to delete records based on this index via CQL3 query: > delete from live_statistics where iscalculated = true; > But Cassandra returns the following error: > PRIMARY KEY part iscalculated found in SET part -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Add netty to pom dependencies
Updated Branches: refs/heads/cassandra-1.2 ef574569a -> 3c6f87eed Add netty to pom dependencies patch by slebresne; reviewed by dbrosius for CASSANDRA-5181 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3c6f87ee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3c6f87ee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3c6f87ee Branch: refs/heads/cassandra-1.2 Commit: 3c6f87eed334c56c4103fb883abf2f0c962b422c Parents: ef57456 Author: Sylvain Lebresne Authored: Mon Mar 4 18:25:45 2013 +0100 Committer: Sylvain Lebresne Committed: Mon Mar 4 18:25:45 2013 +0100 -- CHANGES.txt |1 + build.xml |1 + 2 files changed, 2 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c6f87ee/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c1ae2b9..bd7bf09 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -8,6 +8,7 @@ (CASSANDRA-5300) * Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285) * Handle null values when executing prepared statement (CASSANDRA-5081) + * Add netty to pom dependencies (CASSANDRA-5181) Merged from 1.1: * nodetool: ability to repair specific range (CASSANDRA-5280) * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284) http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c6f87ee/build.xml -- diff --git a/build.xml b/build.xml index 1fd2bf9..1ab9c94 100644 --- a/build.xml +++ b/build.xml @@ -380,6 +380,7 @@ +
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches:
refs/heads/trunk 25a31be4f -> 306a565a4
Merge branch 'cassandra-1.2' into trunk
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/306a565a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/306a565a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/306a565a
Branch: refs/heads/trunk
Commit: 306a565a4e3bf41d52958a7924f47834a1e0206d
Parents: 25a31be 3c6f87e
Author: Sylvain Lebresne
Authored: Mon Mar 4 18:26:44 2013 +0100
Committer: Sylvain Lebresne
Committed: Mon Mar 4 18:26:44 2013 +0100
--
CHANGES.txt|2 +
build.xml |1 +
src/java/org/apache/cassandra/cql3/Constants.java | 20 ++--
src/java/org/apache/cassandra/cql3/Lists.java | 18 ++-
src/java/org/apache/cassandra/cql3/Maps.java | 15 -
src/java/org/apache/cassandra/cql3/Sets.java |7 ++-
.../cassandra/cql3/functions/FunctionCall.java |9 +++-
.../cassandra/cql3/statements/SelectStatement.java | 40 --
.../cassandra/cql3/statements/UpdateStatement.java | 15 -
9 files changed, 105 insertions(+), 22 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/306a565a/CHANGES.txt
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/306a565a/build.xml
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/306a565a/src/java/org/apache/cassandra/cql3/Constants.java
--
diff --cc src/java/org/apache/cassandra/cql3/Constants.java
index 896bd94,f630869..9904f05
--- a/src/java/org/apache/cassandra/cql3/Constants.java
+++ b/src/java/org/apache/cassandra/cql3/Constants.java
@@@ -277,9 -295,12 +280,12 @@@ public abstract class Constant
public void execute(ByteBuffer rowKey, ColumnFamily cf,
ColumnNameBuilder prefix, UpdateParameters params) throws
InvalidRequestException
{
- long increment =
ByteBufferUtil.toLong(t.bindAndGet(params.variables));
+ ByteBuffer bytes = t.bindAndGet(params.variables);
+ if (bytes == null)
+ throw new InvalidRequestException("Invalid null value for
counter increment");
+ long increment = ByteBufferUtil.toLong(bytes);
ByteBuffer cname = columnName == null ? prefix.build() :
prefix.add(columnName.key).build();
-cf.addCounter(new QueryPath(cf.metadata().cfName, null, cname),
increment);
+cf.addCounter(cname, increment);
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/306a565a/src/java/org/apache/cassandra/cql3/Lists.java
--
diff --cc src/java/org/apache/cassandra/cql3/Lists.java
index 3eab387,76f947c..caa84b4
--- a/src/java/org/apache/cassandra/cql3/Lists.java
+++ b/src/java/org/apache/cassandra/cql3/Lists.java
@@@ -368,9 -377,12 +377,12 @@@ public abstract class List
public void execute(ByteBuffer rowKey, ColumnFamily cf,
ColumnNameBuilder prefix, UpdateParameters params) throws
InvalidRequestException
{
Term.Terminal index = t.bind(params.variables);
+ if (index == null)
+ throw new InvalidRequestException("Invalid null value for
list index");
+
assert index instanceof Constants.Value;
-List> existingList =
params.getPrefetchedList(rowKey, columnName.key);
+List> existingList =
params.getPrefetchedList(rowKey, columnName.key);
int idx = ByteBufferUtil.toInt(((Constants.Value)index).bytes);
if (idx < 0 || idx >= existingList.size())
throw new InvalidRequestException(String.format("List index
%d out of bound, list has size %d", idx, existingList.size()));
http://git-wip-us.apache.org/repos/asf/cassandra/blob/306a565a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/306a565a/src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java
--
[1/3] git commit: Support null values in PreparedStatements parameters
Support null values in PreparedStatements parameters
patch by slebresne; reviewed by iamaleksey for CASSANDRA-5081
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef574569
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef574569
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef574569
Branch: refs/heads/trunk
Commit: ef574569a23d33e18c3d9893a323a891a96215db
Parents: 3a3f1d9
Author: Sylvain Lebresne
Authored: Mon Mar 4 17:58:16 2013 +0100
Committer: Sylvain Lebresne
Committed: Mon Mar 4 17:58:16 2013 +0100
--
CHANGES.txt|1 +
src/java/org/apache/cassandra/cql3/Constants.java | 20 ++--
src/java/org/apache/cassandra/cql3/Lists.java | 18 ++-
src/java/org/apache/cassandra/cql3/Maps.java | 15 -
src/java/org/apache/cassandra/cql3/Sets.java |7 ++-
.../cassandra/cql3/functions/FunctionCall.java |9 +++-
.../cassandra/cql3/statements/SelectStatement.java | 40 --
.../cassandra/cql3/statements/UpdateStatement.java | 15 -
8 files changed, 103 insertions(+), 22 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef574569/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a6b2cff..c1ae2b9 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -7,6 +7,7 @@
* Fix insufficient validation of UPDATE queries against counter cfs
(CASSANDRA-5300)
* Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285)
+ * Handle null values when executing prepared statement (CASSANDRA-5081)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef574569/src/java/org/apache/cassandra/cql3/Constants.java
--
diff --git a/src/java/org/apache/cassandra/cql3/Constants.java
b/src/java/org/apache/cassandra/cql3/Constants.java
index 60098be..f630869 100644
--- a/src/java/org/apache/cassandra/cql3/Constants.java
+++ b/src/java/org/apache/cassandra/cql3/Constants.java
@@ -254,7 +254,8 @@ public abstract class Constants
try
{
ByteBuffer value = values.get(bindIndex);
-receiver.type.validate(value);
+if (value != null)
+receiver.type.validate(value);
return value;
}
catch (MarshalException e)
@@ -265,7 +266,8 @@ public abstract class Constants
public Value bind(List values) throws
InvalidRequestException
{
-return new Constants.Value(bindAndGet(values));
+ByteBuffer bytes = bindAndGet(values);
+return bytes == null ? null : new Constants.Value(bytes);
}
}
@@ -279,7 +281,8 @@ public abstract class Constants
public void execute(ByteBuffer rowKey, ColumnFamily cf,
ColumnNameBuilder prefix, UpdateParameters params) throws
InvalidRequestException
{
ByteBuffer cname = columnName == null ? prefix.build() :
prefix.add(columnName.key).build();
-cf.addColumn(params.makeColumn(cname,
t.bindAndGet(params.variables)));
+ByteBuffer value = t.bindAndGet(params.variables);
+cf.addColumn(value == null ? params.makeTombstone(cname) :
params.makeColumn(cname, value));
}
}
@@ -292,7 +295,10 @@ public abstract class Constants
public void execute(ByteBuffer rowKey, ColumnFamily cf,
ColumnNameBuilder prefix, UpdateParameters params) throws
InvalidRequestException
{
-long increment =
ByteBufferUtil.toLong(t.bindAndGet(params.variables));
+ByteBuffer bytes = t.bindAndGet(params.variables);
+if (bytes == null)
+throw new InvalidRequestException("Invalid null value for
counter increment");
+long increment = ByteBufferUtil.toLong(bytes);
ByteBuffer cname = columnName == null ? prefix.build() :
prefix.add(columnName.key).build();
cf.addCounter(new QueryPath(cf.metadata().cfName, null, cname),
increment);
}
@@ -307,7 +313,11 @@ public abstract class Constants
public void execute(ByteBuffer rowKey, ColumnFamily cf,
ColumnNameBuilder prefix, UpdateParameters params) throws
InvalidRequestException
{
-long increment =
ByteBufferUtil.toLong(t.bindAndGet(params.variables));
+ByteBuffer bytes = t.bindAndGet(params.variables);
+if (bytes == null)
+throw new InvalidRequestException("Invalid null value for
counter incre
[2/3] git commit: Add netty to pom dependencies
Add netty to pom dependencies patch by slebresne; reviewed by dbrosius for CASSANDRA-5181 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3c6f87ee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3c6f87ee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3c6f87ee Branch: refs/heads/trunk Commit: 3c6f87eed334c56c4103fb883abf2f0c962b422c Parents: ef57456 Author: Sylvain Lebresne Authored: Mon Mar 4 18:25:45 2013 +0100 Committer: Sylvain Lebresne Committed: Mon Mar 4 18:25:45 2013 +0100 -- CHANGES.txt |1 + build.xml |1 + 2 files changed, 2 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c6f87ee/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index c1ae2b9..bd7bf09 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -8,6 +8,7 @@ (CASSANDRA-5300) * Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285) * Handle null values when executing prepared statement (CASSANDRA-5081) + * Add netty to pom dependencies (CASSANDRA-5181) Merged from 1.1: * nodetool: ability to repair specific range (CASSANDRA-5280) * Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284) http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c6f87ee/build.xml -- diff --git a/build.xml b/build.xml index 1fd2bf9..1ab9c94 100644 --- a/build.xml +++ b/build.xml @@ -380,6 +380,7 @@ +
[jira] [Resolved] (CASSANDRA-5181) cassandra-all 1.2.0 pom missing netty dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-5181. - Resolution: Fixed Fix Version/s: 1.2.3 Committed, thanks > cassandra-all 1.2.0 pom missing netty dependency > > > Key: CASSANDRA-5181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5181 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Affects Versions: 1.2.0 >Reporter: Carl Lerche >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.2.3 > > Attachments: 5181.txt > > > It seems that cassandra depends on netty now, however the pom excludes this > dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5311) Thrift CQLPreparedResult don't include type arguments (for collection in particular)
Sylvain Lebresne created CASSANDRA-5311: --- Summary: Thrift CQLPreparedResult don't include type arguments (for collection in particular) Key: CASSANDRA-5311 URL: https://issues.apache.org/jira/browse/CASSANDRA-5311 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3753) Update CqlPreparedResult to provide type information
[ https://issues.apache.org/jira/browse/CASSANDRA-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592391#comment-13592391 ] Sylvain Lebresne commented on CASSANDRA-3753: - I've created CASSANDRA-5311 for this instead, this ticket has been closed for a while. > Update CqlPreparedResult to provide type information > > > Key: CASSANDRA-3753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3753 > Project: Cassandra > Issue Type: Improvement > Components: API >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne >Priority: Critical > Labels: cql > Fix For: 1.1.0 > > Attachments: 0001-3753-cql3.patch, 0002-Thrift-gen-file-changes.patch > > > As discussed on CASSANDRA-3634, adding type information to a prepared > statement would allow more client-side error checking. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5311) Thrift CQLPreparedResult don't include type arguments (for collection in particular)
[ https://issues.apache.org/jira/browse/CASSANDRA-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5311: Attachment: 5311.txt Trivial patch attached. > Thrift CQLPreparedResult don't include type arguments (for collection in > particular) > > > Key: CASSANDRA-5311 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5311 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.2.3 > > Attachments: 5311.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4795) replication, compaction, compression? options are not validated
[ https://issues.apache.org/jira/browse/CASSANDRA-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592395#comment-13592395 ] Jonathan Ellis commented on CASSANDRA-4795: --- bq. I'm fine with those To clarify, is that "I'm fine in principle" or "I've reviewed it, +1?" > replication, compaction, compression? options are not validated > --- > > Key: CASSANDRA-4795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4795 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Brandon Williams >Assignee: Dave Brosius >Priority: Minor > Fix For: 1.2.1 > > Attachments: 0001-Reallow-unexpected-strategy-options-for-thrift.txt, > 0002-Reallow-unexpected-strategy-options-for-thrift.txt, > 0003-Adds-application_metadata-field-to-ks-metadata.txt, > 4795.compaction_strategy.txt, 4795_compaction_strategy_v2.txt, > 4795_compaction_strategy_v3.txt, 4795.replication_strategy.txt > > > When creating a keyspace and specifying strategy options, you can pass any > k/v pair you like. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5311) Thrift CQLPreparedResult don't include type arguments (for collection in particular)
[ https://issues.apache.org/jira/browse/CASSANDRA-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592398#comment-13592398 ] Jonathan Ellis commented on CASSANDRA-5311: --- +1 > Thrift CQLPreparedResult don't include type arguments (for collection in > particular) > > > Key: CASSANDRA-5311 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5311 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.2.3 > > Attachments: 5311.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "AngeloHam" by AngeloHam
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "AngeloHam" page has been changed by AngeloHam: http://wiki.apache.org/cassandra/AngeloHam New page: I am staying at Riverside. This autumun iam going to be 27.<> I have a job as Linguist.<> <> Here is my blog [[http://www.dressesd.com|wedding dresses 2013]]
git commit: Thrift CQLPreparedResult don't include type arguments
Updated Branches:
refs/heads/cassandra-1.2 3c6f87eed -> b7e10828f
Thrift CQLPreparedResult don't include type arguments
patch by slebresne; reviewed by jbellis for CASSANDRA-5311
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b7e10828
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b7e10828
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b7e10828
Branch: refs/heads/cassandra-1.2
Commit: b7e10828fb4ec14ffebfd7b60775ea8844438542
Parents: 3c6f87e
Author: Sylvain Lebresne
Authored: Mon Mar 4 18:55:59 2013 +0100
Committer: Sylvain Lebresne
Committed: Mon Mar 4 18:55:59 2013 +0100
--
CHANGES.txt|1 +
.../transport/messages/ResultMessage.java |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b7e10828/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bd7bf09..04dcee7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,7 @@
* Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285)
* Handle null values when executing prepared statement (CASSANDRA-5081)
* Add netty to pom dependencies (CASSANDRA-5181)
+ * Include type arguments in Thrift CQLPreparedResult (CASSANDRA-5311)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b7e10828/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
--
diff --git
a/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
b/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
index 57ba7dd..43caace 100644
--- a/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
+++ b/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
@@ -294,7 +294,7 @@ public abstract class ResultMessage extends Message.Response
for (ColumnSpecification name : metadata.names)
{
namesString.add(name.toString());
-typesString.add(TypeParser.getShortName(name.type));
+typesString.add(name.type.toString());
}
return new CqlPreparedResult(thriftStatementId,
metadata.names.size()).setVariable_types(typesString).setVariable_names(namesString);
}
[jira] [Commented] (CASSANDRA-3783) Add 'null' support to CQL 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592416#comment-13592416
]
Sylvain Lebresne commented on CASSANDRA-3783:
-
bq. Could the "insert null" command behaves like a batch mutation ?
I'm not really sure what you mean here. For normal columns (the only ones we
should care about in this ticket really), setting to null really mean deleting
the column. There is no difficulty in doing that. But for collections, if there
is no column internally, there is no element (even for lists, the internal
column representing each element does not include the element index; that's why
operation like 'setting by index' needs to read the full list, so it can find
the element at the requested index by counting them), so we do need to have a
column, but his "value" should mean "null".
> Add 'null' support to CQL 3.0
> -
>
> Key: CASSANDRA-3783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3783
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Reporter: Sylvain Lebresne
>Assignee: Michał Michalski
>Priority: Minor
> Labels: cql3
> Fix For: 1.2.3
>
> Attachments: 3783-v2.patch, 3783-wip-v1.patch
>
>
> Dense composite supports adding records where only a prefix of all the
> component specifying the key is defined. In other words, with:
> {noformat}
> CREATE TABLE connections (
>userid int,
>ip text,
>port int,
>protocol text,
>time timestamp,
>PRIMARY KEY (userid, ip, port, protocol)
> ) WITH COMPACT STORAGE
> {noformat}
> you can insert
> {noformat}
> INSERT INTO connections (userid, ip, port, time) VALUES (2, '192.168.0.1',
> 80, 123456789);
> {noformat}
> You cannot however select that column specifically (i.e, without selecting
> column (2, '192.168.0.1', 80, 'http') for instance).
> This ticket proposes to allow that though 'null', i.e. to allow
> {noformat}
> SELECT * FROM connections WHERE userid = 2 AND ip = '192.168.0.1' AND port =
> 80 AND protocol = null;
> {noformat}
> It would then also make sense to support:
> {noformat}
> INSERT INTO connections (userid, ip, port, protocol, time) VALUES (2,
> '192.168.0.1', 80, null, 123456789);
> {noformat}
> as an equivalent to the insert query above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3783) Add 'null' support to CQL 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592418#comment-13592418
]
Sylvain Lebresne commented on CASSANDRA-3783:
-
As for the attached patch, I'm sorry I haven't had time to get to it yet, but I
committed CASSSANDRA-5081, and I'm pretty sure some rebase has to happen.
> Add 'null' support to CQL 3.0
> -
>
> Key: CASSANDRA-3783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3783
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Reporter: Sylvain Lebresne
>Assignee: Michał Michalski
>Priority: Minor
> Labels: cql3
> Fix For: 1.2.3
>
> Attachments: 3783-v2.patch, 3783-wip-v1.patch
>
>
> Dense composite supports adding records where only a prefix of all the
> component specifying the key is defined. In other words, with:
> {noformat}
> CREATE TABLE connections (
>userid int,
>ip text,
>port int,
>protocol text,
>time timestamp,
>PRIMARY KEY (userid, ip, port, protocol)
> ) WITH COMPACT STORAGE
> {noformat}
> you can insert
> {noformat}
> INSERT INTO connections (userid, ip, port, time) VALUES (2, '192.168.0.1',
> 80, 123456789);
> {noformat}
> You cannot however select that column specifically (i.e, without selecting
> column (2, '192.168.0.1', 80, 'http') for instance).
> This ticket proposes to allow that though 'null', i.e. to allow
> {noformat}
> SELECT * FROM connections WHERE userid = 2 AND ip = '192.168.0.1' AND port =
> 80 AND protocol = null;
> {noformat}
> It would then also make sense to support:
> {noformat}
> INSERT INTO connections (userid, ip, port, protocol, time) VALUES (2,
> '192.168.0.1', 80, null, 123456789);
> {noformat}
> as an equivalent to the insert query above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "Ivory4390" by Ivory4390
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Ivory4390" page has been changed by Ivory4390: http://wiki.apache.org/cassandra/Ivory4390 New page: Howdy !! The name is JEANNETTE REEVES. I am staying at Howell.<> <> I am planning to become a Linesman. One day i would want to do Organic Gardening. My papa name is Gregory and he is a Manufacturer. My mummy is a Real estate agent.<> <> My web site: [[http://www.chanelbagsbuild.com|chanel bags]]
git commit: Add tool to reset SSTable level; patch by Marcus Eriksson, reviewed by yukim for CASSANDRA-5271
Updated Branches:
refs/heads/trunk 306a565a4 -> 6d5e0831a
Add tool to reset SSTable level; patch by Marcus Eriksson, reviewed by yukim
for CASSANDRA-5271
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6d5e0831
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6d5e0831
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6d5e0831
Branch: refs/heads/trunk
Commit: 6d5e0831a42541a3ce4b1bac32d1285fb1004241
Parents: 306a565
Author: Marcus Eriksson
Authored: Mon Mar 4 11:46:51 2013 -0600
Committer: Yuki Morishita
Committed: Mon Mar 4 12:08:51 2013 -0600
--
CHANGES.txt|1 +
debian/cassandra.install |2 +
.../cassandra/tools/SSTableLevelResetter.java | 80 +++
tools/bin/sstablelevelreset| 49 +
4 files changed, 132 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5e0831/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 720d76f..c71db7b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* drop unnecessary keyspace from user-defined compaction API (CASSANDRA-5139)
* more robust solution to incomplete compactions + counters (CASSANDRA-5151)
* Change order of directory searching for c*.in.sh (CASSANDRA-3983)
+ * Add tool to reset SSTable level (CASSANDRA-5271)
1.2.3
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5e0831/debian/cassandra.install
--
diff --git a/debian/cassandra.install b/debian/cassandra.install
index 6fa84ce..56d6bf3 100644
--- a/debian/cassandra.install
+++ b/debian/cassandra.install
@@ -17,6 +17,8 @@ bin/sstablescrub usr/bin
bin/cassandra-shuffle usr/bin
tools/bin/cassandra-stress usr/bin
tools/bin/token-generator usr/bin
+tools/bin/sstablelevelreset usr/bin
+tools/bin/sstablemetadata usr/bin
lib/*.jar usr/share/cassandra/lib
lib/*.zip usr/share/cassandra/lib
lib/licenses usr/share/doc/cassandra
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5e0831/src/java/org/apache/cassandra/tools/SSTableLevelResetter.java
--
diff --git a/src/java/org/apache/cassandra/tools/SSTableLevelResetter.java
b/src/java/org/apache/cassandra/tools/SSTableLevelResetter.java
new file mode 100644
index 000..7fe8059
--- /dev/null
+++ b/src/java/org/apache/cassandra/tools/SSTableLevelResetter.java
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.tools;
+
+import java.io.IOException;
+import java.io.PrintStream;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+
+import org.apache.cassandra.db.Directories;
+import org.apache.cassandra.db.compaction.LeveledManifest;
+import org.apache.cassandra.io.sstable.Component;
+import org.apache.cassandra.io.sstable.Descriptor;
+import org.apache.cassandra.io.sstable.SSTableMetadata;
+import org.apache.cassandra.io.sstable.SSTableReader;
+
+/**
+ * Reset level to 0 on a given set of sstables
+ */
+public class SSTableLevelResetter
+{
+/**
+ * @param args a list of sstables whose metadata we are changing
+ */
+public static void main(String[] args) throws IOException
+{
+PrintStream out = System.out;
+if (args.length == 0)
+{
+out.println("This command should be run with Cassandra stopped!");
+out.println("Usage: sstablelevelreset ");
+System.exit(1);
+}
+
+if (!args[0].equals("--really-reset") || args.length != 3)
+{
+out.println("This command should be run with Cassandra stopped,
otherwise you will get very strange behavior");
+out.println("Verify that Cassandra is not running and then execute
the command like this:");
+out.println("Usage: sstablelevelreset --
[Cassandra Wiki] Trivial Update of "Nigel61D" by Nigel61D
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Nigel61D" page has been changed by Nigel61D: http://wiki.apache.org/cassandra/Nigel61D New page: I have a house in Saginaw. This may i will be 26.<> I am working as Matador.<> <> Look into my website - [[http://www.dressesd.com|cheap wedding dresses]]
[jira] [Commented] (CASSANDRA-5279) Provide a nodetool command to close stream sessions
[ https://issues.apache.org/jira/browse/CASSANDRA-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592489#comment-13592489 ] Yuki Morishita commented on CASSANDRA-5279: --- So, thinking this over again, I got the feeling that this is not the right way to do. First, right now there is no way to tell that the stream session is initiated by which operation. We need major redesign and that's what we should do in next streaming 2.0 (CASSANDRA-5286). Second, we should control(start/stop/resume?) at operation level, not at stream session level. Usually operations consist of several streams and killing one of them causes entire operation to fail anyway. So I'm leaning toward won't fixing this. > Provide a nodetool command to close stream sessions > > > Key: CASSANDRA-5279 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5279 > Project: Cassandra > Issue Type: Improvement > Components: Core, Tools >Affects Versions: 1.1.9 >Reporter: Ahmed Bashir >Assignee: Yuki Morishita > > It would be quite useful to be able to close stream sessions (derived from > AbstractStreamSession) via nodetool. > This could be done in total or by session ID (all stream sessions have an ID). > Stream sessions can be long-running, cause load on the network, send a very > large amount of data to endpoints, and trigger large amount of pending > compaction tasks. Just like we make it possible to cancel compaction, it is > very useful to be able to close these sessions via nodetool (close() is if > such sessions are affecting cluster stability (which they can) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "MilfordGu" by MilfordGu
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "MilfordGu" page has been changed by MilfordGu: http://wiki.apache.org/cassandra/MilfordGu New page: Hello !! I am STEPHINE BURKE. I am turning 27. I am taking admission in The Better Boarding School located in Columbus.<> I am self employed as a Footman. My papa name is Joseph and he is a Dressmaker. My mother is a Organizer.<> <> Also visit my web site ... [[http://www.majorchanelbags.com|chanel handbags]]
[3/4] git commit: Fix compaction not removing columns when bf_fp_ratio is 1; patch by yukim, reviewed by jbellis and pcmanus for CASSANDRA-5182
Fix compaction not removing columns when bf_fp_ratio is 1; patch by yukim,
reviewed by jbellis and pcmanus for CASSANDRA-5182
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6415d6be
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6415d6be
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6415d6be
Branch: refs/heads/cassandra-1.2
Commit: 6415d6bee2815e9267cae002bf873fce8073b347
Parents: b7e1082
Author: Yuki Morishita
Authored: Tue Feb 5 13:09:06 2013 -0600
Committer: Yuki Morishita
Committed: Mon Mar 4 13:35:56 2013 -0600
--
CHANGES.txt|1 +
.../db/compaction/CompactionController.java| 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6415d6be/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04dcee7..924eeeb 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* Handle null values when executing prepared statement (CASSANDRA-5081)
* Add netty to pom dependencies (CASSANDRA-5181)
* Include type arguments in Thrift CQLPreparedResult (CASSANDRA-5311)
+ * Fix compaction not removing columns when bf_fp_ratio is 1 (CASSANDRA-5182)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6415d6be/src/java/org/apache/cassandra/db/compaction/CompactionController.java
--
diff --git
a/src/java/org/apache/cassandra/db/compaction/CompactionController.java
b/src/java/org/apache/cassandra/db/compaction/CompactionController.java
index ff3de53..f3198ff 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionController.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionController.java
@@ -34,6 +34,7 @@ import
org.apache.cassandra.io.sstable.SSTableIdentityIterator;
import org.apache.cassandra.io.sstable.SSTableReader;
import org.apache.cassandra.service.CacheService;
import org.apache.cassandra.service.StorageService;
+import org.apache.cassandra.utils.AlwaysPresentFilter;
import org.apache.cassandra.utils.Throttle;
/**
@@ -114,8 +115,15 @@ public class CompactionController
List filteredSSTables = overlappingTree.search(key);
for (SSTableReader sstable : filteredSSTables)
{
-if (sstable.getBloomFilter().isPresent(key.key) &&
sstable.getMinTimestamp() <= maxDeletionTimestamp)
-return false;
+if (sstable.getMinTimestamp() <= maxDeletionTimestamp)
+{
+// if we don't have bloom filter(bf_fp_chance=1.0 or filter
file is missing),
+// we check index file instead.
+if (sstable.getBloomFilter() instanceof AlwaysPresentFilter &&
sstable.getPosition(key, SSTableReader.Operator.EQ) != null)
+return false;
+else if (sstable.getBloomFilter().isPresent(key.key))
+return false;
+}
}
return true;
}
[4/4] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/cassandra-1.2 b7e10828f -> 6415d6bee refs/heads/trunk 6d5e0831a -> 881429ff8 Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/881429ff Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/881429ff Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/881429ff Branch: refs/heads/trunk Commit: 881429ff8927a0ed6009542d6d03f07b19b76318 Parents: 6d5e083 6415d6b Author: Yuki Morishita Authored: Mon Mar 4 13:36:08 2013 -0600 Committer: Yuki Morishita Committed: Mon Mar 4 13:36:08 2013 -0600 -- CHANGES.txt|2 ++ .../db/compaction/CompactionController.java| 12 ++-- .../transport/messages/ResultMessage.java |2 +- 3 files changed, 13 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/881429ff/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/881429ff/src/java/org/apache/cassandra/db/compaction/CompactionController.java --
[2/4] git commit: Fix compaction not removing columns when bf_fp_ratio is 1; patch by yukim, reviewed by jbellis and pcmanus for CASSANDRA-5182
Fix compaction not removing columns when bf_fp_ratio is 1; patch by yukim,
reviewed by jbellis and pcmanus for CASSANDRA-5182
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6415d6be
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6415d6be
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6415d6be
Branch: refs/heads/trunk
Commit: 6415d6bee2815e9267cae002bf873fce8073b347
Parents: b7e1082
Author: Yuki Morishita
Authored: Tue Feb 5 13:09:06 2013 -0600
Committer: Yuki Morishita
Committed: Mon Mar 4 13:35:56 2013 -0600
--
CHANGES.txt|1 +
.../db/compaction/CompactionController.java| 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6415d6be/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04dcee7..924eeeb 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* Handle null values when executing prepared statement (CASSANDRA-5081)
* Add netty to pom dependencies (CASSANDRA-5181)
* Include type arguments in Thrift CQLPreparedResult (CASSANDRA-5311)
+ * Fix compaction not removing columns when bf_fp_ratio is 1 (CASSANDRA-5182)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6415d6be/src/java/org/apache/cassandra/db/compaction/CompactionController.java
--
diff --git
a/src/java/org/apache/cassandra/db/compaction/CompactionController.java
b/src/java/org/apache/cassandra/db/compaction/CompactionController.java
index ff3de53..f3198ff 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionController.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionController.java
@@ -34,6 +34,7 @@ import
org.apache.cassandra.io.sstable.SSTableIdentityIterator;
import org.apache.cassandra.io.sstable.SSTableReader;
import org.apache.cassandra.service.CacheService;
import org.apache.cassandra.service.StorageService;
+import org.apache.cassandra.utils.AlwaysPresentFilter;
import org.apache.cassandra.utils.Throttle;
/**
@@ -114,8 +115,15 @@ public class CompactionController
List filteredSSTables = overlappingTree.search(key);
for (SSTableReader sstable : filteredSSTables)
{
-if (sstable.getBloomFilter().isPresent(key.key) &&
sstable.getMinTimestamp() <= maxDeletionTimestamp)
-return false;
+if (sstable.getMinTimestamp() <= maxDeletionTimestamp)
+{
+// if we don't have bloom filter(bf_fp_chance=1.0 or filter
file is missing),
+// we check index file instead.
+if (sstable.getBloomFilter() instanceof AlwaysPresentFilter &&
sstable.getPosition(key, SSTableReader.Operator.EQ) != null)
+return false;
+else if (sstable.getBloomFilter().isPresent(key.key))
+return false;
+}
}
return true;
}
[1/4] git commit: Thrift CQLPreparedResult don't include type arguments
Thrift CQLPreparedResult don't include type arguments
patch by slebresne; reviewed by jbellis for CASSANDRA-5311
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b7e10828
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b7e10828
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b7e10828
Branch: refs/heads/trunk
Commit: b7e10828fb4ec14ffebfd7b60775ea8844438542
Parents: 3c6f87e
Author: Sylvain Lebresne
Authored: Mon Mar 4 18:55:59 2013 +0100
Committer: Sylvain Lebresne
Committed: Mon Mar 4 18:55:59 2013 +0100
--
CHANGES.txt|1 +
.../transport/messages/ResultMessage.java |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b7e10828/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bd7bf09..04dcee7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,7 @@
* Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285)
* Handle null values when executing prepared statement (CASSANDRA-5081)
* Add netty to pom dependencies (CASSANDRA-5181)
+ * Include type arguments in Thrift CQLPreparedResult (CASSANDRA-5311)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b7e10828/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
--
diff --git
a/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
b/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
index 57ba7dd..43caace 100644
--- a/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
+++ b/src/java/org/apache/cassandra/transport/messages/ResultMessage.java
@@ -294,7 +294,7 @@ public abstract class ResultMessage extends Message.Response
for (ColumnSpecification name : metadata.names)
{
namesString.add(name.toString());
-typesString.add(TypeParser.getShortName(name.type));
+typesString.add(name.type.toString());
}
return new CqlPreparedResult(thriftStatementId,
metadata.names.size()).setVariable_types(typesString).setVariable_names(namesString);
}
[jira] [Commented] (CASSANDRA-4993) Add binary protocol support to stress
[ https://issues.apache.org/jira/browse/CASSANDRA-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592549#comment-13592549 ] Yuki Morishita commented on CASSANDRA-4993: --- Sylvain, can you rebase? > Add binary protocol support to stress > - > > Key: CASSANDRA-4993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4993 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Minor > Attachments: 0001-Add-native-support-to-stress.txt > > > Attaching a patch adding the option to stress to use the binary protocol. > This is a bit of a hack (for instance, for inserts, the schema is still > created using a thrift connection), but it's the simpler/smallest change I > can come up with that allowa to compare thrift and the binary protocol. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5045) Add Configuration Loader to DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5045: Attachment: 5045_v3.txt Rebased version attached as v3, against trunk now (since at the point I think the 1.2 ship has sailed). > Add Configuration Loader to DatabaseDescriptor > -- > > Key: CASSANDRA-5045 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5045 > Project: Cassandra > Issue Type: New Feature >Reporter: Michael Guymon >Priority: Minor > Labels: patch > Attachments: > 0001-Add-configuration-loader-to-DatabaseDescriptor.patch, 5045-v2.txt, > 5045_v3.txt > > > Based on feed back from CASSANDRA-4998 - > Added IConfigurationLoader that is used to load an external Config. When the > System Property cassandra.config.loader is defined with an implementing > class, DatabaseDescriptor with will that Config over loading the > cassandra.yaml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592559#comment-13592559 ] Cristian Opris commented on CASSANDRA-5062: --- [~slebresne] I have read your pseudo-code, seems pretty much what I was trying to describe with the version counter that counts paxos rounds (except I was thinking at row level rather than column level) I noticed however that while the leader's proposal is aborted if it has a stale round, the acceptor algorithm does not handle the case when the acceptor replica is behind. Basically in the acceptor algorithm you don't seem to handle the case where C_current.timestamp() < R One way to do that is to nack the proposal indicating it needs to catch up and either expect to receive a "snapshot" from the leader or do a read. Also note you don't need to send the column values with proposal. If you get quorum for the proposal you can perform the CAS locally and just send the new column value. Essentially consensus is on the next column value to write, not the CAS. Since proposer is guaranteed to be up to date before sending accept, it can do the CAS locally. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure on builder cassandra-trunk while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/2396 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch trunk] 881429ff8927a0ed6009542d6d03f07b19b76318 Blamelist: Sylvain Lebresne ,Yuki Morishita BUILD FAILED: failed shell sincerely, -The Buildbot
[jira] [Comment Edited] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592559#comment-13592559 ] Cristian Opris edited comment on CASSANDRA-5062 at 3/4/13 7:48 PM: --- [~slebresne] I have read your pseudo-code, seems pretty much what I was trying to describe with the version counter that counts paxos rounds (except I was thinking at row level rather than column level) I noticed however that while the leader's proposal is aborted if it has a stale round, the acceptor algorithm does not handle the case when the acceptor replica is behind. Basically in the acceptor algorithm you don't seem to handle the case where C_current.timestamp() < R One way to do that is to nack the proposal indicating it needs to catch up and either expect to receive a "snapshot" from the leader or do a read. Also note you don't need to send the column values with the proposal. If you get quorum for the proposal you can perform the CAS locally and just send the new column value with the accept Essentially consensus is on the next column value to write, not the CAS. Since proposer is guaranteed to be up to date before sending accept, it can do the CAS locally. was (Author: onetoinfin...@yahoo.com): [~slebresne] I have read your pseudo-code, seems pretty much what I was trying to describe with the version counter that counts paxos rounds (except I was thinking at row level rather than column level) I noticed however that while the leader's proposal is aborted if it has a stale round, the acceptor algorithm does not handle the case when the acceptor replica is behind. Basically in the acceptor algorithm you don't seem to handle the case where C_current.timestamp() < R One way to do that is to nack the proposal indicating it needs to catch up and either expect to receive a "snapshot" from the leader or do a read. Also note you don't need to send the column values with proposal. If you get quorum for the proposal you can perform the CAS locally and just send the new column value. Essentially consensus is on the next column value to write, not the CAS. Since proposer is guaranteed to be up to date before sending accept, it can do the CAS locally. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592559#comment-13592559 ] Cristian Opris edited comment on CASSANDRA-5062 at 3/4/13 7:52 PM: --- [~slebresne] I have read your pseudo-code, seems pretty much what I was trying to describe with the version counter that counts paxos rounds (except I was thinking at row level rather than column level) I noticed however that while the leader's proposal is aborted if it has a stale round, the acceptor algorithm does not handle the case when the acceptor replica is behind. Basically in the acceptor algorithm you don't seem to handle the case where C_current.timestamp() < R-1 Edit: C_current.timestamp needs to be exactly R-1 if you increment the counter on sending the proposal. One way to do that is to nack the proposal indicating it needs to catch up and either expect to receive a "snapshot" from the leader or do a read. Also note you don't need to send the column values with the proposal. If you get quorum for the proposal you can perform the CAS locally and just send the new column value with the accept Essentially consensus is on the next column value to write, not the CAS. Since proposer is guaranteed to be up to date before sending accept, it can do the CAS locally. was (Author: onetoinfin...@yahoo.com): [~slebresne] I have read your pseudo-code, seems pretty much what I was trying to describe with the version counter that counts paxos rounds (except I was thinking at row level rather than column level) I noticed however that while the leader's proposal is aborted if it has a stale round, the acceptor algorithm does not handle the case when the acceptor replica is behind. Basically in the acceptor algorithm you don't seem to handle the case where C_current.timestamp() < R One way to do that is to nack the proposal indicating it needs to catch up and either expect to receive a "snapshot" from the leader or do a read. Also note you don't need to send the column values with the proposal. If you get quorum for the proposal you can perform the CAS locally and just send the new column value with the accept Essentially consensus is on the next column value to write, not the CAS. Since proposer is guaranteed to be up to date before sending accept, it can do the CAS locally. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592572#comment-13592572 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. Basically in the acceptor algorithm you don't seem to handle the case where C_current.timestamp() < R Note sure I follow. On the acceptor, if C_current.timestamp() < R, then it means the message if for a round that hasn't been decided yet (more precisely, that we haven't learned out). That's the case where we actually do some work (as the pseudo-code does really). bq. Also note you don't need to send the column values with proposal Not true. Even if a proposer has his value "accepted", there is not guarantee that it will be the one learning it, or even the only one learning it for that matter. For a given round, the value is decided as soon as a quorum of acceptor accepts it basically, irrelevant of whether the original proposer of that value gets the commit acks or not. bq. Essentially consensus is on the next column value to write Yes. As as discuss later in my brain dump, we'd likely want to support normal inserts at least. The actual operation is largely of irrelevant (that's why it's a blob in the paxos_state table :)). > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5045) Add Configuration Loader to DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592599#comment-13592599 ] Jason Brown commented on CASSANDRA-5045: v3 LGTM. > Add Configuration Loader to DatabaseDescriptor > -- > > Key: CASSANDRA-5045 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5045 > Project: Cassandra > Issue Type: New Feature >Reporter: Michael Guymon >Priority: Minor > Labels: patch > Attachments: > 0001-Add-configuration-loader-to-DatabaseDescriptor.patch, 5045-v2.txt, > 5045_v3.txt > > > Based on feed back from CASSANDRA-4998 - > Added IConfigurationLoader that is used to load an external Config. When the > System Property cassandra.config.loader is defined with an implementing > class, DatabaseDescriptor with will that Config over loading the > cassandra.yaml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4795) replication, compaction, compression? options are not validated
[ https://issues.apache.org/jira/browse/CASSANDRA-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592621#comment-13592621 ] Pavel Yaskevich commented on CASSANDRA-4795: I've reviewed those two, +1. > replication, compaction, compression? options are not validated > --- > > Key: CASSANDRA-4795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4795 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Brandon Williams >Assignee: Dave Brosius >Priority: Minor > Fix For: 1.2.1 > > Attachments: 0001-Reallow-unexpected-strategy-options-for-thrift.txt, > 0002-Reallow-unexpected-strategy-options-for-thrift.txt, > 0003-Adds-application_metadata-field-to-ks-metadata.txt, > 4795.compaction_strategy.txt, 4795_compaction_strategy_v2.txt, > 4795_compaction_strategy_v3.txt, 4795.replication_strategy.txt > > > When creating a keyspace and specifying strategy options, you can pass any > k/v pair you like. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592634#comment-13592634 ] Cristian Opris commented on CASSANDRA-5062: --- Sorry, I've probably edited my comment after your reply. C_current.timestamp needs to be exactly R-1 if you increment the counter on sending the proposal. If it's less than the acceptor hasn't learned the previously committed value (R-1) so can't participate in round R, otherwise we're mixing up rounds. If it's more, than the proposer is behind so you already handle that. Regarding " If you get quorum for the proposal you can perform the CAS locally and just send the new column value with the accept" By that I meant you can do the validate part of the CAS locally, not actually write the CAS. Basically any operation (not just CAS) can be evaluated (in memory) by the proposal after it gets quorum for the proposal (which guarantees it has the latest *committed* value) so it obtains the value to send for acceptance. This is more of an optimization where you exchange and agree on values rather than operations (state transfer replication). Also solves the problem of where to validate the CAS. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592634#comment-13592634 ] Cristian Opris edited comment on CASSANDRA-5062 at 3/4/13 9:05 PM: --- Sorry, I've probably edited my comment after your reply. C_current.timestamp needs to be exactly R-1 if you increment the counter on sending the proposal. If it's less, then the acceptor hasn't learned the previously committed value (R-1) so can't participate in round R, otherwise we're mixing up rounds. If it's more, then the proposer is behind so you already handle that. Regarding " If you get quorum for the proposal you can perform the CAS locally and just send the new column value with the accept" By that I meant you can do the validate part of the CAS locally, not actually write the CAS. Basically any operation (not just CAS) can be evaluated (in memory) by the proposal after it gets quorum for the proposal (which guarantees it has the latest *committed* value) so it obtains the value to send for acceptance. This is more of an optimization where you exchange and agree on values rather than operations (state transfer replication). Also solves the problem of where to validate the CAS. was (Author: onetoinfin...@yahoo.com): Sorry, I've probably edited my comment after your reply. C_current.timestamp needs to be exactly R-1 if you increment the counter on sending the proposal. If it's less than the acceptor hasn't learned the previously committed value (R-1) so can't participate in round R, otherwise we're mixing up rounds. If it's more, than the proposer is behind so you already handle that. Regarding " If you get quorum for the proposal you can perform the CAS locally and just send the new column value with the accept" By that I meant you can do the validate part of the CAS locally, not actually write the CAS. Basically any operation (not just CAS) can be evaluated (in memory) by the proposal after it gets quorum for the proposal (which guarantees it has the latest *committed* value) so it obtains the value to send for acceptance. This is more of an optimization where you exchange and agree on values rather than operations (state transfer replication). Also solves the problem of where to validate the CAS. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5312) json2sstable throws java.lang.ClassCastException when using Murmur3
chris erway created CASSANDRA-5312: -- Summary: json2sstable throws java.lang.ClassCastException when using Murmur3 Key: CASSANDRA-5312 URL: https://issues.apache.org/jira/browse/CASSANDRA-5312 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.1 Environment: DataStax community AMI Reporter: chris erway Priority: Minor Tried to import some JSON tables using json2sstable today on a new cluster using the Murmur3Partitioner. It threw this exception: $ sudo -u cassandra json2sstable -K Keyspace -c CFName Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db log4j:WARN No appenders could be found for logger (org.apache.cassandra.config.DatabaseDescriptor). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Importing 21 keys... java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter at org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56) at org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482) at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325) at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319) at org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:379) at org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:313) at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:535) ERROR: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter There's a related issue in CASSANDRA-4196 having to do with bulk loading that suggests a fix might involve passing the right type down to the FilterFactory (?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5312) json2sstable throws java.lang.ClassCastException when using Murmur3
[ https://issues.apache.org/jira/browse/CASSANDRA-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chris erway updated CASSANDRA-5312: --- Description: Tried to import some JSON tables using json2sstable today on a new cluster using the Murmur3Partitioner. It threw this exception: $ sudo -u cassandra json2sstable -K Keyspace -c CFName Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db log4j:WARN No appenders could be found for logger (org.apache.cassandra.config.DatabaseDescriptor). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Importing 21 keys... java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter at org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56) at org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482) at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325) at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319) at org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:379) at org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:313) at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:535) ERROR: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter There's a related issue in CASSANDRA-4196 having to do with bulk loading that suggests a fix might involve passing the right type down to the FilterFactory. was: Tried to import some JSON tables using json2sstable today on a new cluster using the Murmur3Partitioner. It threw this exception: $ sudo -u cassandra json2sstable -K Keyspace -c CFName Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db log4j:WARN No appenders could be found for logger (org.apache.cassandra.config.DatabaseDescriptor). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Importing 21 keys... java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter at org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56) at org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482) at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325) at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319) at org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:379) at org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:313) at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:535) ERROR: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter There's a related issue in CASSANDRA-4196 having to do with bulk loading that suggests a fix might involve passing the right type down to the FilterFactory (?) > json2sstable throws java.lang.ClassCastException when using Murmur3 > --- > > Key: CASSANDRA-5312 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5312 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.2.1 > Environment: DataStax community AMI >Reporter: chris erway >Priority: Minor > > Tried to import some JSON tables using json2sstable today on a new cluster > using the Murmur3Partitioner. It threw this exception: > $ sudo -u cassandra json2sstable -K Keyspace -c CFName > Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db > log4j:WARN No appenders could be found for logger > (org.apache.cassandra.config.DatabaseDescriptor). > log4j:WARN Please initialize the log4j system properly. > log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more > info. > Importing 21 keys... > java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter > cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter > at > org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56) > at > org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482) > at > org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325) > at > org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319) > at > org.apache.cassandr
[jira] [Updated] (CASSANDRA-5312) json2sstable throws java.lang.ClassCastException when using Murmur3
[
https://issues.apache.org/jira/browse/CASSANDRA-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chris erway updated CASSANDRA-5312:
---
Description:
Tried to import some JSON tables using json2sstable today on a new cluster
using the Murmur3Partitioner. It threw this exception:
{{$ sudo -u cassandra json2sstable -K Keyspace -c CFName
Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.config.DatabaseDescriptor).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
Importing 21 keys...
java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter
cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter
at
org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56)
at
org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319)
at
org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:379)
at
org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:313)
at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:535)
ERROR: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to
org.apache.cassandra.utils.Murmur2BloomFilter}}
There's a related issue in CASSANDRA-4196 having to do with bulk loading that
suggests a fix might involve passing the right type down to the FilterFactory.
was:
Tried to import some JSON tables using json2sstable today on a new cluster
using the Murmur3Partitioner. It threw this exception:
$ sudo -u cassandra json2sstable -K Keyspace -c CFName
Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.config.DatabaseDescriptor).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
Importing 21 keys...
java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter
cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter
at
org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56)
at
org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319)
at
org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:379)
at
org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:313)
at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:535)
ERROR: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to
org.apache.cassandra.utils.Murmur2BloomFilter
There's a related issue in CASSANDRA-4196 having to do with bulk loading that
suggests a fix might involve passing the right type down to the FilterFactory.
> json2sstable throws java.lang.ClassCastException when using Murmur3
> ---
>
> Key: CASSANDRA-5312
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5312
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.2.1
> Environment: DataStax community AMI
>Reporter: chris erway
>Priority: Minor
>
> Tried to import some JSON tables using json2sstable today on a new cluster
> using the Murmur3Partitioner. It threw this exception:
> {{$ sudo -u cassandra json2sstable -K Keyspace -c CFName
> Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db
> log4j:WARN No appenders could be found for logger
> (org.apache.cassandra.config.DatabaseDescriptor).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info.
> Importing 21 keys...
> java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter
> cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter
> at
> org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56)
> at
> org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482)
> at
> org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325)
> at
> org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319)
> at
> org.apache.cassan
[jira] [Updated] (CASSANDRA-5312) json2sstable throws java.lang.ClassCastException when using Murmur3
[
https://issues.apache.org/jira/browse/CASSANDRA-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chris erway updated CASSANDRA-5312:
---
Description:
Tried to import some JSON tables using json2sstable today on a new cluster
using the Murmur3Partitioner. It threw this exception:
$ sudo -u cassandra json2sstable -K Keyspace -c CFName
Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.config.DatabaseDescriptor).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
Importing 21 keys...
java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter
cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter
at
org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56)
at
org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319)
at
org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:379)
at
org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:313)
at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:535)
ERROR: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to
org.apache.cassandra.utils.Murmur2BloomFilter
There's a related issue in CASSANDRA-4196 having to do with bulk loading that
suggests a fix might involve passing the right type down to the FilterFactory.
was:
Tried to import some JSON tables using json2sstable today on a new cluster
using the Murmur3Partitioner. It threw this exception:
{{$ sudo -u cassandra json2sstable -K Keyspace -c CFName
Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.config.DatabaseDescriptor).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
Importing 21 keys...
java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter
cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter
at
org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56)
at
org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325)
at
org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319)
at
org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:379)
at
org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:313)
at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:535)
ERROR: org.apache.cassandra.utils.Murmur3BloomFilter cannot be cast to
org.apache.cassandra.utils.Murmur2BloomFilter}}
There's a related issue in CASSANDRA-4196 having to do with bulk loading that
suggests a fix might involve passing the right type down to the FilterFactory.
> json2sstable throws java.lang.ClassCastException when using Murmur3
> ---
>
> Key: CASSANDRA-5312
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5312
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.2.1
> Environment: DataStax community AMI
>Reporter: chris erway
>Priority: Minor
>
> Tried to import some JSON tables using json2sstable today on a new cluster
> using the Murmur3Partitioner. It threw this exception:
> $ sudo -u cassandra json2sstable -K Keyspace -c CFName
> Keyspace-CFName-hd-1-Data.db.json Keyspace-CFName-hd-1-Data.db
> log4j:WARN No appenders could be found for logger
> (org.apache.cassandra.config.DatabaseDescriptor).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info.
> Importing 21 keys...
> java.lang.ClassCastException: org.apache.cassandra.utils.Murmur3BloomFilter
> cannot be cast to org.apache.cassandra.utils.Murmur2BloomFilter
> at
> org.apache.cassandra.utils.FilterFactory.serialize(FilterFactory.java:56)
> at
> org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:482)
> at
> org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:325)
> at
> org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:319)
> at
> org.apache.cassandr
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592677#comment-13592677 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. C_current.timestamp needs to be exactly R-1 I don't think that's necessary. We never mix rounds, because all operation and paxos state include the round number. If you're an acceptor that is behind and some proposer that is also behind propose some value, then so be it (we're still guarantee the proposer will learn the value that was decided). Paxos is fine with a acceptor failing and recovering at any time, which is exactly what this is about. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592743#comment-13592743 ] Cristian Opris commented on CASSANDRA-5062: --- Say you have this: Proposer has committed R-1, starts round R, proposal timestamp Tn Acceptor recovers with committed R-n < R-1, and has accepted value A at R-n+1 < R-1 at Tm in the paxos state log. When Acceptor receives proposal, if it doesn't check R, if Tm > Tn (clock mismatch) according to paxos it needs to send it's old accepted value and the proposer will have to use it to commit. It will end up committing an old value. It's an edge case but not impossible. Paxos holds within the same round, but not across rounds. This makes sense because a Paxos round just means agree on a value which once accepted by a quorum can never change. Which is why you can't have an out of date replica participate in a round. The idea is to move from quorum that committed (learned) R to quorum that accepts R+1 to quorum that commits R+1 and so on. Note the quorums don't need to be made of same components. To ensure this you maintain the invariant that *you can't propose or accept R+1 locally if you haven't committed R* So a replica can die and recover, but to recover and participate in paxos needs to learn the latest value. This also gives you consistent read (at the possible cost of an extra read paxos proposal to ensure that the last paxos round is committed if left ambiguous) > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592748#comment-13592748 ] Cristian Opris commented on CASSANDRA-5062: --- So I think what you're doing at the moment is effectively using the (R,P) tuple as the proposal number within a single continuous Paxos instance, that sometimes may agree on things and sometimes replicas learn the agreed value. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of "FrontPage" by DBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "FrontPage" page has been changed by DBrosius: http://wiki.apache.org/cassandra/FrontPage?action=diff&rev1=86&rev2=88 Comment: start rebuilding front page + = Cassandra Wiki = - Yo guys !! The name is ALLISON ACEVEDO. I go to night school at The Bumpy Academy of Sturdy People situated in Madison.<> - I am self employed as a Presenter. I also like to Nature Walking. My dad name is Dan and he is a Occupational Therapist. My mummy is a Chaplain.<> - <> - Feel free to surf to my webpage [[http://cheap-beatsbydre.blinkweb.com|dr dre earphones]] + Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store. Cassandra brings together the distributed systems technologies from [[http://web.archive.org/web/20120221222718/http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf|Dynamo]] and the data model from Google's [[http://research.google.com/archive/bigtable-osdi06.pdf|BigTable]]. Like Dynamo, Cassandra is [[http://www.allthingsdistributed.com/2008/12/eventually_consistent.html|eventually consistent]]. Like BigTable, Cassandra provides a ColumnFamily-based data model richer than typical key/value systems. + + Cassandra was open sourced by Facebook in 2008, where it was designed by Avinash Lakshman (one of the authors of Amazon's Dynamo) and Prashant Malik ( Facebook Engineer ). In a lot of ways you can think of Cassandra as Dynamo 2.0 or a marriage of Dynamo and BigTable. Cassandra is in production use at Facebook but is still under heavy development. + + == General Information == + + * Official Cassandra Website (download, bug-tracking, mailing-lists, etc) + * Articles and Presentations about Cassandra. + * A description of the Cassandra data model + * Cassandra Limitations: where Cassandra is not a good fit + + == Application developer and operator documentation == + + * Getting Started + * Datastax's Cassandra documentation + * Client options: ways to access Cassandra -- interfaces for Ruby, Python, Scala and more + * IntegrationPoints -- list of ways Cassandra is integrated with other projects/products + * Administration Tools -- list of administrative tools to configure / admin your Cassandra instance + * Running Cassandra + * Architecture Overview + * Simple Use Cases and Solutions -- please help complete + * FAQ + * Counters + * SecondaryIndexes + * NodeTool + + == Advanced Setup and Tuning == + + * Storage Configuration + * Creating a multi-node cluster + * Operations + * Embedding + * Memtable Thresholds and other Performance Tuning + * Cassandra Hardware + * Configuration on Rackspace or Amazon Web Services + * Large data set considerations + + == Client library developer information == + + * Thrift API Documentation (In progress) + + == Cassandra developer Documentation == + + * How To Build + * How to Debug in Eclipse + * ArchitectureInternals + * CLI Design + * How To Contribute? + * How To Commit? + * How To Release (Note: currently a work in progress) (Note: only relevant to Cassandra Committers) + + == Mailing lists == + + * Users: u...@cassandra.apache.org (subscribe) (archives) (incubator archives) + * Developers: d...@cassandra.apache.org (subscribe) (archives) (incubator archives) + * Commits: commits@cassandra.apache.org (subscribe) + + == Related Information == + + * Thrift, used by Cassandra for client access + * RelatedProjects: Projects using or extending Cassandra + + == Google SoC 2010 Page == + + * Google SoC + This wiki is powered by MoinMoin. With the exception of a few immutable pages, anyone can edit it. Try SyntaxReference if you need help on wiki markup, and FindPage or SiteNavigation to search for existing pages before creating a new one. If you aren't sure where to begin, checkout RecentChanges to see what others have been working on, or RandomPage if you are feeling lucky. + + == Other Languages == + + * SimpleChinese 简体中文 + * Japanese 日本語 + * BrazilianPortuguese Português do Brasil +
[Cassandra Wiki] Update of "FrontPage" by DBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "FrontPage" page has been changed by DBrosius: http://wiki.apache.org/cassandra/FrontPage?action=diff&rev1=88&rev2=89 Comment: add back links == General Information == - * Official Cassandra Website (download, bug-tracking, mailing-lists, etc) + * [[http://web.archive.org/web/20120221222718/http://cassandra.apache.org/|Official Cassandra Website]] (download, bug-tracking, mailing-lists, etc) - * Articles and Presentations about Cassandra. + * [[ArticlesAndPresentations|Articles and Presentations]] about Cassandra. - * A description of the Cassandra data model + * [[DataModel|A description of the Cassandra data model]] - * Cassandra Limitations: where Cassandra is not a good fit + * [[CassandraLimitations|Cassandra Limitations]]: where Cassandra is not a good fit == Application developer and operator documentation == - * Getting Started - * Datastax's Cassandra documentation + * [[GettingStarted|Getting Started]] + * [[http://www.datastax.com/docs|Datastax's Cassandra documentation]] - * Client options: ways to access Cassandra -- interfaces for Ruby, Python, Scala and more + * [[ClientOptions|Client options]]: ways to access Cassandra -- interfaces for Ruby, Python, Scala and more - * IntegrationPoints -- list of ways Cassandra is integrated with other projects/products + * [[IntegrationPoints|Integration Points]] -- list of ways Cassandra is integrated with other projects/products - * Administration Tools -- list of administrative tools to configure / admin your Cassandra instance + * [[Administration%20Tools|Administration Tools]] -- list of administrative tools to configure / admin your Cassandra instance - * Running Cassandra - * Architecture Overview + * [[RunningCassandra|Running Cassandra]] + * [[ArchitectureOverview|Architecture Overview]] - * Simple Use Cases and Solutions -- please help complete + * [[UseCases|Simple Use Cases and Solutions]] -- please help complete - * FAQ - * Counters - * SecondaryIndexes - * NodeTool + * [[FAQ|FAQ]] + * [[Counters|Counters]] + * [[SecondaryIndexes|Secondary Indexes]] + * [[NodeTool|NodeTool]] == Advanced Setup and Tuning ==
[Cassandra Wiki] Update of "FrontPage" by DBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "FrontPage" page has been changed by DBrosius: http://wiki.apache.org/cassandra/FrontPage?action=diff&rev1=89&rev2=90 Comment: add more links == Advanced Setup and Tuning == - * Storage Configuration + * [[StorageConfiguration|Storage Configuration]] - * Creating a multi-node cluster + * [[MultinodeCluster|Creating a multi-node cluster]] - * Operations - * Embedding - * Memtable Thresholds and other Performance Tuning - * Cassandra Hardware + * [[Operations|Operations]] + * [[Embedding|Embedding]] + * [[MemtableThresholds|Memtable Thresholds]] and other [[PerformanceTuning|Performance Tuning]] + * [[CassandraHardware|Cassandra Hardware]] - * Configuration on Rackspace or Amazon Web Services + * [[CloudConfig|Configuration on Rackspace or Amazon Web Services]] - * Large data set considerations + * [[LargeDataSetConsiderations|Large data set considerations]] == Client library developer information == - * Thrift API Documentation (In progress) + * [[API|Thrift API Documentation]] (In progress) == Cassandra developer Documentation == - * How To Build + * [[HowToBuild|How To Build]] - * How to Debug in Eclipse + * [[HowToDebug|How to Debug in Eclipse]] - * ArchitectureInternals - * CLI Design - * How To Contribute? - * How To Commit? + * [[ArchitectureInternals|Architecture Internals]] + * [[CLI%20Design|CLI Design]] + * [[HowToContribute|How To Contribute]]? + * [[How To Commit?|HowToCommit]] - * How To Release (Note: currently a work in progress) (Note: only relevant to Cassandra Committers) + * [[HowToPublishReleases|How To Release]] (Note: currently a work in progress) (Note: only relevant to Cassandra Committers) == Mailing lists == - * Users: u...@cassandra.apache.org (subscribe) (archives) (incubator archives) - * Developers: d...@cassandra.apache.org (subscribe) (archives) (incubator archives) - * Commits: commits@cassandra.apache.org (subscribe) + * Users: [[mailto://u...@cassandra.apache.org|u...@cassandra.apache.org]] ([[mailto://user-subscr...@cassandra.apache.org|subscribe]]) ([[http://www.mail-archive.com/user@cassandra.apache.org/|archives]]) ([[http://www.mail-archive.com/cassandra-user@incubator.apache.org/|incubator archives]]) + * Developers: [[d...@cassandra.apache.org|d...@cassandra.apache.org]] ([[mailto://dev-subscr...@cassandra.apache.org|subscribe]]) ([[http://www.mail-archive.com/dev@cassandra.apache.org/|archives]]) ([[http://www.mail-archive.com/cassandra-dev@incubator.apache.org/|incubator archives]]) + * Commits: [[mailto://commits@cassandra.apache.org|commits@cassandra.apache.org] ([[mailto://commits-subscr...@cassandra.apache.org|subscribe]]) == Related Information == - * Thrift, used by Cassandra for client access + * [[http://incubator.apache.org/thrift|Thrift]], used by Cassandra for client access - * RelatedProjects: Projects using or extending Cassandra + * [[RelatedProjects|Related Projects]]: Projects using or extending Cassandra == Google SoC 2010 Page == - * Google SoC + * [[GoogleSoc2010|Google SoC]] + - This wiki is powered by MoinMoin. With the exception of a few immutable pages, anyone can edit it. Try SyntaxReference if you need help on wiki markup, and FindPage or SiteNavigation to search for existing pages before creating a new one. If you aren't sure where to begin, checkout RecentChanges to see what others have been working on, or RandomPage if you are feeling lucky. + This wiki is powered by [[MoinMoin|MoinMoin]. With the exception of a few immutable pages, anyone can edit it. Try [[SyntaxReference|SyntaxReference]] if you need help on wiki markup, and [[FindPage|FindPage]] or [[SiteNavigation|SiteNavigation]] to search for existing pages before creating a new one. If you aren't sure where to begin, checkout [[RecentChanges|RecentChanges]] to see what others have been working on, or [[RandomPage|RandomPage]] if you are feeling lucky. == Other Languages == - * SimpleChinese 简体中文 - * Japanese 日本語 + * [[%E9%A6%96%E9%A1%B5||SimpleChinese 简体中文]] + * [[FrontPage_JP|Japanese 日本語]] - * BrazilianPortuguese Português do Brasil + * [[FrontPage_PT-BR|BrazilianPortuguese Português do Brasil]]
[Cassandra Wiki] Update of "FrontPage" by DBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "FrontPage" page has been changed by DBrosius: http://wiki.apache.org/cassandra/FrontPage?action=diff&rev1=90&rev2=91 == Other Languages == - * [[%E9%A6%96%E9%A1%B5||SimpleChinese 简体中文]] + * [[%E9%A6%96%E9%A1%B5|SimpleChinese 简体中文]] * [[FrontPage_JP|Japanese 日本語]] * [[FrontPage_PT-BR|BrazilianPortuguese Português do Brasil]]
[Cassandra Wiki] Trivial Update of "BobbyYrj" by BobbyYrj
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "BobbyYrj" page has been changed by BobbyYrj: http://wiki.apache.org/cassandra/BobbyYrj New page: Hey fellas !! The name is DIANNE JOHNSTON. My age is 34.<> My school's name is The Improved Prep School of Largest Education which has a branch in Tulsa. I am self employed as a Astronaut. My papa name is Jason and he is a Internist. My mother is a System designer.<> <> Here is my web site ... [[http://beatsbydre-cheap.blinkweb.com|beats by dre headphones]]
[Cassandra Wiki] Update of "FrontPage" by DBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "FrontPage" page has been changed by DBrosius: http://wiki.apache.org/cassandra/FrontPage?action=diff&rev1=91&rev2=92 Cassandra was open sourced by Facebook in 2008, where it was designed by Avinash Lakshman (one of the authors of Amazon's Dynamo) and Prashant Malik ( Facebook Engineer ). In a lot of ways you can think of Cassandra as Dynamo 2.0 or a marriage of Dynamo and BigTable. Cassandra is in production use at Facebook but is still under heavy development. - == General Information == + == General Information == * [[http://web.archive.org/web/20120221222718/http://cassandra.apache.org/|Official Cassandra Website]] (download, bug-tracking, mailing-lists, etc) * [[ArticlesAndPresentations|Articles and Presentations]] about Cassandra.
[Cassandra Wiki] Trivial Update of "KandyGree" by KandyGree
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "KandyGree" page has been changed by KandyGree: http://wiki.apache.org/cassandra/KandyGree New page: Wassp People !! I am VI BLACKBURN. I am 43. My parents want me to join The Fortune Prep School built at Olathe.<> <> I have a job as Software Engineer. My dad name is Paul and he is a Governess. My mummy is a Gardener.<> <> Have a look at my blog [[http://www.majorchanelbags.com|chanel bags]]
