[jira] [Updated] (CASSANDRA-3749) Allow rangeSlice queries to be start/end inclusive/exclusive
[
https://issues.apache.org/jira/browse/CASSANDRA-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-3749:
Attachment: 3749-v2.patch
bq. if we are splitting a Bounds on bounds.right, that means that remainder
overlaps Bounds entirely and so we should add that to the ranges, but instead
we skip it.
Not absolutely certain about the case you mean, but with an example: let say we
have Bounds [3, 5]. And say that one of the token nodes is 5 (so we'll split on
bounds.right). So if you split [3, 5] by 5, you're basically not splitting
anything, since splitting would end up with [3, 5] and (5, 5], but (5, 5] is an
empty range (as it happens, we do use allow creating (5, 5] and it means *all
the ring*. That qualifies as weird honestly but that's the way it work. In any
case, we shouldn't have split create such a range since it wouldn't be
correct). So that's a case of the splitting not changing the input
AbstractBounds and thus null is returned. In SP.GRR, when that happens, we
simply skip to the next token. If for instance that next token (say 10) isn't
contained in [3, 5], we'll just add [3, 5] at the end of the loop.
Attaching v2 that incorporates the comment tweaks, adds tests for SP.GRR for
the two new classes and remove the now useless {{if remainder == null}} test at
the end of the main loop of SP.GRR.
> Allow rangeSlice queries to be start/end inclusive/exclusive
> -
>
> Key: CASSANDRA-3749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3749
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 1.1
>
> Attachments: 3749-comments.txt, 3749-v2.patch, 3749.patch
>
>
> Currently, given two keys k1 and k2, we can only do a rangeSlice on the
> intervals (k1, k2] (Range) and [k1, k2] (Bounds). CQL goes around this
> "manually", by querying one more row if the start is exclusive and removing
> the start/end post-query if necessary. This doesn't work however with the new
> option introduced by CASSANDRA-3742. So this ticket proposes to add support
> (internally) for doing a rangeSlice for the intervals (k1, k2) an [k1, k2).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3636) cassandra 1.0.6 debian packages will not run on OpenVZ
[
https://issues.apache.org/jira/browse/CASSANDRA-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189018#comment-13189018
]
Saulius Grigaitis commented on CASSANDRA-3636:
--
I have exactly same version with cassandra 1.0.6 and 1.0.7 version (1.0.5
version works fine)
Installing from debian packanges on ubuntu 10.04 64bits:
Installing new version of config file /etc/cassandra/cassandra.yaml ...
error: permission denied on key 'vm.max_map_count'
dpkg: error processing cassandra (--configure):
subprocess installed post-installation script returned error exit status 255
uname -a
Linux server 2.6.32-042stab044.11 #1 SMP Wed Dec 14 16:02:00 MSK 2011 x86_64
GNU/Linux
> cassandra 1.0.6 debian packages will not run on OpenVZ
> --
>
> Key: CASSANDRA-3636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3636
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 1.0.6
> Environment: Debian Linux (stable), OpenVZ container
>Reporter: Zenek Kraweznik
>Assignee: Brandon Williams
>Priority: Minor
>
> During upgrade from 1.0.6
> {code}Setting up cassandra (1.0.6) ...
> *error: permission denied on key 'vm.max_map_count'*
> dpkg: error processing cassandra (--configure):
> subprocess installed post-installation script returned error exit status 255
> Errors were encountered while processing:
> cassandra
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2392) Saving IndexSummaries to disk
[
https://issues.apache.org/jira/browse/CASSANDRA-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189046#comment-13189046
]
Pavel Yaskevich commented on CASSANDRA-2392:
Thanks for the patch! Here is my review:
- Index summaries load in SSTableReader.load(boolean, Set) breaks
key cache pre-load.
- IndexSummary deserialize(...) method should be made static and return
IndexSummary object. This will also allow to drop IndexSummary argument from
SSTableReader.loadSummaries(...).
- To avoid any seeks in the PRIMARY_INDEX file upon IndexSummary.deserialize I
suggest to save key (only BB part) as well as index position on
IndexSummary.serialize.
- I would also suggest to save dataPosition from the primary index into
summaries file to avoid adding serialization to SegmentedFile because
SegmentedFile serialize(...)/deserialize(...) are not really a
serialize/deserialize - they just save/read boundaries. This way you would be
able to do deserialization and boundary load at the save time without
saving/reading additional information to/from the disk because only ibuilder
needs indexPosition and dbuilder - dataPosition.
- loadSummaries should be renamed to something more appropriate because that
method does not only load index summaries it also loads index and data
builders, per se it does not really load them but rather just deserializes
boundaries into an existing object with is not a good practice.
- can you please explain this chunk of code to me?
{code}
+// don't rename summaries as it is not created yet and created
while it is loaded.
+for (Component component : Sets.difference(components,
Sets.newHashSet(Component.DATA, Component.SUMMARIES)))
FBUtilities.renameWithConfirm(tmpdesc.filenameFor(component),
newdesc.filenameFor(component));
{code}
> Saving IndexSummaries to disk
> -
>
> Key: CASSANDRA-2392
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2392
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Chris Goffinet
>Assignee: Vijay
>Priority: Minor
> Fix For: 1.1
>
> Attachments: 0001-re-factor-first-and-last.patch,
> 0001-save-summaries-to-disk.patch, 0002-save-summaries-to-disk.patch
>
>
> For nodes with millions of keys, doing rolling restarts that take over 10
> minutes per node can be painful if you have 100 node cluster. All of our time
> is spent on doing index summary computations on startup. It would be great if
> we could save those to disk as well. Our indexes are quite large.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2878) Allow CQL-based map/reduce
[
https://issues.apache.org/jira/browse/CASSANDRA-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189138#comment-13189138
]
Jonathan Ellis commented on CASSANDRA-2878:
---
So I'm attempting option (1) above, with a method like this:
{code}
. CqlResult execute_partitioned_cql_query(1:required binary query,
2:required string start_token,
3:required string end_token,
4:Compression compression)
{code}
The problem I'm running into is that paginating this CQL-side is enormously
painful. Suppose the last resultset entry is for a composite column (first =
a, second = b) in a row k. Then I need to request my next page as "... WHERE
(key > k OR (key = key AND first >= a AND second > b))." QueryProcessor just
isn't up to this task, even without the complexity of throwing in other
IndexExpressions.
Starting to think that we're better off with (4) for 1.1, after all.
> Allow CQL-based map/reduce
> --
>
> Key: CASSANDRA-2878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2878
> Project: Cassandra
> Issue Type: New Feature
> Components: Hadoop
>Reporter: Mck SembWever
>Assignee: Jonathan Ellis
>Priority: Critical
> Fix For: 1.1
>
>
> Currently, when running a MapReduce job against data in a Cassandra data
> store, it reads through all the data for a particular ColumnFamily. This
> could be optimized to only read through those rows that have to do with the
> query.
> Adding CQL support to m/r will allow using an index more simply than trying
> to cram support for more parameters into the job configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3749) Allow rangeSlice queries to be start/end inclusive/exclusive
[ https://issues.apache.org/jira/browse/CASSANDRA-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189141#comment-13189141 ] Jonathan Ellis commented on CASSANDRA-3749: --- +1 > Allow rangeSlice queries to be start/end inclusive/exclusive > - > > Key: CASSANDRA-3749 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3749 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 1.1 > > Attachments: 3749-comments.txt, 3749-v2.patch, 3749.patch > > > Currently, given two keys k1 and k2, we can only do a rangeSlice on the > intervals (k1, k2] (Range) and [k1, k2] (Bounds). CQL goes around this > "manually", by querying one more row if the start is exclusive and removing > the start/end post-query if necessary. This doesn't work however with the new > option introduced by CASSANDRA-3742. So this ticket proposes to add support > (internally) for doing a rangeSlice for the intervals (k1, k2) an [k1, k2). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3727) Fix unit tests failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189139#comment-13189139
]
Mark Butler commented on CASSANDRA-3727:
Building Cassandra 1.0.7 I get one test failure:
{code}
Class org.apache.cassandra.db.compaction.CompactionsTest
NameTests Errors FailuresTime(s) Time Stamp Host
CompactionsTest 1 1 0 0.000 2012-01-19T12:52:18
mbutler-OptiPlex-990
Tests
NameStatus TypeTime(s)
testSuperColumnCompactions Error Timeout occurred. Please note the time
in the report does not reflect the time until the timeout.
junit.framework.AssertionFailedError: Timeout occurred. Please note the time in
the report does not reflect the time until the timeout.
0.001
{code}
and also see exceptions being thrown saying it was unable to create a hard link
{code}
[junit] WARN 13:53:33,357 Overriding RING_DELAY to 1000ms
[junit] ERROR 13:53:39,794 Unable to create hard link
[junit] com.sun.jna.LastErrorException: errno was 17
[junit] at org.apache.cassandra.utils.CLibrary.link(Native Method)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLink(CLibrary.java:146)
[junit] at
org.apache.cassandra.io.sstable.SSTableReader.createLinks(SSTableReader.java:833)
[junit] at
org.apache.cassandra.db.DataTracker$1.runMayThrow(DataTracker.java:161)
[junit] at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[junit] at java.lang.Thread.run(Thread.java:662)
[junit] ERROR 13:53:39,796 Fatal exception in thread
Thread[NonPeriodicTasks:1,5,main]
[junit] java.lang.RuntimeException: java.io.IOException: Unable to create
hard link from build/test/cassandra/data/Keyspace1/Standard1-hc-1-Digest.sha1
to
/home/mbutler/workspace/vscc/vscc-oss-components/cassandra-1.0.7/build/test/cassandra/data/Keyspace1/backups/Standard1-hc-1-Digest.sha1
(errno 17)
[junit] at
org.apache.cassandra.utils.FBUtilities.unchecked(FBUtilities.java:689)
[junit] at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[junit] at java.lang.Thread.run(Thread.java:662)
[junit] Caused by: java.io.IOException: Unable to create hard link from
build/test/cassandra/data/Keyspace1/Standard1-hc-1-Digest.sha1 to
/home/mbutler/workspace/vscc/vscc-oss-components/cassandra-1.0.7/build/test/cassandra/data/Keyspace1/backups/Standard1-hc-1-Digest.sha1
(errno 17)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLink(CLibrary.java:160)
[junit] at
org.apache.cassandra.io.sstable.SSTableReader.createLinks(SSTableReader.java:833)
[junit] at
org.apache.cassandra.db.DataTracker$1.runMayThrow(DataTracker.java:161)
[junit] at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
[junit] ... 8 more
[junit] ERROR 13:53:39,797 Unable to create hard link
[junit] com.sun.jna.LastErrorException: errno was 17
[junit] at org.apache.cassandra.utils.CLibrary.link(Native Method)
[junit] at
org.apache.cassandra.utils.CLibrary.createHardLink(CLibrary.java:146)
[junit] at
org.apache.cassandra.io.sstable.SSTableReader.createLinks(SSTableReader.java:833)
[junit] at
org.apache.cassandra.db.DataTracker$1.runMayThrow(DataTracker.java:161)
[junit] at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.jav
[jira] [Commented] (CASSANDRA-3749) Allow rangeSlice queries to be start/end inclusive/exclusive
[
https://issues.apache.org/jira/browse/CASSANDRA-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189142#comment-13189142
]
Jonathan Ellis commented on CASSANDRA-3749:
---
Actually my comment change was not quite correct:
{code}
+ * Given token T and AbstractBounds ?L,R?, returns Pair(?L,T], [T,R?),
{code}
should be
{code}
+ * Given token T and AbstractBounds ?L,R?, returns Pair(?L,T], (T,R?),
{code}
> Allow rangeSlice queries to be start/end inclusive/exclusive
> -
>
> Key: CASSANDRA-3749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3749
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 1.1
>
> Attachments: 3749-comments.txt, 3749-v2.patch, 3749.patch
>
>
> Currently, given two keys k1 and k2, we can only do a rangeSlice on the
> intervals (k1, k2] (Range) and [k1, k2] (Bounds). CQL goes around this
> "manually", by querying one more row if the start is exclusive and removing
> the start/end post-query if necessary. This doesn't work however with the new
> option introduced by CASSANDRA-3742. So this ticket proposes to add support
> (internally) for doing a rangeSlice for the intervals (k1, k2) an [k1, k2).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3727) Fix unit tests failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189145#comment-13189145
]
Jonathan Ellis commented on CASSANDRA-3727:
---
See CASSANDRA-3735 for the hard link fix
> Fix unit tests failure
> --
>
> Key: CASSANDRA-3727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3727
> Project: Cassandra
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.0.7
>Reporter: Sylvain Lebresne
>Priority: Blocker
> Fix For: 1.0.7
>
> Attachments: 3727.txt, CASSANDRA-3727-CliTest-timeout-fix.patch
>
>
> On current 1.0 branch (and on my machine: Linux), I have the following unit
> test failures:
> * CliTest and EmbeddedCassandraTest: they both first kind of pass (JUnit
> first prints a message with no failures in it), then hang until JUnit timeout
> and fails with a 'Timeout occurred'. In other word, the tests themselves are
> passing, but something they do prevents the process to exit cleanly leading
> to a JUnit timeout. I don't want to discard that as not a problem, because if
> something can make the process not exit cleanly, this can be a pain for
> restarts (and in particular upgrades) and hence would be basically a
> regression. I'm marking the ticket as blocker (for the release of 1.0.7)
> mostly because of this one.
> * SystemTableTest: throws an assertionError. I haven't checked yet, so that
> could be an easy one to fix.
> * RemoveTest: it fails, saying that '/127.0.0.1:7010 is in use by another
> process' (consistently). But I have no other process running on port 7010.
> It's likely just of problem of the test, but it's new and in the meantime
> removes are not tested.
> * I also see a bunch of stack trace with errors like:
> {noformat}
> [junit] ERROR 10:01:59,007 Fatal exception in thread
> Thread[NonPeriodicTasks:1,5,main]
> [junit] java.lang.RuntimeException: java.io.IOException: Unable to create
> hard link from build/test/cassandra/data/Keyspace1/Indexed1-hc-1-Index.db to
> /home/mcmanus/Git/cassandra/build/test/cassandra/data/Keyspace1/backups/Indexed1-hc-1-Index.db
> (errno 17)
> {noformat}
> (with SSTableReaderTest). This does not make the tests fail, but it is still
> worth investigating. It may be due to CASSANDRA-3101.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2878) Allow CQL-based map/reduce
[ https://issues.apache.org/jira/browse/CASSANDRA-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189147#comment-13189147 ] Mck SembWever commented on CASSANDRA-2878: -- (4) would at least leave CFIF in better place before migrating forward to CIF. > Allow CQL-based map/reduce > -- > > Key: CASSANDRA-2878 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2878 > Project: Cassandra > Issue Type: New Feature > Components: Hadoop >Reporter: Mck SembWever >Assignee: Jonathan Ellis >Priority: Critical > Fix For: 1.1 > > > Currently, when running a MapReduce job against data in a Cassandra data > store, it reads through all the data for a particular ColumnFamily. This > could be optimized to only read through those rows that have to do with the > query. > Adding CQL support to m/r will allow using an index more simply than trying > to cram support for more parameters into the job configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3636) cassandra 1.0.6 debian packages will not run on OpenVZ
[
https://issues.apache.org/jira/browse/CASSANDRA-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189164#comment-13189164
]
paul cannon commented on CASSANDRA-3636:
Saulius- are you also running openvz? What version, if so?
> cassandra 1.0.6 debian packages will not run on OpenVZ
> --
>
> Key: CASSANDRA-3636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3636
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 1.0.6
> Environment: Debian Linux (stable), OpenVZ container
>Reporter: Zenek Kraweznik
>Assignee: Brandon Williams
>Priority: Minor
>
> During upgrade from 1.0.6
> {code}Setting up cassandra (1.0.6) ...
> *error: permission denied on key 'vm.max_map_count'*
> dpkg: error processing cassandra (--configure):
> subprocess installed post-installation script returned error exit status 255
> Errors were encountered while processing:
> cassandra
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Allow rangeSlice queries to be start/end inclusive/exclusive
Updated Branches:
refs/heads/trunk bce44ff32 -> 35f7bc597
Allow rangeSlice queries to be start/end inclusive/exclusive
patch by slebresne; reviewed by jbellis for CASSANDRA-3749
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/35f7bc59
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/35f7bc59
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/35f7bc59
Branch: refs/heads/trunk
Commit: 35f7bc597a8d26ca88526cf0d5208c13bdda523d
Parents: bce44ff
Author: Sylvain Lebresne
Authored: Thu Jan 19 17:05:45 2012 +0100
Committer: Sylvain Lebresne
Committed: Thu Jan 19 17:05:45 2012 +0100
--
CHANGES.txt|1 +
.../org/apache/cassandra/db/ColumnFamilyStore.java | 30 ++--
.../org/apache/cassandra/dht/AbstractBounds.java | 105 ++--
src/java/org/apache/cassandra/dht/Bounds.java | 15 ++-
.../org/apache/cassandra/dht/ExcludingBounds.java | 98 ++
.../cassandra/dht/IncludingExcludingBounds.java| 97 ++
src/java/org/apache/cassandra/dht/Range.java | 91 +-
src/java/org/apache/cassandra/dht/Token.java | 27 ++--
.../apache/cassandra/io/sstable/SSTableReader.java |4 +-
.../org/apache/cassandra/service/StorageProxy.java | 20 +-
.../apache/cassandra/db/ColumnFamilyStoreTest.java | 70 +++-
.../apache/cassandra/dht/AbstractBoundsTest.java | 137 ---
test/unit/org/apache/cassandra/dht/RangeTest.java | 77
.../apache/cassandra/service/StorageProxyTest.java | 32 -
14 files changed, 522 insertions(+), 282 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/35f7bc59/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 68147d7..4a4bf35 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -45,6 +45,7 @@
* Make stress.java insert operation to use microseconds (CASSANDRA-3725)
* Allows (internally) doing a range query with a limit of columns instead of
rows (CASSANDRA-3742)
+ * Allow rangeSlice queries to be start/end inclusive/exclusive
(CASSANDRA-3749)
1.0.7
http://git-wip-us.apache.org/repos/asf/cassandra/blob/35f7bc59/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index 805c55c..0238344 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -1218,9 +1218,7 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
*/
public AbstractScanIterator getSequentialIterator(ByteBuffer superColumn,
final AbstractBounds range, IFilter columnFilter)
{
-assert range instanceof Bounds
- || !((Range)range).isWrapAround() || range.right.isMinimum()
- : range;
+assert !(range instanceof Range) || !((Range)range).isWrapAround() ||
range.right.isMinimum() : range;
final RowPosition startWith = range.left;
final RowPosition stopAt = range.right;
@@ -1236,8 +1234,6 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
return new AbstractScanIterator()
{
-boolean first = true;
-
protected Row computeNext()
{
// pull a row out of the iterator
@@ -1250,20 +1246,18 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
if (!stopAt.isMinimum() && stopAt.compareTo(key) < 0)
return endOfData();
-// skip first one
-if (range instanceof Bounds || !first ||
!key.equals(startWith))
-{
-if (logger.isDebugEnabled())
-logger.debug("scanned " + key);
-// TODO this is necessary because when we collate
supercolumns together, we don't check
-// their subcolumns for relevance, so we need to do a
second prune post facto here.
-return current.cf != null && current.cf.isSuper()
- ? new Row(current.key, removeDeleted(current.cf,
gcBefore))
- : current;
-}
-first = false;
+// skipping outside of assigned range
+if (!range.contains(key))
+return computeNext();
+
+if (logger.isDebugEnabled())
+logger.debug("scanned " + key);
-return
[jira] [Assigned] (CASSANDRA-3752) bulk loader no longer finds sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-3752:
---
Assignee: Brandon Williams
> bulk loader no longer finds sstables
>
>
> Key: CASSANDRA-3752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3752
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1
>Reporter: Brandon Williams
>Assignee: Brandon Williams
> Fix For: 1.1
>
>
> It looks like CASSANDRA-2749 broke it:
> {noformat}
> WARN 13:02:20,107 Invalid file 'Standard1' in data directory
> /var/lib/cassandra/data/Keyspace1.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3726) cqlsh and cassandra-cli show keys differently for data created via stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-3726:
---
Attachment: 3726.patch.txt
Added a bunch to cqlsh's output formatting so that certain types (in
particular, blob) are shown in a more human-readable way. Used colors (when
enabled) to help distinguish hex strings from text strings, and to distinguish
control characters in text strings.
The attached patch contains the changes, or the 3726 branch in my github fork
can be used:
https://github.com/thepaul/cassandra/commits/3726
> cqlsh and cassandra-cli show keys differently for data created via stress tool
> --
>
> Key: CASSANDRA-3726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3726
> Project: Cassandra
> Issue Type: Bug
>Reporter: Cathy Daw
>Assignee: paul cannon
>Priority: Minor
> Attachments: 3726.patch.txt
>
>
> {code}
> // Run: stress --operation=INSERT --num-keys=5 --columns=2
> --consistency-level=QUORUM --column-size=1 --threads=1 --replication-factor=1
> --nodes=localhost
> // cqlsh
> cqlsh:Keyspace1> select * from Standard1;
> KEY,3 | C0,c | C1,c |
> KEY,0 |
> KEY,2 | C0,c | C1,c |
> KEY,1 | C0,c | C1,c |
> KEY,4 | C0,c | C1,c |
> cqlsh:Keyspace1> describe columnfamily Standard1;
> CREATE COLUMNFAMILY Standard1 (
> KEY blob PRIMARY KEY
> ) WITH
> comment='' AND
> comparator=ascii AND
> row_cache_provider='ConcurrentLinkedHashCacheProvider' AND
> key_cache_size=20.00 AND
> row_cache_size=0.00 AND
> read_repair_chance=1.00 AND
> gc_grace_seconds=864000 AND
> default_validation=blob AND
> min_compaction_threshold=4 AND
> max_compaction_threshold=32 AND
> row_cache_save_period_in_seconds=0 AND
> key_cache_save_period_in_seconds=14400 AND
> replicate_on_write=True;
> // cassandra-cli
> [default@Keyspace1] list Standard1;
> Using default limit of 100
> ---
> RowKey: 33
> => (column=C0, value=63, timestamp=1326259960705)
> => (column=C1, value=63, timestamp=1326259960705)
> ---
> RowKey: 30
> ---
> RowKey: 32
> => (column=C0, value=63, timestamp=1326259960704)
> => (column=C1, value=63, timestamp=1326259960704)
> ---
> RowKey: 31
> => (column=C0, value=63, timestamp=1326259960704)
> => (column=C1, value=63, timestamp=1326259960704)
> ---
> RowKey: 34
> => (column=C0, value=63, timestamp=1326259960705)
> => (column=C1, value=63, timestamp=1326259960705)
> [default@Keyspace1] describe Standard1;
> ColumnFamily: Standard1
> Key Validation Class: org.apache.cassandra.db.marshal.BytesType
> Default column value validator:
> org.apache.cassandra.db.marshal.BytesType
> Columns sorted by: org.apache.cassandra.db.marshal.AsciiType
> Row cache size / save period in seconds / keys to save : 0.0/0/all
> Row Cache Provider:
> org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider
> Key cache size / save period in seconds: 20.0/14400
> GC grace seconds: 864000
> Compaction min/max thresholds: 4/32
> Read repair chance: 1.0
> Replicate on write: true
> Built indexes: []
> Compaction Strategy:
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3752) bulk loader no longer finds sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3752:
Attachment: 3752.txt
Patch to use new directory layout, also add stream throttling to prevent an NPE
when there is no yaml config (in anticipation of CASSANDRA-3740)
> bulk loader no longer finds sstables
>
>
> Key: CASSANDRA-3752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3752
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1
>Reporter: Brandon Williams
>Assignee: Brandon Williams
> Fix For: 1.1
>
> Attachments: 3752.txt
>
>
> It looks like CASSANDRA-2749 broke it:
> {noformat}
> WARN 13:02:20,107 Invalid file 'Standard1' in data directory
> /var/lib/cassandra/data/Keyspace1.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2392) Saving IndexSummaries to disk
[ https://issues.apache.org/jira/browse/CASSANDRA-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189198#comment-13189198 ] Vijay commented on CASSANDRA-2392: -- Hi Pavel >> To avoid any seeks in the PRIMARY_INDEX file upon IndexSummary.deserialize I >> suggest to save key (only BB part) as well as index position on >> IndexSummary.serialize. Will do, The initial idea was to save some disk space as they keys in some cases can be really long :) and with the index seeks was not that bad in my initial tests but i will save it in v2. >> I would also suggest to save dataPosition from the primary index into >> summaries file to avoid adding serialization to SegmentedFile because >> SegmentedFile serialize(...)/deserialize(...) are not really a >> serialize/deserialize I am not sure how saving dataPosition will help as we only have summaries between 128Keys or more and how will we mark a boundary with it? For example each row is 100MB big. >> can you please explain this chunk of code to me? The idea is to save the summary when SSTable creation/load completes (as there isnt any temporary state for them and they fit in memory). If corrupted or deleted or not there we will just recalculate them instead of depending on them. > Saving IndexSummaries to disk > - > > Key: CASSANDRA-2392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2392 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Assignee: Vijay >Priority: Minor > Fix For: 1.1 > > Attachments: 0001-re-factor-first-and-last.patch, > 0001-save-summaries-to-disk.patch, 0002-save-summaries-to-disk.patch > > > For nodes with millions of keys, doing rolling restarts that take over 10 > minutes per node can be painful if you have 100 node cluster. All of our time > is spent on doing index summary computations on startup. It would be great if > we could save those to disk as well. Our indexes are quite large. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3740) While using BulkOutputFormat unneccessarily look for the cassandra.yaml file.
[
https://issues.apache.org/jira/browse/CASSANDRA-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3740:
Attachment: 0004-update-BOF-for-new-dir-layout.txt
> While using BulkOutputFormat unneccessarily look for the cassandra.yaml file.
> --
>
> Key: CASSANDRA-3740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3740
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 1.1
>Reporter: Samarth Gahire
>Assignee: Brandon Williams
> Labels: cassandra, hadoop, mapreduce
> Fix For: 1.1
>
> Attachments: 0001-Make-DD-the-canonical-partitioner-source.txt,
> 0002-Prevent-loading-from-yaml.txt, 0003-use-output-partitioner.txt,
> 0004-update-BOF-for-new-dir-layout.txt
>
>
> I am trying to use BulkOutputFormat to stream the data from map of Hadoop
> job. I have set the cassandra related configuration using ConfigHelper ,Also
> have looked into Cassandra code seems Cassandra has taken care that it should
> not look for the cassandra.yaml file.
> But still when I run the job i get the following error:
> {
> 12/01/13 11:30:04 WARN mapred.JobClient: Use GenericOptionsParser for parsing
> the arguments. Applications should implement Tool for the same.
> 12/01/13 11:30:04 INFO input.FileInputFormat: Total input paths to process : 1
> 12/01/13 11:30:04 INFO mapred.JobClient: Running job: job_201201130910_0015
> 12/01/13 11:30:05 INFO mapred.JobClient: map 0% reduce 0%
> 12/01/13 11:30:23 INFO mapred.JobClient: Task Id :
> attempt_201201130910_0015_m_00_0, Status : FAILED
> java.lang.Throwable: Child Error
> at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:271)
> Caused by: java.io.IOException: Task process exit with nonzero status of 1.
> at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:258)
> attempt_201201130910_0015_m_00_0: Cannot locate cassandra.yaml
> attempt_201201130910_0015_m_00_0: Fatal configuration error; unable to
> start server.
> }
> Also let me know how can i make this cassandra.yaml file available to Hadoop
> mapreduce job?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3754) Add TTL and counter support to BulkOutputFormat
Add TTL and counter support to BulkOutputFormat --- Key: CASSANDRA-3754 URL: https://issues.apache.org/jira/browse/CASSANDRA-3754 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Fix For: 1.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3740) While using BulkOutputFormat unneccessarily look for the cassandra.yaml file.
[
https://issues.apache.org/jira/browse/CASSANDRA-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189205#comment-13189205
]
Brandon Williams commented on CASSANDRA-3740:
-
bq. 1) "org.apache.cassandra.config.Config" do not initialize the all the
properties and which results into the null pointer exception in a static block
of class "DatabaseDescriptor" for example "conf.commitlog_sync"
Patches to address that.
bq. 2) I cant see any method in ConfigHelper to specify that I am using
"Supercolumn"
"mapreduce.output.bulkoutputformat.issuper" controls that.
bq. 3) Also there is no method to specify comparator and subcomparator in
ConfigHelper and it seems like comparators have been hard coded to "BytesType"
BytesType will sort correctly, the comparators are in the schema on the remote
nodes.
bq. Apart From these issues I do not think that we are considering the TTL case
in BulkOutputFormat.
CASSANDRA-3754 will handle this.
> While using BulkOutputFormat unneccessarily look for the cassandra.yaml file.
> --
>
> Key: CASSANDRA-3740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3740
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 1.1
>Reporter: Samarth Gahire
>Assignee: Brandon Williams
> Labels: cassandra, hadoop, mapreduce
> Fix For: 1.1
>
> Attachments: 0001-Make-DD-the-canonical-partitioner-source.txt,
> 0002-Prevent-loading-from-yaml.txt, 0003-use-output-partitioner.txt,
> 0004-update-BOF-for-new-dir-layout.txt
>
>
> I am trying to use BulkOutputFormat to stream the data from map of Hadoop
> job. I have set the cassandra related configuration using ConfigHelper ,Also
> have looked into Cassandra code seems Cassandra has taken care that it should
> not look for the cassandra.yaml file.
> But still when I run the job i get the following error:
> {
> 12/01/13 11:30:04 WARN mapred.JobClient: Use GenericOptionsParser for parsing
> the arguments. Applications should implement Tool for the same.
> 12/01/13 11:30:04 INFO input.FileInputFormat: Total input paths to process : 1
> 12/01/13 11:30:04 INFO mapred.JobClient: Running job: job_201201130910_0015
> 12/01/13 11:30:05 INFO mapred.JobClient: map 0% reduce 0%
> 12/01/13 11:30:23 INFO mapred.JobClient: Task Id :
> attempt_201201130910_0015_m_00_0, Status : FAILED
> java.lang.Throwable: Child Error
> at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:271)
> Caused by: java.io.IOException: Task process exit with nonzero status of 1.
> at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:258)
> attempt_201201130910_0015_m_00_0: Cannot locate cassandra.yaml
> attempt_201201130910_0015_m_00_0: Fatal configuration error; unable to
> start server.
> }
> Also let me know how can i make this cassandra.yaml file available to Hadoop
> mapreduce job?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3752) bulk loader no longer finds sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3752:
--
Reviewer: xedin
> bulk loader no longer finds sstables
>
>
> Key: CASSANDRA-3752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3752
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1
>Reporter: Brandon Williams
>Assignee: Brandon Williams
> Fix For: 1.1
>
> Attachments: 3752.txt
>
>
> It looks like CASSANDRA-2749 broke it:
> {noformat}
> WARN 13:02:20,107 Invalid file 'Standard1' in data directory
> /var/lib/cassandra/data/Keyspace1.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3743) Lower memory consumption used by index sampling
[
https://issues.apache.org/jira/browse/CASSANDRA-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189286#comment-13189286
]
Yuki Morishita commented on CASSANDRA-3743:
---
+1 except coding style:
- you should use 4 spaces instead of tab
- always place { and } on new line
> Lower memory consumption used by index sampling
> ---
>
> Key: CASSANDRA-3743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3743
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0.0
>Reporter: Radim Kolar
>Assignee: Radim Kolar
> Labels: optimization
> Fix For: 1.1
>
> Attachments: cassandra-3743.txt
>
>
> currently j.o.a.c.io.sstable.indexsummary is implemented as ArrayList of
> KeyPosition (RowPosition key, long offset)i propose to change it to:
> RowPosition keys[]
> long offsets[]
> and use standard binary search on it. This will lower number of java objects
> used per entry from 2 (KeyPosition + RowPosition) to 1 (RowPosition).
> For building these arrays convenient ArrayList class can be used and then
> call to .toArray() on it.
> This is very important because index sampling uses a lot of memory on nodes
> with billions rows
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3748) Range ghosts don't disappear as expected and accumulate
[ https://issues.apache.org/jira/browse/CASSANDRA-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189291#comment-13189291 ] Dominic Williams commented on CASSANDRA-3748: - Hey, anyone got any ideas on this bug yet? > Range ghosts don't disappear as expected and accumulate > --- > > Key: CASSANDRA-3748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3748 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.3 > Environment: Cassandra on Debian >Reporter: Dominic Williams > Labels: compaction, ghost-row, range, remove > Fix For: 1.0.8 > > Original Estimate: 6h > Remaining Estimate: 6h > > I have a problem where range ghosts are accumulating and cannot be removed by > reducing GCSeconds and compacting. > In our system, we have some cfs that represent "markets" where each row > represents an item. Once an item is sold, it is removed from the market by > passing its key to remove(). > The problem, which was hidden for some time by caching, is appearing on read. > Every few seconds our system collates a random sample from each cf/market by > choosing a random starting point: > String startKey = RNG.nextUUID()) > and then loading a page range of rows, specifying the key range as: > KeyRange keyRange = new KeyRange(pageSize); > keyRange.setStart_key(startKey); > keyRange.setEnd_key(maxKey); > The returned rows are iterated over, and ghosts ignored. If insufficient rows > are obtained, the process is repeated using the key of the last row as the > starting key (or wrapping if necessary etc). > When performance was lagging, we did a test and found that constructing a > random sample of 40 items (rows) involved iterating over hundreds of > thousands of ghost rows. > Our first attempt to deal with this was to halve our GCGraceSeconds and then > perform major compactions. However, this had no effect on the number of ghost > rows being returned. Furthermore, on examination it seems clear that the > number of ghost rows being created within GCSeconds window must be smaller > than the number being returned. Thus looks like a bug. > We are using Cassandra 1.0.3 with Sylain's patch from CASSANDRA-3510 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3736:
Fix Version/s: (was: 1.0.8)
1.1
> -Dreplace_token leaves old node (IP) in the gossip with the token.
> --
>
> Key: CASSANDRA-3736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.0
>Reporter: Jackson Chung
>Assignee: Vijay
> Fix For: 1.1
>
> Attachments: 0001-CASSANDRA-3736.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
> -Dreplace_token,
> however, the replaced IP keeps on showing up in the Gossiper when starting
> the replacement node:
> {noformat}
> INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
> Listening for thrift clients...
> INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
> /50.56.59.68 has restarted, now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
> InetAddress /50.56.59.68 is now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
> Node /50.56.59.68 state jump to normal
> INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
> /50.56.58.55 has restarted, now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
> FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
> INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
> /50.56.58.55 is now part of the cluster
> INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
> FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
> INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
> /50.56.58.55 is now part of the cluster
> INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
> Removing token 122029383590318827259508597176866581733 for /50.56.58.55
> {noformat}
> in the above, /50.56.58.55 was the replaced IP.
> tried adding the "Gossiper.instance.removeEndpoint(endpoint);" in the
> StorageService.java where the message 'Nodes %s and %s have the same token
> %s. Ignoring %s",' seems only have fixed this temporary. Here is a ring
> output:
> {noformat}
> riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
> Address DC RackStatus State LoadOwns
> Token
>
> 85070591730234615865843651857942052864
> 50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
> 60502102442797279294142560823234402248
> 50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
> 85070591730234615865843651857942052864
> {noformat}
> gossipinfo:
> {noformat}
> $ ./bin/nodetool -h localhost gossipinfo
> /50.56.58.55
> LOAD:6835.0
> SCHEMA:--1000--
> RPC_ADDRESS:50.56.58.55
> STATUS:NORMAL,85070591730234615865843651857942052864
> RELEASE_VERSION:1.0.7-SNAPSHOT
> /50.56.59.68
> LOAD:6835.0
> SCHEMA:--1000--
> RPC_ADDRESS:50.56.59.6
[jira] [Commented] (CASSANDRA-2392) Saving IndexSummaries to disk
[ https://issues.apache.org/jira/browse/CASSANDRA-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189299#comment-13189299 ] Pavel Yaskevich commented on CASSANDRA-2392: bq. I am not sure how saving dataPosition will help as we only have summaries between 128Keys or more and how will we mark a boundary with it? For example each row is 100MB big. Oh yes, you are right, we really need all boundary information from segmented files, my bad. > Saving IndexSummaries to disk > - > > Key: CASSANDRA-2392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2392 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Assignee: Vijay >Priority: Minor > Fix For: 1.1 > > Attachments: 0001-re-factor-first-and-last.patch, > 0001-save-summaries-to-disk.patch, 0002-save-summaries-to-disk.patch > > > For nodes with millions of keys, doing rolling restarts that take over 10 > minutes per node can be painful if you have 100 node cluster. All of our time > is spent on doing index summary computations on startup. It would be great if > we could save those to disk as well. Our indexes are quite large. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189302#comment-13189302
]
Brandon Williams commented on CASSANDRA-3736:
-
If CASSANDRA-3747 solved this, then I don't think there's any full solution
here worth applying, since this is mostly just a cosmetic problem and not worth
introducing a possibly destabilizing change over. Anyone running into this can
use CASSANDRA-3337 to remove it, or avoid replacing tokens.
+1 to this patch for 1.0 and trunk, though.
> -Dreplace_token leaves old node (IP) in the gossip with the token.
> --
>
> Key: CASSANDRA-3736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.0
>Reporter: Jackson Chung
>Assignee: Vijay
> Fix For: 1.1
>
> Attachments: 0001-CASSANDRA-3736.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
> -Dreplace_token,
> however, the replaced IP keeps on showing up in the Gossiper when starting
> the replacement node:
> {noformat}
> INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
> Listening for thrift clients...
> INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
> /50.56.59.68 has restarted, now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
> InetAddress /50.56.59.68 is now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
> Node /50.56.59.68 state jump to normal
> INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
> /50.56.58.55 has restarted, now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
> FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
> INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
> /50.56.58.55 is now part of the cluster
> INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
> FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
> INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
> /50.56.58.55 is now part of the cluster
> INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
> Removing token 122029383590318827259508597176866581733 for /50.56.58.55
> {noformat}
> in the above, /50.56.58.55 was the replaced IP.
> tried adding the "Gossiper.instance.removeEndpoint(endpoint);" in the
> StorageService.java where the message 'Nodes %s and %s have the same token
> %s. Ignoring %s",' seems only have fixed this temporary. Here is a ring
> output:
> {noformat}
> riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
> Address DC RackStatus State LoadOwns
> Token
>
> 85070591730234615865843651857942052864
> 50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
> 60502102442797279294142560823234402248
> 50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
> 85070591730234615865843651857942052864
> {noformat}
> gossipinfo:
> {nof
[jira] [Issue Comment Edited] (CASSANDRA-2392) Saving IndexSummaries to disk
[ https://issues.apache.org/jira/browse/CASSANDRA-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189299#comment-13189299 ] Pavel Yaskevich edited comment on CASSANDRA-2392 at 1/19/12 7:18 PM: - bq. Will do, The initial idea was to save some disk space as they keys in some cases can be really long and with the index seeks was not that bad in my initial tests but i will save it in v2. I'm thinking here from the I/O perpective because if we just read one file sequentially we will get page cache read-head working for us populating it with useful data but if you read from two files and do random I/O on one of them that will lead to slower I/O + page cache populated with useless data which could cost performance when node finishes start-up and starts to serve reads. Index intervals are almost all the time big enough so space taken by keys negligible comparing to I/O benefits it would give us. bq. I am not sure how saving dataPosition will help as we only have summaries between 128Keys or more and how will we mark a boundary with it? For example each row is 100MB big. Oh yes, you are right, we really need all boundary information from segmented files, my bad. was (Author: xedin): bq. I am not sure how saving dataPosition will help as we only have summaries between 128Keys or more and how will we mark a boundary with it? For example each row is 100MB big. Oh yes, you are right, we really need all boundary information from segmented files, my bad. > Saving IndexSummaries to disk > - > > Key: CASSANDRA-2392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2392 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Assignee: Vijay >Priority: Minor > Fix For: 1.1 > > Attachments: 0001-re-factor-first-and-last.patch, > 0001-save-summaries-to-disk.patch, 0002-save-summaries-to-disk.patch > > > For nodes with millions of keys, doing rolling restarts that take over 10 > minutes per node can be painful if you have 100 node cluster. All of our time > is spent on doing index summary computations on startup. It would be great if > we could save those to disk as well. Our indexes are quite large. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3688) [patch] avoid map lookups in loops by using entrysets
[ https://issues.apache.org/jira/browse/CASSANDRA-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3688: -- Reviewer: jbellis Affects Version/s: (was: 1.0.6) Fix Version/s: (was: 1.0.8) 1.1 Assignee: Dave Brosius > [patch] avoid map lookups in loops by using entrysets > - > > Key: CASSANDRA-3688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3688 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 1.1 > > Attachments: use_entrysets.diff > > > code loops over the keySet and does gets for the value, just use entrySet() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3688) [patch] avoid map lookups in loops by using entrysets
[ https://issues.apache.org/jira/browse/CASSANDRA-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3688. --- Resolution: Fixed committed to trunk > [patch] avoid map lookups in loops by using entrysets > - > > Key: CASSANDRA-3688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3688 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 1.1 > > Attachments: use_entrysets.diff > > > code loops over the keySet and does gets for the value, just use entrySet() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3689) [path] minor cleanup of compiler warnings
[ https://issues.apache.org/jira/browse/CASSANDRA-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3689: -- Affects Version/s: (was: 1.0.6) Fix Version/s: (was: 1.0.8) 1.1 Assignee: Dave Brosius committed > [path] minor cleanup of compiler warnings > - > > Key: CASSANDRA-3689 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3689 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 1.1 > > Attachments: warnings_AbstractType.diff > > > a bunch of minor cleanups around generics use around AbstractType, some > imports cleanups, unused fields etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[3/3] git commit: use entryset looping instead of key + get patch by Dave Brosius; reviewed by jbellis for CASSANDRA-3688
use entryset looping instead of key + get
patch by Dave Brosius; reviewed by jbellis for CASSANDRA-3688
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9bfdb01f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9bfdb01f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9bfdb01f
Branch: refs/heads/trunk
Commit: 9bfdb01f00bdd88165fac9d07e7f6b60700ca40b
Parents: 35f7bc5
Author: Jonathan Ellis
Authored: Thu Jan 19 13:22:09 2012 -0600
Committer: Jonathan Ellis
Committed: Thu Jan 19 13:31:23 2012 -0600
--
.../apache/cassandra/service/StorageService.java | 19 --
1 files changed, 11 insertions(+), 8 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9bfdb01f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 4b544bc..6852fe0 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2657,22 +2657,24 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
private CountDownLatch streamRanges(final Map, InetAddress>> rangesToStreamByTable)
{
final CountDownLatch latch = new
CountDownLatch(rangesToStreamByTable.keySet().size());
-for (final String table : rangesToStreamByTable.keySet())
+for (Map.Entry, InetAddress>> entry :
rangesToStreamByTable.entrySet())
{
-Multimap, InetAddress> rangesWithEndpoints =
rangesToStreamByTable.get(table);
+Multimap, InetAddress> rangesWithEndpoints =
entry.getValue();
if (rangesWithEndpoints.isEmpty())
{
latch.countDown();
continue;
}
+
+final String table = entry.getKey();
final Set, InetAddress>> pending = new
HashSet, InetAddress>>(rangesWithEndpoints.entries());
-for (final Map.Entry, InetAddress> entry :
rangesWithEndpoints.entries())
+for (final Map.Entry, InetAddress> endPointEntry :
rangesWithEndpoints.entries())
{
-final Range range = entry.getKey();
-final InetAddress newEndpoint = entry.getValue();
+final Range range = endPointEntry.getKey();
+final InetAddress newEndpoint = endPointEntry.getValue();
final Runnable callback = new Runnable()
{
@@ -2680,7 +2682,7 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
{
synchronized (pending)
{
-pending.remove(entry);
+pending.remove(endPointEntry);
if (pending.isEmpty())
latch.countDown();
@@ -2709,9 +2711,9 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
private CountDownLatch requestRanges(final Map>> ranges)
{
final CountDownLatch latch = new
CountDownLatch(ranges.keySet().size());
-for (final String table : ranges.keySet())
+for (Map.Entry>> entry :
ranges.entrySet())
{
-Multimap> endpointWithRanges =
ranges.get(table);
+Multimap> endpointWithRanges =
entry.getValue();
if (endpointWithRanges.isEmpty())
{
@@ -2719,6 +2721,7 @@ public class StorageService implements
IEndpointStateChangeSubscriber, StorageSe
continue;
}
+final String table = entry.getKey();
final Set pending = new
HashSet(endpointWithRanges.keySet());
// Send messages to respective folks to stream data over to me
[2/3] clean up AbtractType generics treatment patch by Dave Brosius; reviewed by jbellis for CASSANDRA-3689
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2bc0d4db/src/java/org/apache/cassandra/thrift/ThriftValidation.java
--
diff --git a/src/java/org/apache/cassandra/thrift/ThriftValidation.java
b/src/java/org/apache/cassandra/thrift/ThriftValidation.java
index 64f5d6d..31035e3 100644
--- a/src/java/org/apache/cassandra/thrift/ThriftValidation.java
+++ b/src/java/org/apache/cassandra/thrift/ThriftValidation.java
@@ -235,7 +235,7 @@ public class ThriftValidation
if (metadata.cfType == ColumnFamilyType.Standard)
throw new InvalidRequestException("supercolumn specified to
ColumnFamily " + metadata.cfName + " containing normal columns");
}
-AbstractType comparator = metadata.getComparatorFor(superColumnName);
+AbstractType comparator =
metadata.getComparatorFor(superColumnName);
for (ByteBuffer name : column_names)
{
if (name.remaining() > IColumn.MAX_NAME_LENGTH)
@@ -260,7 +260,7 @@ public class ThriftValidation
public static void validateRange(CFMetaData metadata, ColumnParent
column_parent, SliceRange range) throws InvalidRequestException
{
-AbstractType comparator =
metadata.getComparatorFor(column_parent.super_column);
+AbstractType comparator =
metadata.getComparatorFor(column_parent.super_column);
try
{
comparator.validate(range.start);
@@ -428,7 +428,7 @@ public class ThriftValidation
ColumnDefinition columnDef = metadata.getColumnDefinition(column.name);
try
{
-AbstractType validator = metadata.getValueValidator(columnDef);
+AbstractType validator = metadata.getValueValidator(columnDef);
if (validator != null)
validator.validate(column.value);
}
@@ -552,7 +552,7 @@ public class ThriftValidation
return false;
Set indexedColumns =
Table.open(metadata.ksName).getColumnFamilyStore(metadata.cfName).indexManager.getIndexedColumns();
-AbstractType nameValidator =
ColumnFamily.getComparatorFor(metadata.ksName, metadata.cfName, null);
+AbstractType nameValidator =
ColumnFamily.getComparatorFor(metadata.ksName, metadata.cfName, null);
boolean isIndexed = false;
for (IndexExpression expression : index_clause)
@@ -569,7 +569,7 @@ public class ThriftValidation
me.getMessage()));
}
-AbstractType valueValidator =
Schema.instance.getValueValidator(metadata.ksName, metadata.cfName,
expression.column_name);
+AbstractType valueValidator =
Schema.instance.getValueValidator(metadata.ksName, metadata.cfName,
expression.column_name);
try
{
valueValidator.validate(expression.value);
@@ -624,7 +624,7 @@ public class ThriftValidation
if (cf_def.column_metadata == null)
return;
-AbstractType comparator = cfType == ColumnFamilyType.Standard
+AbstractType comparator = cfType == ColumnFamilyType.Standard
? TypeParser.parse(cf_def.comparator_type)
:
TypeParser.parse(cf_def.subcomparator_type);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2bc0d4db/src/java/org/apache/cassandra/tools/SSTableExport.java
--
diff --git a/src/java/org/apache/cassandra/tools/SSTableExport.java
b/src/java/org/apache/cassandra/tools/SSTableExport.java
index 8c9ee5f..c521755 100644
--- a/src/java/org/apache/cassandra/tools/SSTableExport.java
+++ b/src/java/org/apache/cassandra/tools/SSTableExport.java
@@ -100,7 +100,7 @@ public class SSTableExport
* @param comparator columns comparator
* @param cfMetaData Column Family metadata (to get validator)
*/
-private static void serializeColumns(Iterator columns,
PrintStream out, AbstractType comparator, CFMetaData cfMetaData)
+private static void serializeColumns(Iterator columns,
PrintStream out, AbstractType comparator, CFMetaData cfMetaData)
{
while (columns.hasNext())
{
@@ -120,7 +120,7 @@ public class SSTableExport
*
* @return column as serialized list
*/
-private static List serializeColumn(IColumn column, AbstractType
comparator, CFMetaData cfMetaData)
+private static List serializeColumn(IColumn column,
AbstractType comparator, CFMetaData cfMetaData)
{
ArrayList serializedColumn = new ArrayList();
@@ -134,7 +134,7 @@ public class SSTableExport
}
else
{
-AbstractType validator = cfMetaData.getValueValidator(name);
+AbstractType validator = cfMetaData.getValueValidator(name);
serializedColumn.add(validator.getString(value));
[jira] [Resolved] (CASSANDRA-3689) [path] minor cleanup of compiler warnings
[ https://issues.apache.org/jira/browse/CASSANDRA-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3689. --- Resolution: Fixed > [path] minor cleanup of compiler warnings > - > > Key: CASSANDRA-3689 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3689 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 1.1 > > Attachments: warnings_AbstractType.diff > > > a bunch of minor cleanups around generics use around AbstractType, some > imports cleanups, unused fields etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3755) NPE on invalid CQL DELETE command
NPE on invalid CQL DELETE command
-
Key: CASSANDRA-3755
URL: https://issues.apache.org/jira/browse/CASSANDRA-3755
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8 beta 1
Reporter: paul cannon
Priority: Minor
The CQL command {{delete from k where key='bar';}} causes Cassandra to hit a
NullPointerException when the "k" column family does not exist, and it
subsequently closes the Thrift connection instead of reporting an IRE or
whatever. This is probably wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3371) Cassandra inferred schema and actual data don't match
[
https://issues.apache.org/jira/browse/CASSANDRA-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3371:
Description:
It's looking like there may be a mismatch between the schema that's being
reported by the latest CassandraStorage.java, and the data that's actually
returned. Here's an example:
rows = LOAD 'cassandra://Frap/PhotoVotes' USING CassandraStorage();
DESCRIBE rows;
rows: {key: chararray,columns: {(name: chararray,value: bytearray,photo_owner:
chararray,value_photo_owner: bytearray,pid: chararray,value_pid:
bytearray,matched_string: chararray,value_matched_string: bytearray,src_big:
chararray,value_src_big: bytearray,time: chararray,value_time:
bytearray,vote_type: chararray,value_vote_type: bytearray,voter:
chararray,value_voter: bytearray)}}
DUMP rows;
(691831038_1317937188.48955,{(photo_owner,1596090180),(pid,6855155124568798560),(matched_string,),(src_big,),(time,Thu
Oct 06 14:39:48 -0700 2011),(vote_type,album_dislike),(voter,691831038)})
getSchema() is reporting the columns as an inner bag of tuples, each of which
contains 16 values. In fact, getNext() seems to return an inner bag containing
7 tuples, each of which contains two values.
It appears that things got out of sync with this change:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?r1=1177083&r2=1177082&pathrev=1177083
See more discussion at:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/pig-cassandra-problem-quot-Incompatible-field-schema-quot-error-tc6882703.html
was:
It's looking like there may be a mismatch between the schema that's being
reported by the latest CassandraStorage.java, and the data that's actually
returned. Here's an example:
rows = LOAD 'cassandra://Frap/PhotoVotes' USING CassandraStorage();
DESCRIBE rows;
rows: {key: chararray,columns: {(name: chararray,value: bytearray,photo_owner:
chararray,value_photo_owner: bytearray,pid: chararray,value_pid:
bytearray,matched_string: chararray,value_matched_string: bytearray,src_big:
chararray,value_src_big: bytearray,time: chararray,value_time:
bytearray,vote_type: chararray,value_vote_type: bytearray,voter:
chararray,value_voter: bytearray)}}
DUMP rows;
(691831038_1317937188.48955,{(photo_owner,1596090180),(pid,6855155124568798560),(matched_string,),(src_big,),(time,Thu
Oct 06 14:39:48 -0700 2011),(vote_type,album_dislike),(voter,691831038)})
getSchema() is reporting the columns as an inner bag of tuples, each of which
contains 16 values. In fact, getNext() seems to return an inner bag containing
7 tuples, each of which contains two values.
It appears that things got out of sync with this change:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?r1=1177083&r2=1177082&pathrev=1177083
See more discussion at:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/pig-cassandra-problem-quot-Incompatible-field-schema-quot-error-tc6882703.html
Here's a patch I ended up creating for my own use, which gives the results I
need (though it doesn't handle super-columns):
DESCRIBE rows;
rows: {cassandra_key: chararray,photo_owner: bytearray,pid:
bytearray,place_matched_string: bytearray,src_big: bytearray,time:
bytearray,vote_type: bytearray,voter: bytearray}
Index:
contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
===
--- contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
(revision 1185044)
+++ contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
(working copy)
@@ -26,7 +26,7 @@
import org.apache.cassandra.db.marshal.IntegerType;
import org.apache.cassandra.db.marshal.TypeParser;
import org.apache.cassandra.thrift.*;
-import org.apache.cassandra.utils.Hex;
+import org.apache.cassandra.utils.FBUtilities;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -122,15 +122,15 @@
assert key != null && cf != null;
// and wrap it in a tuple
- Tuple tuple = TupleFactory.getInstance().newTuple(2);
+ Tuple tuple = TupleFactory.getInstance().newTuple(cf.size()+1);
ArrayList columns = new ArrayList();
-tuple.set(0, new DataByteArray(key.array(),
key.position()+key.arrayOffset(), key.limit()+key.arrayOffset()));
+int tupleIndex = 0;
+tuple.set(tupleIndex++, new DataByteArray(key.array(),
key.position()+key.arrayOffset(), key.limit()+key.arrayOffset()));
for (Map.Entry entry : cf.entrySet())
{
-columns.add(columnToTuple(entry.getKey(), entry.getValue(),
cfDef));
+tuple.set(tupleInde
[jira] [Updated] (CASSANDRA-3371) Cassandra inferred schema and actual data don't match
[
https://issues.apache.org/jira/browse/CASSANDRA-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3371:
Attachment: 3371-v4.txt
> Cassandra inferred schema and actual data don't match
> -
>
> Key: CASSANDRA-3371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3371
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.7
>Reporter: Pete Warden
>Assignee: Brandon Williams
> Attachments: 3371-v2.txt, 3371-v3.txt, 3371-v4.txt, pig.diff
>
>
> It's looking like there may be a mismatch between the schema that's being
> reported by the latest CassandraStorage.java, and the data that's actually
> returned. Here's an example:
> rows = LOAD 'cassandra://Frap/PhotoVotes' USING CassandraStorage();
> DESCRIBE rows;
> rows: {key: chararray,columns: {(name: chararray,value:
> bytearray,photo_owner: chararray,value_photo_owner: bytearray,pid:
> chararray,value_pid: bytearray,matched_string:
> chararray,value_matched_string: bytearray,src_big: chararray,value_src_big:
> bytearray,time: chararray,value_time: bytearray,vote_type:
> chararray,value_vote_type: bytearray,voter: chararray,value_voter:
> bytearray)}}
> DUMP rows;
> (691831038_1317937188.48955,{(photo_owner,1596090180),(pid,6855155124568798560),(matched_string,),(src_big,),(time,Thu
> Oct 06 14:39:48 -0700 2011),(vote_type,album_dislike),(voter,691831038)})
> getSchema() is reporting the columns as an inner bag of tuples, each of which
> contains 16 values. In fact, getNext() seems to return an inner bag
> containing 7 tuples, each of which contains two values.
> It appears that things got out of sync with this change:
> http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?r1=1177083&r2=1177082&pathrev=1177083
> See more discussion at:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/pig-cassandra-problem-quot-Incompatible-field-schema-quot-error-tc6882703.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3371) Cassandra inferred schema and actual data don't match
[
https://issues.apache.org/jira/browse/CASSANDRA-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189334#comment-13189334
]
Brandon Williams commented on CASSANDRA-3371:
-
bq. 1. Fix schema so that this ticket's problem is resolved
v4 does this, however it's not quite all of what we want.
bq. 2. have the default return value from CassandraStorage be (key, column,
value) as is thought of for transposing wide rows
After thinking about this more, that's the wrong way to approach that, because
if you DO want to work within the row, now you have to do an expensive group to
get back what we had before -- a nest structure -- where breaking that
structure up into (k, c, v) is extremely cheap if that's what you want. So
ultimately, we need to stick with a bag for spillage, and thus keep the
existing schema. v4 does this.
v4 also names the *values* of indexed/validated columns after their name, which
is more pygmalion-style, since you'll always want to filter the value, not the
name.
The problem, however, is strange parsing problems again:
{noformat}
ERROR 1200: Pig script failed to parse:
pig script failed to validate:
org.apache.pig.impl.logicalLayer.FrontendException: ERROR 1128: Cannot find
field owner_id in :tuple(name:chararray,owner_id:chararray)
{noformat}
The seems related to the fact that schema-wise, a bag can only contain a single
tuple - but that tuple can then contain any number of items. Apparently this
is only a hard requirement in 0.9 or later, but I tested it up to trunk so it
doesn't look like it's going anywhere.
In practice, however, getNext doesn't actually return this 'container' tuple.
If you do you get casting errors.
I'm not really sure how we can fix this, and finding other examples of
LoadMetadata implemented with bags are hard to come by.
> Cassandra inferred schema and actual data don't match
> -
>
> Key: CASSANDRA-3371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3371
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.7
>Reporter: Pete Warden
>Assignee: Brandon Williams
> Attachments: 3371-v2.txt, 3371-v3.txt, 3371-v4.txt, pig.diff
>
>
> It's looking like there may be a mismatch between the schema that's being
> reported by the latest CassandraStorage.java, and the data that's actually
> returned. Here's an example:
> rows = LOAD 'cassandra://Frap/PhotoVotes' USING CassandraStorage();
> DESCRIBE rows;
> rows: {key: chararray,columns: {(name: chararray,value:
> bytearray,photo_owner: chararray,value_photo_owner: bytearray,pid:
> chararray,value_pid: bytearray,matched_string:
> chararray,value_matched_string: bytearray,src_big: chararray,value_src_big:
> bytearray,time: chararray,value_time: bytearray,vote_type:
> chararray,value_vote_type: bytearray,voter: chararray,value_voter:
> bytearray)}}
> DUMP rows;
> (691831038_1317937188.48955,{(photo_owner,1596090180),(pid,6855155124568798560),(matched_string,),(src_big,),(time,Thu
> Oct 06 14:39:48 -0700 2011),(vote_type,album_dislike),(voter,691831038)})
> getSchema() is reporting the columns as an inner bag of tuples, each of which
> contains 16 values. In fact, getNext() seems to return an inner bag
> containing 7 tuples, each of which contains two values.
> It appears that things got out of sync with this change:
> http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?r1=1177083&r2=1177082&pathrev=1177083
> See more discussion at:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/pig-cassandra-problem-quot-Incompatible-field-schema-quot-error-tc6882703.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3633) update stress to support prepared statements
[
https://issues.apache.org/jira/browse/CASSANDRA-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189337#comment-13189337
]
Brandon Williams commented on CASSANDRA-3633:
-
+1
> update stress to support prepared statements
>
>
> Key: CASSANDRA-3633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3633
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Eric Evans
>Priority: Minor
> Labels: cql
> Fix For: 1.1
>
>
> The {{stress}} utility needs to be updated for testing prepared statements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3587) DESC alias for DESCRIBE keyword in CQL shell
[ https://issues.apache.org/jira/browse/CASSANDRA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-3587: --- Attachment: 3587.patch.txt DESC alias added. Patch attached, or the 3587 branch in my github fork can be used: https://github.com/thepaul/cassandra/commits/3587 > DESC alias for DESCRIBE keyword in CQL shell > > > Key: CASSANDRA-3587 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3587 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Robin Schumacher >Assignee: paul cannon >Priority: Minor > Labels: cqlsh > Attachments: 3587.patch.txt > > > Allow DESC to be used instead of full DESCRIBE keyword. MySQL and Oracle > users are used to DESC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3586) Add new SHOW command in CQL shell to list column families
[
https://issues.apache.org/jira/browse/CASSANDRA-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-3586:
---
Attachment: 3586.patch.txt
added {{DESCRIBE COLUMNFAMILIES}}, because this functionality fits with the
other DESCRIBE commands better than the other SHOW commands.
patch attached, or the 3586 branch in my github fork may be used:
https://github.com/thepaul/cassandra/commits/3586
> Add new SHOW command in CQL shell to list column families
> --
>
> Key: CASSANDRA-3586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3586
> Project: Cassandra
> Issue Type: New Feature
> Components: Tools
>Affects Versions: 1.0.6
>Reporter: Robin Schumacher
>Assignee: paul cannon
>Priority: Minor
> Labels: cqlsh
> Attachments: 3586.patch.txt
>
>
> add command SHOW COLUMN FAMILIES to list all column families in a current
> keyspace by name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3633) update stress to support prepared statements
[
https://issues.apache.org/jira/browse/CASSANDRA-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189366#comment-13189366
]
Eric Evans commented on CASSANDRA-3633:
---
bq. The most current changes can be found here:
https://github.com/eevans/cassandra/tree/3633.stress
This branch added working support for prepared statements that used string
arguments; In light of the conclusion to CASSANDRA-3634, more work will be
needed
> update stress to support prepared statements
>
>
> Key: CASSANDRA-3633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3633
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Eric Evans
>Priority: Minor
> Labels: cql
> Fix For: 1.1
>
>
> The {{stress}} utility needs to be updated for testing prepared statements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: CASSANDRA-3736-remove-token-from-systable-when-replaced
Updated Branches:
refs/heads/trunk 2bc0d4db9 -> 739848602
CASSANDRA-3736-remove-token-from-systable-when-replaced
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/73984860
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/73984860
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/73984860
Branch: refs/heads/trunk
Commit: 739848602dc01b4f4d1893bf3aa38f5ddcf13267
Parents: 2bc0d4d
Author: Vijay Parthasarathy
Authored: Thu Jan 19 12:59:50 2012 -0800
Committer: Vijay Parthasarathy
Committed: Thu Jan 19 12:59:50 2012 -0800
--
src/java/org/apache/cassandra/db/SystemTable.java |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/73984860/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java
b/src/java/org/apache/cassandra/db/SystemTable.java
index 8f1adfc..c831382 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -139,7 +139,10 @@ public class SystemTable
public static synchronized void updateToken(InetAddress ep, Token token)
{
if (ep == FBUtilities.getLocalAddress())
+{
+removeToken(token);
return;
+}
IPartitioner p = StorageService.getPartitioner();
ColumnFamily cf = ColumnFamily.create(Table.SYSTEM_TABLE, STATUS_CF);
cf.addColumn(new Column(p.getTokenFactory().toByteArray(token),
ByteBuffer.wrap(ep.getAddress()), System.currentTimeMillis()));
git commit: 0001-CASSANDRA-3736-remove-token-from-systable-when-replaced
Updated Branches:
refs/heads/cassandra-1.0 181022bd5 -> 83119656a
0001-CASSANDRA-3736-remove-token-from-systable-when-replaced
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/83119656
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/83119656
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/83119656
Branch: refs/heads/cassandra-1.0
Commit: 83119656a2f54db064ec1479eddb826d8fcaf7de
Parents: 181022b
Author: Vijay Parthasarathy
Authored: Thu Jan 19 13:04:21 2012 -0800
Committer: Vijay Parthasarathy
Committed: Thu Jan 19 13:04:21 2012 -0800
--
src/java/org/apache/cassandra/db/SystemTable.java |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83119656/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java
b/src/java/org/apache/cassandra/db/SystemTable.java
index 8f1adfc..c831382 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -139,7 +139,10 @@ public class SystemTable
public static synchronized void updateToken(InetAddress ep, Token token)
{
if (ep == FBUtilities.getLocalAddress())
+{
+removeToken(token);
return;
+}
IPartitioner p = StorageService.getPartitioner();
ColumnFamily cf = ColumnFamily.create(Table.SYSTEM_TABLE, STATUS_CF);
cf.addColumn(new Column(p.getTokenFactory().toByteArray(token),
ByteBuffer.wrap(ep.getAddress()), System.currentTimeMillis()));
[jira] [Resolved] (CASSANDRA-3736) -Dreplace_token leaves old node (IP) in the gossip with the token.
[
https://issues.apache.org/jira/browse/CASSANDRA-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay resolved CASSANDRA-3736.
--
Resolution: Fixed
Fix Version/s: 1.0.8
Committed both in 1.0 and trunk. Thanks!
> -Dreplace_token leaves old node (IP) in the gossip with the token.
> --
>
> Key: CASSANDRA-3736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3736
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.0
>Reporter: Jackson Chung
>Assignee: Vijay
> Fix For: 1.0.8, 1.1
>
> Attachments: 0001-CASSANDRA-3736.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-957 introduce a
> -Dreplace_token,
> however, the replaced IP keeps on showing up in the Gossiper when starting
> the replacement node:
> {noformat}
> INFO [Thread-2] 2012-01-12 23:59:35,162 CassandraDaemon.java (line 213)
> Listening for thrift clients...
> INFO [GossipStage:1] 2012-01-12 23:59:35,173 Gossiper.java (line 836) Node
> /50.56.59.68 has restarted, now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,174 Gossiper.java (line 804)
> InetAddress /50.56.59.68 is now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,175 StorageService.java (line 988)
> Node /50.56.59.68 state jump to normal
> INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 836) Node
> /50.56.58.55 has restarted, now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,176 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-12 23:59:35,177 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-12 23:59:45,048 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipTasks:1] 2012-01-13 00:00:06,062 Gossiper.java (line 632)
> FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
> INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 838) Node
> /50.56.58.55 is now part of the cluster
> INFO [GossipStage:1] 2012-01-13 00:01:06,320 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-13 00:01:06,321 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-13 00:01:16,106 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipTasks:1] 2012-01-13 00:01:37,121 Gossiper.java (line 632)
> FatClient /50.56.58.55 has been silent for 3ms, removing from gossip
> INFO [GossipStage:1] 2012-01-13 00:02:37,352 Gossiper.java (line 838) Node
> /50.56.58.55 is now part of the cluster
> INFO [GossipStage:1] 2012-01-13 00:02:37,353 Gossiper.java (line 804)
> InetAddress /50.56.58.55 is now UP
> INFO [GossipStage:1] 2012-01-13 00:02:37,353 StorageService.java (line 1016)
> Nodes /50.56.58.55 and action-quick2/50.56.31.186 have the same token
> 85070591730234615865843651857942052864. Ignoring /50.56.58.55
> INFO [GossipTasks:1] 2012-01-13 00:02:47,158 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipStage:1] 2012-01-13 00:02:50,162 Gossiper.java (line 818)
> InetAddress /50.56.58.55 is now dead.
> INFO [GossipStage:1] 2012-01-13 00:02:50,163 StorageService.java (line 1156)
> Removing token 122029383590318827259508597176866581733 for /50.56.58.55
> {noformat}
> in the above, /50.56.58.55 was the replaced IP.
> tried adding the "Gossiper.instance.removeEndpoint(endpoint);" in the
> StorageService.java where the message 'Nodes %s and %s have the same token
> %s. Ignoring %s",' seems only have fixed this temporary. Here is a ring
> output:
> {noformat}
> riptano@action-quick:~/work/cassandra$ ./bin/nodetool -h localhost ring
> Address DC RackStatus State LoadOwns
> Token
>
> 85070591730234615865843651857942052864
> 50.56.59.68 datacenter1 rack1 Up Normal 6.67 KB 85.56%
> 60502102442797279294142560823234402248
> 50.56.31.186datacenter1 rack1 Up Normal 11.12 KB14.44%
> 85070591730234615865843651857942052864
> {noformat}
> gossipinfo:
> {noformat}
> $ ./bin/nodetool -h localhost gossipinfo
> /50.56.58.55
> LOAD:6835.0
> SCHEMA:--1000--
> RPC_ADDRESS:50.56.58.55
> STATUS:NORMAL,85070591730234615865843651857942052864
> RELEASE_VERSION:1.0.7-SNAPSHOT
> /50.56.59.68
> LOAD:6835.0
> SCHEMA:--1000--000
[jira] [Created] (CASSANDRA-3756) cqlsh: allow configuration of value display formats
cqlsh: allow configuration of value display formats
---
Key: CASSANDRA-3756
URL: https://issues.apache.org/jira/browse/CASSANDRA-3756
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.0.0
Reporter: paul cannon
Assignee: paul cannon
Priority: Trivial
With CASSANDRA-3726, cqlsh now formats some types of query result data to be
more human-readable, such as timestamps and hex data. The format of timestamps
and the precision of floating point values should be configurable by cqlshrc
and/or command line.
see the {{Shell.display_time_format}} and {{Shell.display_float_precision}}
attributes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3757) cqlsh: update syntax for tab completions
cqlsh: update syntax for tab completions Key: CASSANDRA-3757 URL: https://issues.apache.org/jira/browse/CASSANDRA-3757 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.0.0 Reporter: paul cannon Assignee: paul cannon Priority: Minor Several recent additions to CQL syntax have yet to be reflected in cqlsh's tab completion capability, such as CASSANDRA-3419, CASSANDRA-3374, and CASSANDRA-3523. Update those bits of syntax definition. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3633) update stress to support prepared statements
[
https://issues.apache.org/jira/browse/CASSANDRA-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189457#comment-13189457
]
Jonathan Ellis commented on CASSANDRA-3633:
---
What about https://github.com/eevans/cassandra/tree/3634.stress.bb ?
> update stress to support prepared statements
>
>
> Key: CASSANDRA-3633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3633
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
>Reporter: Eric Evans
>Assignee: Eric Evans
>Priority: Minor
> Labels: cql
> Fix For: 1.1
>
>
> The {{stress}} utility needs to be updated for testing prepared statements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3586) Add new SHOW command in CQL shell to list column families
[ https://issues.apache.org/jira/browse/CASSANDRA-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189466#comment-13189466 ] Jonathan Ellis commented on CASSANDRA-3586: --- committed > Add new SHOW command in CQL shell to list column families > -- > > Key: CASSANDRA-3586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3586 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Affects Versions: 1.0.6 >Reporter: Robin Schumacher >Assignee: paul cannon >Priority: Minor > Labels: cqlsh > Attachments: 3586.patch.txt > > > add command SHOW COLUMN FAMILIES to list all column families in a current > keyspace by name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[2/6] git commit: add DESC alias for DESCRIBE
add DESC alias for DESCRIBE patch by pcannon; reviewed by jbellis for CASSANDRA-3587 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fc610396 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fc610396 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fc610396 Branch: refs/heads/cassandra-1.0 Commit: fc6103966cbe90c96e75f4b52c10376b9df468d7 Parents: 95942f0 Author: paul cannon Authored: Thu Jan 19 12:02:13 2012 -0600 Committer: Jonathan Ellis Committed: Thu Jan 19 17:03:02 2012 -0600 -- bin/cqlsh |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc610396/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 8fe044c..2a18722 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -116,6 +116,7 @@ cqlhandling.commands_end_with_newline.update(( 'help', '?', 'describe', +'desc', 'show', 'assume', 'eof', @@ -134,7 +135,7 @@ cqlhandling.CqlRuleSet.append_rules(r''' | ; - ::= "DESCRIBE" ( "KEYSPACE" ksname=? + ::= ( "DESCRIBE" | "DESC" ) ( "KEYSPACE" ksname=? | "COLUMNFAMILY" cfname= | "COLUMNFAMILIES" | "SCHEMA" @@ -741,6 +742,8 @@ class Shell(cmd.Cmd): """ DESCRIBE [cqlsh only] +(DESC may be used as a shorthand.) + Outputs information about the connected Cassandra cluster, or about the data stored on it. Use in one of the following ways: @@ -798,6 +801,8 @@ class Shell(cmd.Cmd): elif what == 'schema': self.describe_schema() +do_desc = do_describe + def do_show(self, parsed): """ SHOW [cqlsh only]
[1/6] git commit: merge from 1.0
Updated Branches: refs/heads/cassandra-1.0 83119656a -> fc6103966 refs/heads/trunk 739848602 -> 91c45d445 merge from 1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/91c45d44 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/91c45d44 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/91c45d44 Branch: refs/heads/trunk Commit: 91c45d445c68e925122250d7443a4690ea4ecbed Parents: 7398486 fc61039 Author: Jonathan Ellis Authored: Thu Jan 19 17:04:29 2012 -0600 Committer: Jonathan Ellis Committed: Thu Jan 19 17:04:29 2012 -0600 -- CHANGES.txt |4 bin/cqlsh | 36 ++-- 2 files changed, 38 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/91c45d44/CHANGES.txt -- diff --cc CHANGES.txt index 4a4bf35,4688381..14a4efe --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,53 -1,7 +1,57 @@@ +1.1-dev + * avoid returning internal Cassandra classes over JMX (CASSANDRA-2805) + * add row-level isolation via SnapTree (CASSANDRA-2893) + * Optimize key count estimation when opening sstable on startup + (CASSANDRA-2988) + * multi-dc replication optimization supporting CL > ONE (CASSANDRA-3577) + * add command to stop compactions (CASSANDRA-1740, 3566, 3582) + * multithreaded streaming (CASSANDRA-3494) + * removed in-tree redhat spec (CASSANDRA-3567) + * "defragment" rows for name-based queries under STCS, again (CASSANDRA-2503) + * Recycle commitlog segments for improved performance + (CASSANDRA-3411, 3543, 3557, 3615) + * update size-tiered compaction to prioritize small tiers (CASSANDRA-2407) + * add message expiration logic to OutboundTcpConnection (CASSANDRA-3005) + * off-heap cache to use sun.misc.Unsafe instead of JNA (CASSANDRA-3271) + * EACH_QUORUM is only supported for writes (CASSANDRA-3272) + * replace compactionlock use in schema migration by checking CFS.isValid + (CASSANDRA-3116) + * recognize that "SELECT first ... *" isn't really "SELECT *" (CASSANDRA-3445) + * Use faster bytes comparison (CASSANDRA-3434) + * Bulk loader is no longer a fat client, (HADOOP) bulk load output format + (CASSANDRA-3045) + * remove assumption that keys and token are in bijection + (CASSANDRA-1034, 3574, 3604) + * always remove endpoints from delevery queue in HH (CASSANDRA-3546) + * fix race between cf flush and its 2ndary indexes flush (CASSANDRA-3547) + * fix potential race in AES when a repair fails (CASSANDRA-3548) + * Remove columns shadowed by a deleted container even when we cannot purge + (CASSANDRA-3538) + * Improve memtable slice iteration performance (CASSANDRA-3545) + * more efficient allocation of small bloom filters (CASSANDRA-3618) + * Use separate writer thread in SSTableSimpleUnsortedWriter (CASSANDRA-3619) + * fsync the directory after new sstable or commitlog segment are created (CASSANDRA-3250) + * fix minor issues reported by FindBugs (CASSANDRA-3658) + * global key/row caches (CASSANDRA-3143) + * optimize memtable iteration during range scan (CASSANDRA-3638) + * introduce 'crc_check_chance' in CompressionParameters to support + a checksum percentage checking chance similarly to read-repair (CASSANDRA-3611) + * a way to deactivate global key/row cache on per-CF basis (CASSANDRA-3667) + * fix LeveledCompactionStrategy broken because of generation pre-allocation + in LeveledManifest (CASSANDRA-3691) + * finer-grained control over data directories (CASSANDRA-2749) + * Fix ClassCastException during hinted handoff (CASSANDRA-3694) + * Upgrade Thrift to 0.7 (CASSANDRA-3213) + * Make stress.java insert operation to use microseconds (CASSANDRA-3725) + * Allows (internally) doing a range query with a limit of columns instead of + rows (CASSANDRA-3742) + * Allow rangeSlice queries to be start/end inclusive/exclusive (CASSANDRA-3749) + + + 1.0.8 + * (cqlsh) add DESCRIBE COLUMNFAMILIES (CASSANDRA-3586) + + 1.0.7 * fix regression in HH page size calculation (CASSANDRA-3624) * retry failed stream on IOException (CASSANDRA-3686) http://git-wip-us.apache.org/repos/asf/cassandra/blob/91c45d44/bin/cqlsh --
[3/6] git commit: add DESC alias for DESCRIBE
add DESC alias for DESCRIBE patch by pcannon; reviewed by jbellis for CASSANDRA-3587 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fc610396 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fc610396 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fc610396 Branch: refs/heads/trunk Commit: fc6103966cbe90c96e75f4b52c10376b9df468d7 Parents: 95942f0 Author: paul cannon Authored: Thu Jan 19 12:02:13 2012 -0600 Committer: Jonathan Ellis Committed: Thu Jan 19 17:03:02 2012 -0600 -- bin/cqlsh |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/fc610396/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 8fe044c..2a18722 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -116,6 +116,7 @@ cqlhandling.commands_end_with_newline.update(( 'help', '?', 'describe', +'desc', 'show', 'assume', 'eof', @@ -134,7 +135,7 @@ cqlhandling.CqlRuleSet.append_rules(r''' | ; - ::= "DESCRIBE" ( "KEYSPACE" ksname=? + ::= ( "DESCRIBE" | "DESC" ) ( "KEYSPACE" ksname=? | "COLUMNFAMILY" cfname= | "COLUMNFAMILIES" | "SCHEMA" @@ -741,6 +742,8 @@ class Shell(cmd.Cmd): """ DESCRIBE [cqlsh only] +(DESC may be used as a shorthand.) + Outputs information about the connected Cassandra cluster, or about the data stored on it. Use in one of the following ways: @@ -798,6 +801,8 @@ class Shell(cmd.Cmd): elif what == 'schema': self.describe_schema() +do_desc = do_describe + def do_show(self, parsed): """ SHOW [cqlsh only]
[5/6] git commit: cqlsh: add DESC COLUMNFAMILIES to show cf names
cqlsh: add DESC COLUMNFAMILIES to show cf names
as opposed to DESCRIBE KEYSPACE, which shows all columnfamilies but
includes all their column definitions and options, which is usually a
lot of output.
patch by pcannon; reviewed by jbellis for CASSANDRA-3586
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/95942f02
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/95942f02
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/95942f02
Branch: refs/heads/cassandra-1.0
Commit: 95942f0221240e47e950a387a440b4dbe7dada65
Parents: 8311965
Author: paul cannon
Authored: Thu Jan 19 14:23:56 2012 -0600
Committer: Jonathan Ellis
Committed: Thu Jan 19 17:02:36 2012 -0600
--
CHANGES.txt |4
bin/cqlsh | 29 -
2 files changed, 32 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/95942f02/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d3919d7..4688381 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,7 @@
+1.0.8
+ * (cqlsh) add DESCRIBE COLUMNFAMILIES (CASSANDRA-3586)
+
+
1.0.7
* fix regression in HH page size calculation (CASSANDRA-3624)
* retry failed stream on IOException (CASSANDRA-3686)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/95942f02/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index 0f02a0c..8fe044c 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -136,6 +136,7 @@ cqlhandling.CqlRuleSet.append_rules(r'''
::= "DESCRIBE" ( "KEYSPACE" ksname=?
| "COLUMNFAMILY" cfname=
+ | "COLUMNFAMILIES"
| "SCHEMA"
| "CLUSTER" )
;
@@ -205,6 +206,9 @@ def complete_assume_col(ctxt, cqlsh):
class NoKeyspaceError(Exception):
pass
+class KeyspaceNotFound(Exception):
+pass
+
def trim_if_present(s, prefix):
if s.startswith(prefix):
return s[len(prefix):]
@@ -697,6 +701,22 @@ class Shell(cmd.Cmd):
self.print_recreate_columnfamily(self.get_columnfamily(cfname))
self.printout('')
+def describe_columnfamilies(self, ksname):
+if ksname is None:
+for k in self.get_keyspaces():
+self.printout('Keyspace %s' % (k.name,))
+self.printout('-%s\n' % ('-' * len(k.name)))
+cmd.Cmd.columnize(self, [c.name for c in k.cf_defs])
+self.printout('')
+else:
+try:
+names = self.get_columnfamily_names(ksname)
+except cql.cassandra.ttypes.NotFoundException:
+raise KeyspaceNotFound('Keyspace %s not found.' % (ksname,))
+self.printout('')
+cmd.Cmd.columnize(self, names)
+self.printout('')
+
def describe_cluster(self):
self.printout('Cluster: %s' % self.get_cluster_name())
p = trim_if_present(self.get_partitioner(),
'org.apache.cassandra.dht.')
@@ -724,7 +744,7 @@ class Shell(cmd.Cmd):
Outputs information about the connected Cassandra cluster, or about
the data stored on it. Use in one of the following ways:
-DESCRIBE KEYSPACE
+DESCRIBE KEYSPACE []
Output CQL commands that could be used to recreate the given
keyspace, and the columnfamilies in it. In some cases, as the CQL
@@ -734,6 +754,11 @@ class Shell(cmd.Cmd):
The '' argument may be omitted when using a non-system
keyspace; in that case, the current keyspace will be described.
+DESCRIBE COLUMNFAMILIES
+
+ Output the names of all column families in the current keyspace, or
+ in all keyspaces if there is no current keyspace.
+
DESCRIBE COLUMNFAMILY
Output CQL commands that could be used to recreate the given
@@ -766,6 +791,8 @@ class Shell(cmd.Cmd):
elif what == 'columnfamily':
cfname = cql_dequote(parsed.get_binding('cfname'))
self.describe_columnfamily(cfname)
+elif what == 'columnfamilies':
+self.describe_columnfamilies(self.current_keyspace)
elif what == 'cluster':
self.describe_cluster()
elif what == 'schema':
[4/6] git commit: cqlsh: add DESC COLUMNFAMILIES to show cf names
cqlsh: add DESC COLUMNFAMILIES to show cf names
as opposed to DESCRIBE KEYSPACE, which shows all columnfamilies but
includes all their column definitions and options, which is usually a
lot of output.
patch by pcannon; reviewed by jbellis for CASSANDRA-3586
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/95942f02
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/95942f02
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/95942f02
Branch: refs/heads/trunk
Commit: 95942f0221240e47e950a387a440b4dbe7dada65
Parents: 8311965
Author: paul cannon
Authored: Thu Jan 19 14:23:56 2012 -0600
Committer: Jonathan Ellis
Committed: Thu Jan 19 17:02:36 2012 -0600
--
CHANGES.txt |4
bin/cqlsh | 29 -
2 files changed, 32 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/95942f02/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d3919d7..4688381 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,3 +1,7 @@
+1.0.8
+ * (cqlsh) add DESCRIBE COLUMNFAMILIES (CASSANDRA-3586)
+
+
1.0.7
* fix regression in HH page size calculation (CASSANDRA-3624)
* retry failed stream on IOException (CASSANDRA-3686)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/95942f02/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index 0f02a0c..8fe044c 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -136,6 +136,7 @@ cqlhandling.CqlRuleSet.append_rules(r'''
::= "DESCRIBE" ( "KEYSPACE" ksname=?
| "COLUMNFAMILY" cfname=
+ | "COLUMNFAMILIES"
| "SCHEMA"
| "CLUSTER" )
;
@@ -205,6 +206,9 @@ def complete_assume_col(ctxt, cqlsh):
class NoKeyspaceError(Exception):
pass
+class KeyspaceNotFound(Exception):
+pass
+
def trim_if_present(s, prefix):
if s.startswith(prefix):
return s[len(prefix):]
@@ -697,6 +701,22 @@ class Shell(cmd.Cmd):
self.print_recreate_columnfamily(self.get_columnfamily(cfname))
self.printout('')
+def describe_columnfamilies(self, ksname):
+if ksname is None:
+for k in self.get_keyspaces():
+self.printout('Keyspace %s' % (k.name,))
+self.printout('-%s\n' % ('-' * len(k.name)))
+cmd.Cmd.columnize(self, [c.name for c in k.cf_defs])
+self.printout('')
+else:
+try:
+names = self.get_columnfamily_names(ksname)
+except cql.cassandra.ttypes.NotFoundException:
+raise KeyspaceNotFound('Keyspace %s not found.' % (ksname,))
+self.printout('')
+cmd.Cmd.columnize(self, names)
+self.printout('')
+
def describe_cluster(self):
self.printout('Cluster: %s' % self.get_cluster_name())
p = trim_if_present(self.get_partitioner(),
'org.apache.cassandra.dht.')
@@ -724,7 +744,7 @@ class Shell(cmd.Cmd):
Outputs information about the connected Cassandra cluster, or about
the data stored on it. Use in one of the following ways:
-DESCRIBE KEYSPACE
+DESCRIBE KEYSPACE []
Output CQL commands that could be used to recreate the given
keyspace, and the columnfamilies in it. In some cases, as the CQL
@@ -734,6 +754,11 @@ class Shell(cmd.Cmd):
The '' argument may be omitted when using a non-system
keyspace; in that case, the current keyspace will be described.
+DESCRIBE COLUMNFAMILIES
+
+ Output the names of all column families in the current keyspace, or
+ in all keyspaces if there is no current keyspace.
+
DESCRIBE COLUMNFAMILY
Output CQL commands that could be used to recreate the given
@@ -766,6 +791,8 @@ class Shell(cmd.Cmd):
elif what == 'columnfamily':
cfname = cql_dequote(parsed.get_binding('cfname'))
self.describe_columnfamily(cfname)
+elif what == 'columnfamilies':
+self.describe_columnfamilies(self.current_keyspace)
elif what == 'cluster':
self.describe_cluster()
elif what == 'schema':
[6/6] git commit: 0001-CASSANDRA-3736-remove-token-from-systable-when-replaced
0001-CASSANDRA-3736-remove-token-from-systable-when-replaced
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/83119656
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/83119656
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/83119656
Branch: refs/heads/trunk
Commit: 83119656a2f54db064ec1479eddb826d8fcaf7de
Parents: 181022b
Author: Vijay Parthasarathy
Authored: Thu Jan 19 13:04:21 2012 -0800
Committer: Vijay Parthasarathy
Committed: Thu Jan 19 13:04:21 2012 -0800
--
src/java/org/apache/cassandra/db/SystemTable.java |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83119656/src/java/org/apache/cassandra/db/SystemTable.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemTable.java
b/src/java/org/apache/cassandra/db/SystemTable.java
index 8f1adfc..c831382 100644
--- a/src/java/org/apache/cassandra/db/SystemTable.java
+++ b/src/java/org/apache/cassandra/db/SystemTable.java
@@ -139,7 +139,10 @@ public class SystemTable
public static synchronized void updateToken(InetAddress ep, Token token)
{
if (ep == FBUtilities.getLocalAddress())
+{
+removeToken(token);
return;
+}
IPartitioner p = StorageService.getPartitioner();
ColumnFamily cf = ColumnFamily.create(Table.SYSTEM_TABLE, STATUS_CF);
cf.addColumn(new Column(p.getTokenFactory().toByteArray(token),
ByteBuffer.wrap(ep.getAddress()), System.currentTimeMillis()));
[jira] [Updated] (CASSANDRA-3668) Performance of sstableloader is affected in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3668: -- Reviewer: scode (was: jbellis) > Performance of sstableloader is affected in 1.0.x > - > > Key: CASSANDRA-3668 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 1.0.0 >Reporter: Manish Zope >Assignee: Yuki Morishita >Priority: Minor > Labels: streaming > Fix For: 1.1 > > Attachments: 0001-Allow-multiple-connection-in-StreamInSession.patch, > 0002-Allow-concurrent-stream-in-StreamOutSession.patch, > 0003-Add-threads-option-to-sstableloader.patch, > 3688-reply_before_closing_writer.txt, sstable-loader performance.txt > > Original Estimate: 48h > Remaining Estimate: 48h > > One of my colleague had reported the bug regarding the degraded performance > of the sstable generator and sstable loader. > ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 > As stated in above issue generator performance is rectified but performance > of the sstableloader is still an issue. > 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the > problem with sstableloader still exists. > So opening other issue so that sstbleloader problem should not go unnoticed. > FYI : We have tested the generator part with the patch given in 3589.Its > Working fine. > Please let us know if you guys require further inputs from our side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Fix test compilation after 3689
Updated Branches:
refs/heads/trunk 91c45d445 -> e86469ee0
Fix test compilation after 3689
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e86469ee
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e86469ee
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e86469ee
Branch: refs/heads/trunk
Commit: e86469ee058fb73acebbae5f0ff64e5eae55e613
Parents: 91c45d4
Author: Brandon Williams
Authored: Thu Jan 19 17:34:44 2012 -0600
Committer: Brandon Williams
Committed: Thu Jan 19 17:35:12 2012 -0600
--
test/unit/org/apache/cassandra/SchemaLoader.java |6 +++---
.../cassandra/db/marshal/CompositeTypeTest.java|2 +-
.../db/marshal/DynamicCompositeTypeTest.java |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e86469ee/test/unit/org/apache/cassandra/SchemaLoader.java
--
diff --git a/test/unit/org/apache/cassandra/SchemaLoader.java
b/test/unit/org/apache/cassandra/SchemaLoader.java
index 198cb5f..59c8ac5 100644
--- a/test/unit/org/apache/cassandra/SchemaLoader.java
+++ b/test/unit/org/apache/cassandra/SchemaLoader.java
@@ -92,11 +92,11 @@ public class SchemaLoader
ColumnFamilyType su = ColumnFamilyType.Super;
AbstractType bytes = BytesType.instance;
-AbstractType composite = CompositeType.getInstance(Arrays.asList(new
AbstractType[]{BytesType.instance, TimeUUIDType.instance,
IntegerType.instance}));
-Map aliases = new HashMap();
+AbstractType composite =
CompositeType.getInstance(Arrays.asList(new
AbstractType[]{BytesType.instance, TimeUUIDType.instance,
IntegerType.instance}));
+Map> aliases = new HashMap>();
aliases.put((byte)'b', BytesType.instance);
aliases.put((byte)'t', TimeUUIDType.instance);
-AbstractType dynamicComposite =
DynamicCompositeType.getInstance(aliases);
+AbstractType dynamicComposite =
DynamicCompositeType.getInstance(aliases);
// these column definitions will will be applied to the jdbc utf and
integer column familes respectively.
Map integerColumn = new
HashMap();
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e86469ee/test/unit/org/apache/cassandra/db/marshal/CompositeTypeTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/marshal/CompositeTypeTest.java
b/test/unit/org/apache/cassandra/db/marshal/CompositeTypeTest.java
index 284c98d..fa2e876 100644
--- a/test/unit/org/apache/cassandra/db/marshal/CompositeTypeTest.java
+++ b/test/unit/org/apache/cassandra/db/marshal/CompositeTypeTest.java
@@ -42,7 +42,7 @@ public class CompositeTypeTest extends CleanupHelper
private static final CompositeType comparator;
static
{
-List subComparators = new ArrayList();
+List> subComparators = new
ArrayList>();
subComparators.add(BytesType.instance);
subComparators.add(TimeUUIDType.instance);
subComparators.add(IntegerType.instance);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e86469ee/test/unit/org/apache/cassandra/db/marshal/DynamicCompositeTypeTest.java
--
diff --git
a/test/unit/org/apache/cassandra/db/marshal/DynamicCompositeTypeTest.java
b/test/unit/org/apache/cassandra/db/marshal/DynamicCompositeTypeTest.java
index e453705..f3b0ec7 100644
--- a/test/unit/org/apache/cassandra/db/marshal/DynamicCompositeTypeTest.java
+++ b/test/unit/org/apache/cassandra/db/marshal/DynamicCompositeTypeTest.java
@@ -42,7 +42,7 @@ public class DynamicCompositeTypeTest extends CleanupHelper
private static final DynamicCompositeType comparator;
static
{
-Map aliases = new HashMap();
+Map> aliases = new HashMap>();
aliases.put((byte)'b', BytesType.instance);
aliases.put((byte)'t', TimeUUIDType.instance);
comparator = DynamicCompositeType.getInstance(aliases);
[jira] [Updated] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1391: -- Attachment: 1391-rebased.txt rebased patch attached. comments: - validateSchemaAgreement is unnecessary now right? - the old Migration infrastructure feels unnecessarily heavyweight now. Can we move the validation into the CassandraServer methods, and then just invoke a MigrationHelper method from a runnable there? - should we snapshot the old avro schema before nuking it? - SystemTable.dropOldSchemaTables is a no-op. I think we can take this out entirely since loadSchema/fromAvro takes care of it? - Can you add a comment describing the layout of the new schema CFs to defstable or systemtable? - I'd prefer to leave the low level slicing / deserialize in SystemTable class instead of scattered between Schema and DefsTable > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > Attachments: 1391-rebased.txt, CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189511#comment-13189511 ] Pavel Yaskevich commented on CASSANDRA-1391: bq. validateSchemaAgreement is unnecessary now right? I think it's still a good idea to validate if all nodes have the same schema. bq. the old Migration infrastructure feels unnecessarily heavyweight now. Can we move the validation into the CassandraServer methods, and then just invoke a MigrationHelper method from a runnable there? I tried to optimize it as much as possible because I still think that there is a reason to keep it because it encapsulates all announce, apply and validation logic pretty good. I tried to move validation and stuff to the CassandraServer but it shows itself as hardly readable and heavy-weight. bq. should we snapshot the old avro schema before nuking it? MigrationHelper.dropColumnFamily that I call to remove Migrations and Schema CFs makes snapshot of the data. bq. SystemTable.dropOldSchemaTables is a no-op. I think we can take this out entirely since loadSchema/fromAvro takes care of it? Ugh, I forgot to remove it from the final version of the patch, sorry... bq. Can you add a comment describing the layout of the new schema CFs to defstable or systemtable? Sure, I will do that in SystemTable. bq. I'd prefer to leave the low level slicing / deserialize in SystemTable class instead of scattered between Schema and DefsTable Sure, I will move serialize and serialized methods from Schema to SystemTable, plus DefsTable.readSchemaRow and getSchema also go there. > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > Attachments: 1391-rebased.txt, CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3726) cqlsh and cassandra-cli show keys differently for data created via stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189512#comment-13189512
]
Jonathan Ellis commented on CASSANDRA-3726:
---
Can you rebase on top of 1.0? I think 3586/3587 conflict.
> cqlsh and cassandra-cli show keys differently for data created via stress tool
> --
>
> Key: CASSANDRA-3726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3726
> Project: Cassandra
> Issue Type: Bug
>Reporter: Cathy Daw
>Assignee: paul cannon
>Priority: Minor
> Attachments: 3726.patch.txt
>
>
> {code}
> // Run: stress --operation=INSERT --num-keys=5 --columns=2
> --consistency-level=QUORUM --column-size=1 --threads=1 --replication-factor=1
> --nodes=localhost
> // cqlsh
> cqlsh:Keyspace1> select * from Standard1;
> KEY,3 | C0,c | C1,c |
> KEY,0 |
> KEY,2 | C0,c | C1,c |
> KEY,1 | C0,c | C1,c |
> KEY,4 | C0,c | C1,c |
> cqlsh:Keyspace1> describe columnfamily Standard1;
> CREATE COLUMNFAMILY Standard1 (
> KEY blob PRIMARY KEY
> ) WITH
> comment='' AND
> comparator=ascii AND
> row_cache_provider='ConcurrentLinkedHashCacheProvider' AND
> key_cache_size=20.00 AND
> row_cache_size=0.00 AND
> read_repair_chance=1.00 AND
> gc_grace_seconds=864000 AND
> default_validation=blob AND
> min_compaction_threshold=4 AND
> max_compaction_threshold=32 AND
> row_cache_save_period_in_seconds=0 AND
> key_cache_save_period_in_seconds=14400 AND
> replicate_on_write=True;
> // cassandra-cli
> [default@Keyspace1] list Standard1;
> Using default limit of 100
> ---
> RowKey: 33
> => (column=C0, value=63, timestamp=1326259960705)
> => (column=C1, value=63, timestamp=1326259960705)
> ---
> RowKey: 30
> ---
> RowKey: 32
> => (column=C0, value=63, timestamp=1326259960704)
> => (column=C1, value=63, timestamp=1326259960704)
> ---
> RowKey: 31
> => (column=C0, value=63, timestamp=1326259960704)
> => (column=C1, value=63, timestamp=1326259960704)
> ---
> RowKey: 34
> => (column=C0, value=63, timestamp=1326259960705)
> => (column=C1, value=63, timestamp=1326259960705)
> [default@Keyspace1] describe Standard1;
> ColumnFamily: Standard1
> Key Validation Class: org.apache.cassandra.db.marshal.BytesType
> Default column value validator:
> org.apache.cassandra.db.marshal.BytesType
> Columns sorted by: org.apache.cassandra.db.marshal.AsciiType
> Row cache size / save period in seconds / keys to save : 0.0/0/all
> Row Cache Provider:
> org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider
> Key cache size / save period in seconds: 20.0/14400
> GC grace seconds: 864000
> Compaction min/max thresholds: 4/32
> Read repair chance: 1.0
> Replicate on write: true
> Built indexes: []
> Compaction Strategy:
> org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3758) parallel compaction hang (on large rows?)
parallel compaction hang (on large rows?) - Key: CASSANDRA-3758 URL: https://issues.apache.org/jira/browse/CASSANDRA-3758 Project: Cassandra Issue Type: Bug Reporter: Jackson Chung it is observed that: nodetool -h 127.0.0.1 -p 8080 compactionstats pending tasks: 1 compaction type keyspace column family bytes compacted bytes total progress Compaction SyncCoreComputedContactNetworks 119739938 0 n/a and that is not moving (ie the bytes compacted never increase, the bytes total stay 0). this is probably going to be difficult to reproduce, as the problem is observed when compacting 15 large sstables (total ~300G). attaching the thread dumps (along with logs), when such happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3758) parallel compaction hang (on large rows?)
[ https://issues.apache.org/jira/browse/CASSANDRA-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jackson Chung updated CASSANDRA-3758: - Attachment: cassandra.log.zip ps: i had a problem unzip it originally, but getaround by gunzip -c [file] > /path/to/file .. just in case > parallel compaction hang (on large rows?) > - > > Key: CASSANDRA-3758 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3758 > Project: Cassandra > Issue Type: Bug >Reporter: Jackson Chung > Attachments: cassandra.log.zip > > > it is observed that: > nodetool -h 127.0.0.1 -p 8080 compactionstats > pending tasks: 1 > compaction type keyspace column family bytes compacted bytes total progress > Compaction SyncCoreComputedContactNetworks 119739938 0 n/a > and that is not moving (ie the bytes compacted never increase, the bytes > total stay 0). > this is probably going to be difficult to reproduce, as the problem is > observed when compacting 15 large sstables (total ~300G). > attaching the thread dumps (along with logs), when such happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3758) parallel compaction hang (on large rows?)
[ https://issues.apache.org/jira/browse/CASSANDRA-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jackson Chung reassigned CASSANDRA-3758: Assignee: Sylvain Lebresne > parallel compaction hang (on large rows?) > - > > Key: CASSANDRA-3758 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3758 > Project: Cassandra > Issue Type: Bug >Reporter: Jackson Chung >Assignee: Sylvain Lebresne > Attachments: cassandra.log.zip > > > it is observed that: > nodetool -h 127.0.0.1 -p 8080 compactionstats > pending tasks: 1 > compaction type keyspace column family bytes compacted bytes total progress > Compaction SyncCoreComputedContactNetworks 119739938 0 n/a > and that is not moving (ie the bytes compacted never increase, the bytes > total stay 0). > this is probably going to be difficult to reproduce, as the problem is > observed when compacting 15 large sstables (total ~300G). > attaching the thread dumps (along with logs), when such happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3468) SStable data corruption in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189555#comment-13189555 ] Joaquin Casares commented on CASSANDRA-3468: Testing details on said system: 1) Row cache enabled, no jna - the problem did not occur, 2) Row cache enabled, jna enabled, with SerializingCacheProvider - problem reproduced, 3) Row cache enabled, jna enabled, with ConcurrentLinkedHashCacheProvider - problem did not occur. > SStable data corruption in 1.0.x > > > Key: CASSANDRA-3468 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3468 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 > Environment: RHEL 6 running Cassandra 1.0.x. >Reporter: Terry Cumaranatunge > Labels: patch > > We have noticed several instances of sstable corruptions in 1.0.x. This has > occurred in 1.0.0-rcx and 1.0.0 and 1.0.1. It has happened on multiple nodes > and multiple hosts with different disks, so this is the reason the software > is suspected at this time. The file system used is XFS, but no resets or any > type of failure scenarios have been run to create the problem. We were > basically running under load and every so often, we see that the sstable gets > corrupted and compaction stops on that node. > I will attach the relevant sstable files if it lets me do that when I create > this ticket. > ERROR [CompactionExecutor:23] 2011-10-27 11:14:09,309 PrecompactedRow.java > (line 119) Skipping row DecoratedKey(128013852116656632841539411062933532114, > 37303730303138313533) in > /var/lib/cassandra/data/MSA/participants-h-8688-Data.db > java.io.EOFException > at java.io.RandomAccessFile.readFully(RandomAccessFile.java:399) > at java.io.RandomAccessFile.readFully(RandomAccessFile.java:377) > at > org.apache.cassandra.utils.BytesReadTracker.readFully(BytesReadTracker.java:95) > at > org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:388) > at > org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:350) > at > org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:96) > at > org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:36) > at > org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:143) > at > org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:231) > at > org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:115) > at > org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:102) > at > org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:127) > at > org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:102) > at > org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:87) > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:116) > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) > at > com.google.common.collect.Iterators$7.computeNext(Iterators.java:614) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) > at > org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:179) > at > org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:47) > at > org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:131) > at > org.apache.cassandra.db.compaction.CompactionManager$1.call(CompactionManager.java:114) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > This was Sylvain's analysis: > I don't have much better news. Basically it seems the 2 last MB of the file > are complete garbage (which also explain the mmap error btw). And given where > the corruption actually starts, it suggests that it's either
[jira] [Commented] (CASSANDRA-3743) Lower memory consumption used by index sampling
[ https://issues.apache.org/jira/browse/CASSANDRA-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189561#comment-13189561 ] Radim Kolar commented on CASSANDRA-3743: Are you going to fix these codestyle errors? its just few lines > Lower memory consumption used by index sampling > --- > > Key: CASSANDRA-3743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3743 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0 >Reporter: Radim Kolar >Assignee: Radim Kolar > Labels: optimization > Fix For: 1.1 > > Attachments: cassandra-3743.txt > > > currently j.o.a.c.io.sstable.indexsummary is implemented as ArrayList of > KeyPosition (RowPosition key, long offset)i propose to change it to: > RowPosition keys[] > long offsets[] > and use standard binary search on it. This will lower number of java objects > used per entry from 2 (KeyPosition + RowPosition) to 1 (RowPosition). > For building these arrays convenient ArrayList class can be used and then > call to .toArray() on it. > This is very important because index sampling uses a lot of memory on nodes > with billions rows -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3743) Lower memory consumption used by index sampling
[ https://issues.apache.org/jira/browse/CASSANDRA-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189569#comment-13189569 ] Jonathan Ellis commented on CASSANDRA-3743: --- Please submit an updated patch against 1.1, Radim. > Lower memory consumption used by index sampling > --- > > Key: CASSANDRA-3743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3743 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0 >Reporter: Radim Kolar >Assignee: Radim Kolar > Labels: optimization > Fix For: 1.1 > > Attachments: cassandra-3743.txt > > > currently j.o.a.c.io.sstable.indexsummary is implemented as ArrayList of > KeyPosition (RowPosition key, long offset)i propose to change it to: > RowPosition keys[] > long offsets[] > and use standard binary search on it. This will lower number of java objects > used per entry from 2 (KeyPosition + RowPosition) to 1 (RowPosition). > For building these arrays convenient ArrayList class can be used and then > call to .toArray() on it. > This is very important because index sampling uses a lot of memory on nodes > with billions rows -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2893) Add row-level isolation
[
https://issues.apache.org/jira/browse/CASSANDRA-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189579#comment-13189579
]
Cathy Daw commented on CASSANDRA-2893:
--
I have a question about the test case attached: row_isolation_test.py
Based on how the inserts or deletes are constructed, if I continually poll the
column count of the test key, while a large mutation is being applied, the only
value I should see if this transaction is isolated is 0, 100 or 200k.
Otherwise, I print an error message (this is my version of a 'diff').
Running this script on different versions, I saw the following behavior. I am
not sure if the experiment is wrong, or if I have a bug because my expectation
would be to see no diffs (or messages from the 2nd thread).
* 0.8.6: incremental column counts on the large column delete and insert
(expected)
* 1.0.7: incremental column counts on the large column delete (expected to see
insert diffs as well)
* 1.0 branch: incremental column counts on the large column delete (no diffs
expected)
* trunk: incremental column counts on the large column delete (no diffs
expected)
*0.8.9 test run*
{code}
Thread 1: Insert to 100 - Start
Thread 1: Insert End - Expect # columns = 100
Thread 1: Insert to 200k - Start
Thread 1: Insert End - Expect # columns = 20
Thread 1: Remove 200k - Start
--- Thread 2: Mismatch Column Count. Current # columns: 184628 Current Test:
test3 - remove 200k
--- Thread 2: Mismatch Column Count. Current # columns: 44765 Current Test:
test3 - remove 200k
Thread 1: Remove End - Expect # columns = 0
Thread 1: Insert to 100 - Start
Thread 1: Insert End - Expect # columns = 100
Thread 1: Remove 100 - Start
Thread 1: Remove End - Expect # columns = 0
Thread 1: Insert 100k to 300k - Start
--- Thread 2: Mismatch Column Count. Current # columns: 569 Current Test:
test5 - insert 200k
Thread 1: Insert End - Expect # columns = 20
{code}
> Add row-level isolation
> ---
>
> Key: CASSANDRA-2893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2893
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 1.1
>
> Attachments: 0001-Move-deletion-infos-into-ISortedColumns-v2.patch,
> 0001-Move-deletion-infos-into-ISortedColumns.patch,
> 0002-Make-memtable-use-CF.addAll-v2.patch,
> 0002-Make-memtable-use-CF.addAll.patch,
> 0003-Add-AtomicSortedColumn-and-snapTree-v2.patch,
> 0003-Add-AtomicSortedColumn-and-snapTree.patch, latency-plain.svg,
> latency.svg, row_isolation_test.py, snaptree-0.1-SNAPSHOT.jar
>
>
> This could be done using an the atomic ConcurrentMap operations from the
> Memtable and something like http://code.google.com/p/pcollections/ to replace
> the ConcurrentSkipListMap in ThreadSafeSortedColumns. The trick is that
> pcollections does not provide a SortedMap, so we probably need to write our
> own.
> Googling [persistent sortedmap] I found
> http://code.google.com/p/actord/source/browse/trunk/actord/src/main/scala/ff/collection
> (in scala) and http://clojure.org/data_structures#Data Structures-Maps.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2893) Add row-level isolation
[ https://issues.apache.org/jira/browse/CASSANDRA-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cathy Daw updated CASSANDRA-2893: - Attachment: row_isolation_test.py > Add row-level isolation > --- > > Key: CASSANDRA-2893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2893 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.1 > > Attachments: 0001-Move-deletion-infos-into-ISortedColumns-v2.patch, > 0001-Move-deletion-infos-into-ISortedColumns.patch, > 0002-Make-memtable-use-CF.addAll-v2.patch, > 0002-Make-memtable-use-CF.addAll.patch, > 0003-Add-AtomicSortedColumn-and-snapTree-v2.patch, > 0003-Add-AtomicSortedColumn-and-snapTree.patch, latency-plain.svg, > latency.svg, row_isolation_test.py, snaptree-0.1-SNAPSHOT.jar > > > This could be done using an the atomic ConcurrentMap operations from the > Memtable and something like http://code.google.com/p/pcollections/ to replace > the ConcurrentSkipListMap in ThreadSafeSortedColumns. The trick is that > pcollections does not provide a SortedMap, so we probably need to write our > own. > Googling [persistent sortedmap] I found > http://code.google.com/p/actord/source/browse/trunk/actord/src/main/scala/ff/collection > (in scala) and http://clojure.org/data_structures#Data Structures-Maps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2893) Add row-level isolation
[ https://issues.apache.org/jira/browse/CASSANDRA-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189586#comment-13189586 ] Brandon Williams commented on CASSANDRA-2893: - This is only in 1.1, are you seeing problems in trunk? > Add row-level isolation > --- > > Key: CASSANDRA-2893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2893 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.1 > > Attachments: 0001-Move-deletion-infos-into-ISortedColumns-v2.patch, > 0001-Move-deletion-infos-into-ISortedColumns.patch, > 0002-Make-memtable-use-CF.addAll-v2.patch, > 0002-Make-memtable-use-CF.addAll.patch, > 0003-Add-AtomicSortedColumn-and-snapTree-v2.patch, > 0003-Add-AtomicSortedColumn-and-snapTree.patch, latency-plain.svg, > latency.svg, row_isolation_test.py, snaptree-0.1-SNAPSHOT.jar > > > This could be done using an the atomic ConcurrentMap operations from the > Memtable and something like http://code.google.com/p/pcollections/ to replace > the ConcurrentSkipListMap in ThreadSafeSortedColumns. The trick is that > pcollections does not provide a SortedMap, so we probably need to write our > own. > Googling [persistent sortedmap] I found > http://code.google.com/p/actord/source/browse/trunk/actord/src/main/scala/ff/collection > (in scala) and http://clojure.org/data_structures#Data Structures-Maps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2893) Add row-level isolation
[ https://issues.apache.org/jira/browse/CASSANDRA-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189590#comment-13189590 ] Cathy Daw commented on CASSANDRA-2893: -- I see the issue with the delete columns on trunk. I guess what is confusing me is that I only see an issue inserting columns on 0.8.9, and the insert columns doesn't reproduce on 1.0.x or trunk. > Add row-level isolation > --- > > Key: CASSANDRA-2893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2893 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.1 > > Attachments: 0001-Move-deletion-infos-into-ISortedColumns-v2.patch, > 0001-Move-deletion-infos-into-ISortedColumns.patch, > 0002-Make-memtable-use-CF.addAll-v2.patch, > 0002-Make-memtable-use-CF.addAll.patch, > 0003-Add-AtomicSortedColumn-and-snapTree-v2.patch, > 0003-Add-AtomicSortedColumn-and-snapTree.patch, latency-plain.svg, > latency.svg, row_isolation_test.py, snaptree-0.1-SNAPSHOT.jar > > > This could be done using an the atomic ConcurrentMap operations from the > Memtable and something like http://code.google.com/p/pcollections/ to replace > the ConcurrentSkipListMap in ThreadSafeSortedColumns. The trick is that > pcollections does not provide a SortedMap, so we probably need to write our > own. > Googling [persistent sortedmap] I found > http://code.google.com/p/actord/source/browse/trunk/actord/src/main/scala/ff/collection > (in scala) and http://clojure.org/data_structures#Data Structures-Maps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3468) SStable data corruption in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3468: -- Attachment: 3468-assert.txt Andy confirms that supercolumns are not involved. I do note that the stacktrace corresponds to a counter column in 1.0.0. We've had several counter-related bug fixes since then. (If you're NOT using counters, then the corruption must have happened mid-column, which would be interesting.) Patch adding more assertions to make sure we're not reading or writing to unallocated native memory attached. Can you test JNA + SerializingCache with 1.0.7 + this patch? I'd like to see if there are any assertion or other error messages before compaction EOFs. One other thing to try: turn on snapshot_before_compaction in cassandra.yaml. Then, when you have a compaction or scrub error out, check the logs to see where that corrupt sstable came from. If a freshly flushed sstable is corrupt, that's going to narrow down our search vs corruption coming from a cached row of an existing sstable. (As an optimization, compaction will use a cached version of the row if one is present, instead of re-reading its sources from disk.) > SStable data corruption in 1.0.x > > > Key: CASSANDRA-3468 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3468 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0 > Environment: RHEL 6 running Cassandra 1.0.x. >Reporter: Terry Cumaranatunge > Labels: patch > Attachments: 3468-assert.txt > > > We have noticed several instances of sstable corruptions in 1.0.x. This has > occurred in 1.0.0-rcx and 1.0.0 and 1.0.1. It has happened on multiple nodes > and multiple hosts with different disks, so this is the reason the software > is suspected at this time. The file system used is XFS, but no resets or any > type of failure scenarios have been run to create the problem. We were > basically running under load and every so often, we see that the sstable gets > corrupted and compaction stops on that node. > I will attach the relevant sstable files if it lets me do that when I create > this ticket. > ERROR [CompactionExecutor:23] 2011-10-27 11:14:09,309 PrecompactedRow.java > (line 119) Skipping row DecoratedKey(128013852116656632841539411062933532114, > 37303730303138313533) in > /var/lib/cassandra/data/MSA/participants-h-8688-Data.db > java.io.EOFException > at java.io.RandomAccessFile.readFully(RandomAccessFile.java:399) > at java.io.RandomAccessFile.readFully(RandomAccessFile.java:377) > at > org.apache.cassandra.utils.BytesReadTracker.readFully(BytesReadTracker.java:95) > at > org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:388) > at > org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:350) > at > org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:96) > at > org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:36) > at > org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:143) > at > org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:231) > at > org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:115) > at > org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:102) > at > org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:127) > at > org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:102) > at > org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:87) > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:116) > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) > at > com.google.common.collect.Iterators$7.computeNext(Iterators.java:614) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) > at > org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:179) > at > org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:47) > at > org.apache.cassan
[jira] [Commented] (CASSANDRA-3743) Lower memory consumption used by index sampling
[ https://issues.apache.org/jira/browse/CASSANDRA-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189629#comment-13189629 ] Vijay commented on CASSANDRA-3743: -- Wondering if we can use DecoratedKey[] instead of ArrayList in the attached patch... Just my 2 cents (I noticed this while doing another patch). > Lower memory consumption used by index sampling > --- > > Key: CASSANDRA-3743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3743 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0 >Reporter: Radim Kolar >Assignee: Radim Kolar > Labels: optimization > Fix For: 1.1 > > Attachments: cassandra-3743.txt > > > currently j.o.a.c.io.sstable.indexsummary is implemented as ArrayList of > KeyPosition (RowPosition key, long offset)i propose to change it to: > RowPosition keys[] > long offsets[] > and use standard binary search on it. This will lower number of java objects > used per entry from 2 (KeyPosition + RowPosition) to 1 (RowPosition). > For building these arrays convenient ArrayList class can be used and then > call to .toArray() on it. > This is very important because index sampling uses a lot of memory on nodes > with billions rows -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2392) Saving IndexSummaries to disk
[ https://issues.apache.org/jira/browse/CASSANDRA-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2392: - Attachment: 0002-save-summaries-to-disk-v2.patch Hi Pavel, Plz find the attached patch. 1) Renamed and done recommended changes. Exempt we have all the in-memory data-structures in one file instead of multiple files. They are handled differently and will be kind of throw away data so we can regenerate it. 2) I do see Keycache working in my tests... 3) the change is only on 0002 and 0001 remains the same. Thanks! > Saving IndexSummaries to disk > - > > Key: CASSANDRA-2392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2392 > Project: Cassandra > Issue Type: Improvement >Reporter: Chris Goffinet >Assignee: Vijay >Priority: Minor > Fix For: 1.1 > > Attachments: 0001-re-factor-first-and-last.patch, > 0001-save-summaries-to-disk.patch, 0002-save-summaries-to-disk-v2.patch, > 0002-save-summaries-to-disk.patch > > > For nodes with millions of keys, doing rolling restarts that take over 10 > minutes per node can be painful if you have 100 node cluster. All of our time > is spent on doing index summary computations on startup. It would be great if > we could save those to disk as well. Our indexes are quite large. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3755) NPE on invalid CQL DELETE command
[
https://issues.apache.org/jira/browse/CASSANDRA-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated CASSANDRA-3755:
Attachment: unknown_cf.diff
throw a IRE exception with understandable error message, rather than NPE.
> NPE on invalid CQL DELETE command
> -
>
> Key: CASSANDRA-3755
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3755
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.8 beta 1
>Reporter: paul cannon
>Priority: Minor
> Labels: cql
> Attachments: unknown_cf.diff
>
>
> The CQL command {{delete from k where key='bar';}} causes Cassandra to hit a
> NullPointerException when the "k" column family does not exist, and it
> subsequently closes the Thrift connection instead of reporting an IRE or
> whatever. This is probably wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3759) [patch] don't allow dropping the system keyspace
[patch] don't allow dropping the system keyspace Key: CASSANDRA-3759 URL: https://issues.apache.org/jira/browse/CASSANDRA-3759 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.7 Reporter: Dave Brosius Priority: Trivial Fix For: 1.0.8 throw an IRE if user attempts to drop system keyspace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3759) [patch] don't allow dropping the system keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3759: Attachment: no_drop_system.diff > [patch] don't allow dropping the system keyspace > > > Key: CASSANDRA-3759 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3759 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.7 >Reporter: Dave Brosius >Priority: Trivial > Fix For: 1.0.8 > > Attachments: no_drop_system.diff > > > throw an IRE if user attempts to drop system keyspace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3759) [patch] don't allow dropping the system keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3759: Attachment: no_drop_system.diff > [patch] don't allow dropping the system keyspace > > > Key: CASSANDRA-3759 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3759 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.7 >Reporter: Dave Brosius >Priority: Trivial > Fix For: 1.0.8 > > Attachments: no_drop_system.diff > > > throw an IRE if user attempts to drop system keyspace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3759) [patch] don't allow dropping the system keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3759: Attachment: (was: no_drop_system.diff) > [patch] don't allow dropping the system keyspace > > > Key: CASSANDRA-3759 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3759 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.7 >Reporter: Dave Brosius >Priority: Trivial > Fix For: 1.0.8 > > Attachments: no_drop_system.diff > > > throw an IRE if user attempts to drop system keyspace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
