[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590344#comment-13590344 ] Sylvain Lebresne commented on CASSANDRA-5062: - Paxos is use here to have replicas agree on basically the value post-next-cas. I.e. a proposer proposes it's values as if the cas was ok. If the replica tell us that our proposal (so our cas) don't win anyway, we bail out (which I don't think is the right thing to do, but that's a detail for now), otherwise we check our cas does indeed apply and we send accepts. Now, paxos guarantees basically that once a majority of replica have accepted one value, only this value can ever be accepted, even by other proposer. So far, raw paxos only allow us to do one CAS (per row-key) ever. I.e. paxos allows to agree on what is the first cas to go it but that's it. To be able to continue, we need to restart a completely new instance of paxos. How does that happen exactly in your sketch? I think you elude to that in you comment on the commit phase with 3b, where you "discard acceptance records for successfully committed replicas", which I understand more or less as, "once we've committed the first paxos result, we forget all state and start afresh a new paxos instance". But this is not obviously correct to me. At the very least, it seems to me that you shouldn't start forgetting about the previous instance of Paxos before you've make sure a majority of replica have learn about the commit result. So basically I don't understand how the commit part work and more generally how do you go from one round to Paxos to the next (where by round, I mean a full instance of the paxos algorithm) since you don't seem to formalize the notion of round. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5271) Create tool to drop sstables to level 0
[ https://issues.apache.org/jira/browse/CASSANDRA-5271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-5271: --- Attachment: 0001-Add-tool-to-drop-sstables-back-to-level-0-v3.patch v3 takes keyspace and columnfamily as parameters instead > Create tool to drop sstables to level 0 > --- > > Key: CASSANDRA-5271 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5271 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Trivial > Labels: tools > Fix For: 2.0 > > Attachments: 0001-Add-tool-to-drop-sstables-back-to-level-0.patch, > 0001-Add-tool-to-drop-sstables-back-to-level-0-v2.patch, > 0001-Add-tool-to-drop-sstables-back-to-level-0-v3.patch > > > after CASSANDRA-4872 we need a way to reset all sstables to level 0, > previously we did this by removing the .json file from the data-directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5301) Clean up bash scripts in bin/ and tools/bin/
Marcus Eriksson created CASSANDRA-5301: -- Summary: Clean up bash scripts in bin/ and tools/bin/ Key: CASSANDRA-5301 URL: https://issues.apache.org/jira/browse/CASSANDRA-5301 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson Priority: Trivial there is alot of copy-and-pasting going on in the scripts in bin/ and tools/bin/, create a script to include in the various tool-scripts, it should do classpath and config file detection etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5300) Insufficient validation of UPDATE queries against counter cfs
[
https://issues.apache.org/jira/browse/CASSANDRA-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590389#comment-13590389
]
Marco Matarazzo commented on CASSANDRA-5300:
I was hoping this was a feature, and was about to be extended to INSERT too, it
can be very useful during table initialization/import using COPY FROM on cqlsh
or just a bunch of saved CQL.
> Insufficient validation of UPDATE queries against counter cfs
> -
>
> Key: CASSANDRA-5300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5300
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5300.txt
>
>
> {noformat}
> CREATE TABLE demo (
> id int PRIMARY KEY,
> c counter
> )
> {noformat}
> This is expected:
> {noformat}
> insert into demo (id, c) VALUES ( 0, 20);
> Bad Request: INSERT statement are not allowed on counter tables, use UPDATE
> instead
> {noformat}
> This should also be forbidden, but it is not:
> {noformat}
> update demo set c = 20 where id = 0;
> select * from demo;
> id | c
> +
> 0 | 20
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5300) Insufficient validation of UPDATE queries against counter cfs
[
https://issues.apache.org/jira/browse/CASSANDRA-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590392#comment-13590392
]
Giovanni Gargani commented on CASSANDRA-5300:
-
I welcomed it as nice feature, too. Forcing a defined value in a counter does
have uses (i.e., when you have a cap to the value a counter can reach)
> Insufficient validation of UPDATE queries against counter cfs
> -
>
> Key: CASSANDRA-5300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5300
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5300.txt
>
>
> {noformat}
> CREATE TABLE demo (
> id int PRIMARY KEY,
> c counter
> )
> {noformat}
> This is expected:
> {noformat}
> insert into demo (id, c) VALUES ( 0, 20);
> Bad Request: INSERT statement are not allowed on counter tables, use UPDATE
> instead
> {noformat}
> This should also be forbidden, but it is not:
> {noformat}
> update demo set c = 20 where id = 0;
> select * from demo;
> id | c
> +
> 0 | 20
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5300) Insufficient validation of UPDATE queries against counter cfs
[
https://issues.apache.org/jira/browse/CASSANDRA-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5300:
Attachment: 5300-v2.txt
I'd prefer doing the validation in Operation.SetValue directly because that
where we have all the other type validation now (and it's cleaner that way
imo), as done in the attached v2.
bq. it can be very useful during table initialization/import
For the record, nobody contesting being able to set a counter would be useful.
But it doesn't work and I'm pretty sure it cannot work with the current
implementation of counters. Don't be fooled by the example above, it's not
complete. If you try an increment after the last update, you will end up with a
server side exception because you've basically corrupted your data.
> Insufficient validation of UPDATE queries against counter cfs
> -
>
> Key: CASSANDRA-5300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5300
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5300.txt, 5300-v2.txt
>
>
> {noformat}
> CREATE TABLE demo (
> id int PRIMARY KEY,
> c counter
> )
> {noformat}
> This is expected:
> {noformat}
> insert into demo (id, c) VALUES ( 0, 20);
> Bad Request: INSERT statement are not allowed on counter tables, use UPDATE
> instead
> {noformat}
> This should also be forbidden, but it is not:
> {noformat}
> update demo set c = 20 where id = 0;
> select * from demo;
> id | c
> +
> 0 | 20
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3783) Add 'null' support to CQL 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590443#comment-13590443
]
Joachim Haagen Skeie commented on CASSANDRA-3783:
-
It would also be convenient if CQL3 supported null values for collections.
Say I have
ALTER TABLE metrics ADD valueBySecond list;
And I want to insert metric values into the table, some data-point could be
null if no measurement for that time period exists. It would be great if CQL3
supported doing:
INSERT into metrics (id, valueBySecond ) values ( 'id', [1.2, 3,4, null, 4.5,
null]);
> Add 'null' support to CQL 3.0
> -
>
> Key: CASSANDRA-3783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3783
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Reporter: Sylvain Lebresne
>Assignee: Michał Michalski
>Priority: Minor
> Labels: cql3
> Fix For: 1.2.3
>
> Attachments: 3783-v2.patch, 3783-wip-v1.patch
>
>
> Dense composite supports adding records where only a prefix of all the
> component specifying the key is defined. In other words, with:
> {noformat}
> CREATE TABLE connections (
>userid int,
>ip text,
>port int,
>protocol text,
>time timestamp,
>PRIMARY KEY (userid, ip, port, protocol)
> ) WITH COMPACT STORAGE
> {noformat}
> you can insert
> {noformat}
> INSERT INTO connections (userid, ip, port, time) VALUES (2, '192.168.0.1',
> 80, 123456789);
> {noformat}
> You cannot however select that column specifically (i.e, without selecting
> column (2, '192.168.0.1', 80, 'http') for instance).
> This ticket proposes to allow that though 'null', i.e. to allow
> {noformat}
> SELECT * FROM connections WHERE userid = 2 AND ip = '192.168.0.1' AND port =
> 80 AND protocol = null;
> {noformat}
> It would then also make sense to support:
> {noformat}
> INSERT INTO connections (userid, ip, port, protocol, time) VALUES (2,
> '192.168.0.1', 80, null, 123456789);
> {noformat}
> as an equivalent to the insert query above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5300) Insufficient validation of UPDATE queries against counter cfs
[
https://issues.apache.org/jira/browse/CASSANDRA-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590467#comment-13590467
]
Aleksey Yeschenko commented on CASSANDRA-5300:
--
bq. I'd prefer doing the validation in Operation.SetValue directly because that
where we have all the other type validation now (and it's cleaner that way
imo), as done in the attached v2.
wfm, +1
> Insufficient validation of UPDATE queries against counter cfs
> -
>
> Key: CASSANDRA-5300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5300
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5300.txt, 5300-v2.txt
>
>
> {noformat}
> CREATE TABLE demo (
> id int PRIMARY KEY,
> c counter
> )
> {noformat}
> This is expected:
> {noformat}
> insert into demo (id, c) VALUES ( 0, 20);
> Bad Request: INSERT statement are not allowed on counter tables, use UPDATE
> instead
> {noformat}
> This should also be forbidden, but it is not:
> {noformat}
> update demo set c = 20 where id = 0;
> select * from demo;
> id | c
> +
> 0 | 20
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3783) Add 'null' support to CQL 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590511#comment-13590511
]
Sylvain Lebresne commented on CASSANDRA-3783:
-
bq. It would also be convenient if CQL3 supported null values for collections.
I'm afraid this is not so simple I'm afraid. Doing that would basically require
having an internal representation of null for every type (because in that case,
we would be talking of actually storing a null value, not just deleting a
column). And we don't have an easy candidate for that internal representation
currently. Meaning we would have to change a bit the internal representation of
collection columns (say, add some flags somewhere in the column name that say
"this is a null element"). But I'm not convinced we can do that without
breaking backward compatibility really. In any case, this is a very special
case so we should handle that in a followup ticket if we do handle. But again,
not sure how doable that is in practice.
{quote}
Say I have
ALTER TABLE metrics ADD valueBySecond list;
{quote}
Just for the record, this sound like a bad use of a list. Because valueBySecond
sound like something that by design will grow fairly big. Remember that
currently you cannot fetch parts of a collection. And even when we allow
fetching part of a collection, we'll only be able to do it for maps and sets,
not for lists. This is typically a case where you'd rather want to have a
composite PK.
> Add 'null' support to CQL 3.0
> -
>
> Key: CASSANDRA-3783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3783
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Reporter: Sylvain Lebresne
>Assignee: Michał Michalski
>Priority: Minor
> Labels: cql3
> Fix For: 1.2.3
>
> Attachments: 3783-v2.patch, 3783-wip-v1.patch
>
>
> Dense composite supports adding records where only a prefix of all the
> component specifying the key is defined. In other words, with:
> {noformat}
> CREATE TABLE connections (
>userid int,
>ip text,
>port int,
>protocol text,
>time timestamp,
>PRIMARY KEY (userid, ip, port, protocol)
> ) WITH COMPACT STORAGE
> {noformat}
> you can insert
> {noformat}
> INSERT INTO connections (userid, ip, port, time) VALUES (2, '192.168.0.1',
> 80, 123456789);
> {noformat}
> You cannot however select that column specifically (i.e, without selecting
> column (2, '192.168.0.1', 80, 'http') for instance).
> This ticket proposes to allow that though 'null', i.e. to allow
> {noformat}
> SELECT * FROM connections WHERE userid = 2 AND ip = '192.168.0.1' AND port =
> 80 AND protocol = null;
> {noformat}
> It would then also make sense to support:
> {noformat}
> INSERT INTO connections (userid, ip, port, protocol, time) VALUES (2,
> '192.168.0.1', 80, null, 123456789);
> {noformat}
> as an equivalent to the insert query above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Fix insufficient validation of UPDATE queries against counter cfs
Updated Branches:
refs/heads/cassandra-1.2 d8e819386 -> 7c920b0bb
Fix insufficient validation of UPDATE queries against counter cfs
patch by slebresne; reviewed by iamaleksey for CASSANDRA-5300
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7c920b0b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7c920b0b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7c920b0b
Branch: refs/heads/cassandra-1.2
Commit: 7c920b0bb88dffca61602c849df25cc3153c
Parents: d8e8193
Author: Sylvain Lebresne
Authored: Fri Mar 1 14:25:44 2013 +0100
Committer: Sylvain Lebresne
Committed: Fri Mar 1 14:25:44 2013 +0100
--
CHANGES.txt |2 ++
src/java/org/apache/cassandra/cql3/Operation.java |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7c920b0b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 9d0468b..231de9c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -3,6 +3,8 @@
not intersect the sstable (CASSANDRA-5249)
* Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292)
* Fix composite comparator with super columns (CASSANDRA-5287)
+ * Fix insufficient validation of UPDATE queries against counter cfs
+ (CASSANDRA-5300)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7c920b0b/src/java/org/apache/cassandra/cql3/Operation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/Operation.java
b/src/java/org/apache/cassandra/cql3/Operation.java
index 90887e0..2e16cea 100644
--- a/src/java/org/apache/cassandra/cql3/Operation.java
+++ b/src/java/org/apache/cassandra/cql3/Operation.java
@@ -159,6 +159,9 @@ public abstract class Operation
{
Term v = value.prepare(receiver);
+if (receiver.type instanceof CounterColumnType)
+throw new InvalidRequestException(String.format("Cannot set
the value of counter column %s (counters can only be incremented/decremented,
not set)", receiver));
+
if (!(receiver.type instanceof CollectionType))
return new Constants.Setter(receiver.kind ==
CFDefinition.Name.Kind.VALUE_ALIAS ? null : receiver.name, v);
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/trunk 7b65883d8 -> a17f0ed4e Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a17f0ed4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a17f0ed4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a17f0ed4 Branch: refs/heads/trunk Commit: a17f0ed4e95329c43bdf1d47c9e7002ec00f0c14 Parents: 7b65883 7c920b0 Author: Sylvain Lebresne Authored: Fri Mar 1 14:30:40 2013 +0100 Committer: Sylvain Lebresne Committed: Fri Mar 1 14:30:40 2013 +0100 -- CHANGES.txt |2 ++ src/java/org/apache/cassandra/cql3/Operation.java |3 +++ 2 files changed, 5 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a17f0ed4/CHANGES.txt --
[1/2] git commit: Fix insufficient validation of UPDATE queries against counter cfs
Fix insufficient validation of UPDATE queries against counter cfs
patch by slebresne; reviewed by iamaleksey for CASSANDRA-5300
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7c920b0b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7c920b0b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7c920b0b
Branch: refs/heads/trunk
Commit: 7c920b0bb88dffca61602c849df25cc3153c
Parents: d8e8193
Author: Sylvain Lebresne
Authored: Fri Mar 1 14:25:44 2013 +0100
Committer: Sylvain Lebresne
Committed: Fri Mar 1 14:25:44 2013 +0100
--
CHANGES.txt |2 ++
src/java/org/apache/cassandra/cql3/Operation.java |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7c920b0b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 9d0468b..231de9c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -3,6 +3,8 @@
not intersect the sstable (CASSANDRA-5249)
* Don't lowercase property map keys (this breaks NTS) (CASSANDRA-5292)
* Fix composite comparator with super columns (CASSANDRA-5287)
+ * Fix insufficient validation of UPDATE queries against counter cfs
+ (CASSANDRA-5300)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7c920b0b/src/java/org/apache/cassandra/cql3/Operation.java
--
diff --git a/src/java/org/apache/cassandra/cql3/Operation.java
b/src/java/org/apache/cassandra/cql3/Operation.java
index 90887e0..2e16cea 100644
--- a/src/java/org/apache/cassandra/cql3/Operation.java
+++ b/src/java/org/apache/cassandra/cql3/Operation.java
@@ -159,6 +159,9 @@ public abstract class Operation
{
Term v = value.prepare(receiver);
+if (receiver.type instanceof CounterColumnType)
+throw new InvalidRequestException(String.format("Cannot set
the value of counter column %s (counters can only be incremented/decremented,
not set)", receiver));
+
if (!(receiver.type instanceof CollectionType))
return new Constants.Setter(receiver.kind ==
CFDefinition.Name.Kind.VALUE_ALIAS ? null : receiver.name, v);
[jira] [Commented] (CASSANDRA-4795) replication, compaction, compression? options are not validated
[ https://issues.apache.org/jira/browse/CASSANDRA-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590518#comment-13590518 ] Sylvain Lebresne commented on CASSANDRA-4795: - So, does the absence of review of my 2 first patches mean that everyone decided the status quo was ok? Cause I could live with that. But if we think this should be reverted from 1.2 then let's do that sooner than later. > replication, compaction, compression? options are not validated > --- > > Key: CASSANDRA-4795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4795 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Brandon Williams >Assignee: Dave Brosius >Priority: Minor > Fix For: 1.2.1 > > Attachments: 0001-Reallow-unexpected-strategy-options-for-thrift.txt, > 0002-Reallow-unexpected-strategy-options-for-thrift.txt, > 0003-Adds-application_metadata-field-to-ks-metadata.txt, > 4795.compaction_strategy.txt, 4795_compaction_strategy_v2.txt, > 4795_compaction_strategy_v3.txt, 4795.replication_strategy.txt > > > When creating a keyspace and specifying strategy options, you can pass any > k/v pair you like. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5081) Support null values in PreparedStatements parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590520#comment-13590520 ] Sylvain Lebresne commented on CASSANDRA-5081: - I'd be thankful if someone review this quicklyish :) > Support null values in PreparedStatements parameters > > > Key: CASSANDRA-5081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5081 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Michaël Figuière >Assignee: Sylvain Lebresne > Fix For: 1.2.3 > > Attachments: 5081.patch > > > Currently whenever developers want to use PreparedStatements, they need to > ensure that all their parameters are non null or they need to have several > PreparedStatements for each possible set of non null columns they want to > store. This is obviously not a satisfying solution considering that 'null' > values are a commonplace in applications. > 'null' values should be allowed as parameters of PreparedStatements in Binary > Protocol to solve this issue. > This issue is obviously tightly coupled with CASSANDRA-3783 but they might be > fixed separately. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590519#comment-13590519 ] Jonathan Ellis commented on CASSANDRA-5062: --- bq. To be able to continue, we need to restart a completely new instance of paxos. Yes, that's the tricky part, and none of the papers go into detail here. I think the outline here will work, but I'm open to better ideas. bq. At the very least, it seems to me that you shouldn't start forgetting about the previous instance of Paxos before you've make sure a majority of replica have learn about the commit result. "Commit" means "write it to the 'main' CF, update mostRecentCommitted, and discard the proposal records." (Prepare/Accept/Commit are all commitlog'd; normal caveats apply if you don't run with Batch mode.) I think you're correct that we need to wait for a majority to agree on mostRecentCommitted before proceeding. > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5302) Fix nodetool ring and status output format for IPv6 addresses
Michał Michalski created CASSANDRA-5302:
---
Summary: Fix nodetool ring and status output format for IPv6
addresses
Key: CASSANDRA-5302
URL: https://issues.apache.org/jira/browse/CASSANDRA-5302
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Michał Michalski
Assignee: Michał Michalski
Priority: Trivial
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture:~/workspace/cassandra-dev$ ./bin/nodetool -h
cssa01-04.oslo.osa status
Datacenter: DC1
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
TokenRack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are equal. Let me know if there's the case when it's
not valid.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5302) Fix nodetool ring and status output format for IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michał Michalski updated CASSANDRA-5302:
Attachment: 5302.patch
> Fix nodetool ring and status output format for IPv6 addresses
> -
>
> Key: CASSANDRA-5302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5302
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Michał Michalski
>Assignee: Michał Michalski
>Priority: Trivial
> Attachments: 5302.patch
>
>
> My pedantic nature can't stand having unaligned columns in nodetool outputs,
> which happens when IP addresses are IPv6 ones:
> {noformat}michal@aperture:~/workspace/cassandra-dev$ ./bin/nodetool -h
> cssa01-04.oslo.osa status
> Datacenter: DC1
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Owns (effective) Host ID
>TokenRack
> UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
> d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
> rack2
> UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
> 0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
> rack1
> {noformat}
> I'm attaching a patch that fixes this problem for nodetool status / ring
> commands. It does it by picking first item in nodes list (for nodetool ring
> it's first node in general, for nodetool status it's first node in each DC)
> and uses its length as a field length for output.
> It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC
> and the lenghts of addresses are equal. Let me know if there's the case when
> it's not valid.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5302) Fix nodetool ring and status output format for IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michał Michalski updated CASSANDRA-5302:
Description:
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture$ nodetool -h myhost status
Datacenter: DC1
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
TokenRack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are equal. Let me know if there's the case when it's
not valid.
was:
My pedantic nature can't stand having unaligned columns in nodetool outputs,
which happens when IP addresses are IPv6 ones:
{noformat}michal@aperture:~/workspace/cassandra-dev$ ./bin/nodetool -h
cssa01-04.oslo.osa status
Datacenter: DC1
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns (effective) Host ID
TokenRack
UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
rack2
UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
rack1
{noformat}
I'm attaching a patch that fixes this problem for nodetool status / ring
commands. It does it by picking first item in nodes list (for nodetool ring
it's first node in general, for nodetool status it's first node in each DC) and
uses its length as a field length for output.
It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and
the lenghts of addresses are equal. Let me know if there's the case when it's
not valid.
> Fix nodetool ring and status output format for IPv6 addresses
> -
>
> Key: CASSANDRA-5302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5302
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Michał Michalski
>Assignee: Michał Michalski
>Priority: Trivial
> Attachments: 5302.patch
>
>
> My pedantic nature can't stand having unaligned columns in nodetool outputs,
> which happens when IP addresses are IPv6 ones:
> {noformat}michal@aperture$ nodetool -h myhost status
> Datacenter: DC1
> ==
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Owns (effective) Host ID
>TokenRack
> UN 2001:3c27:21:166:0:1:2:7 331.65 GB 100,0%
> d557fb83-72f2-4e92-9f26-de6c788aada5 85070591730234615865843651857942052864
> rack2
> UN 2001:3c27:21:166:0:1:1:7 328.8 GB 100,0%
> 0461a4bf-97a6-447d-9d06-3b42ad1f702c 0
> rack1
> {noformat}
> I'm attaching a patch that fixes this problem for nodetool status / ring
> commands. It does it by picking first item in nodes list (for nodetool ring
> it's first node in general, for nodetool status it's first node in each DC)
> and uses its length as a field length for output.
> It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC
> and the lenghts of addresses are equal. Let me know if there's the case when
> it's not valid.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4206) AssertionError: originally calculated column size of 629444349 but now it is 588008950
[
https://issues.apache.org/jira/browse/CASSANDRA-4206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590564#comment-13590564
]
Joey Imbasciano commented on CASSANDRA-4206:
I am seeing what seems like the same issue on 1.2.2 on nodes that had collected
a lot of hints after a node had been down for a couple hours.
{noformat}
ERROR [CompactionExecutor:104] 2013-03-01 00:29:54,211 CassandraDaemon.java
(line 132) Exception in thread Thread[CompactionExecutor:104,1,main]
java.lang.AssertionError: originally calculated column size of 350273328 but
now it is 350297055
at
org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:135)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:159)
at
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:163)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:59)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:62)
at
org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:422)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
ERROR [HintedHandoff:1] 2013-03-01 00:29:54,211 CassandraDaemon.java (line 132)
Exception in thread Thread[HintedHandoff:1,1,main]
java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.AssertionError: originally calculated column size of 350273328 but
now it is 350297055
at
org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:406)
at
org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:252)
at
org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:89)
at
org.apache.cassandra.db.HintedHandOffManager$4.runMayThrow(HintedHandOffManager.java:459)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.concurrent.ExecutionException: java.lang.AssertionError:
originally calculated column size of 350273328 but now it is 350297055
at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at
org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:402)
... 7 more
Caused by: java.lang.AssertionError: originally calculated column size of
350273328 but now it is 350297055
at
org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:135)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:159)
at
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:163)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:59)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:62)
at
org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:422)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
... 3 more
{noformat}
> AssertionError: originally calculated column size of 629444349 but now it is
> 588008950
> --
>
> Key: CASSANDRA-4206
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4206
> Project: Cassandra
> Issue Ty
[jira] [Updated] (CASSANDRA-3929) Support row size limits
[ https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3929: -- Reviewer: slebresne (was: jbellis) > Support row size limits > --- > > Key: CASSANDRA-3929 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3929 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Dave Brosius >Priority: Minor > Labels: ponies > Fix For: 2.0 > > Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, > 3929_f.txt, 3929_g_tests.txt, 3929_g.txt, 3929.txt > > > We currently support expiring columns by time-to-live; we've also had > requests for keeping the most recent N columns in a row. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5251) Hadoop support should be able to work with multiple column families
[ https://issues.apache.org/jira/browse/CASSANDRA-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590587#comment-13590587 ] Jonathan Ellis commented on CASSANDRA-5251: --- If you want to m/r data without random i/o, it needs to be in the same CF, which may not be ideal for your other uses. Pick your poison. > Hadoop support should be able to work with multiple column families > --- > > Key: CASSANDRA-5251 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5251 > Project: Cassandra > Issue Type: Improvement > Components: Hadoop >Affects Versions: 1.1.0, 1.1.11, 1.2.0, 2.0 >Reporter: Illarion Kovalchuk >Priority: Minor > Attachments: trunk-5251.txt > > > This patch affects api, so I changed hadoop example in it. The main > difference is that now ColumnFamilyInput format generates splits for all > input column families, and ColumnFamilyOutputFormat works not with > List, but with List>, where Pair.left is for > column family name. > Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5285) PropertyFileSnitch default DC/Rack behavior is broken in 1.2
[ https://issues.apache.org/jira/browse/CASSANDRA-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590588#comment-13590588 ] Jonathan Ellis commented on CASSANDRA-5285: --- +1 > PropertyFileSnitch default DC/Rack behavior is broken in 1.2 > > > Key: CASSANDRA-5285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5285 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.2.3 > > Attachments: 5285.txt > > > CASSANDRA-4728 added a check that the local node was in the property file but > didn't took a potential default into account. > Typically, using the shipped cassandra-topology.properties (that has a > default DC and rack) with a node on localhost raises a ConfigurationException > on startup). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5081) Support null values in PreparedStatements parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5081: Attachment: (was: 5081.patch) > Support null values in PreparedStatements parameters > > > Key: CASSANDRA-5081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5081 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Michaël Figuière >Assignee: Sylvain Lebresne > Fix For: 1.2.3 > > Attachments: 5081.txt > > > Currently whenever developers want to use PreparedStatements, they need to > ensure that all their parameters are non null or they need to have several > PreparedStatements for each possible set of non null columns they want to > store. This is obviously not a satisfying solution considering that 'null' > values are a commonplace in applications. > 'null' values should be allowed as parameters of PreparedStatements in Binary > Protocol to solve this issue. > This issue is obviously tightly coupled with CASSANDRA-3783 but they might be > fixed separately. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5081) Support null values in PreparedStatements parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5081: Attachment: 5081.txt > Support null values in PreparedStatements parameters > > > Key: CASSANDRA-5081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5081 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Michaël Figuière >Assignee: Sylvain Lebresne > Fix For: 1.2.3 > > Attachments: 5081.txt > > > Currently whenever developers want to use PreparedStatements, they need to > ensure that all their parameters are non null or they need to have several > PreparedStatements for each possible set of non null columns they want to > store. This is obviously not a satisfying solution considering that 'null' > values are a commonplace in applications. > 'null' values should be allowed as parameters of PreparedStatements in Binary > Protocol to solve this issue. > This issue is obviously tightly coupled with CASSANDRA-3783 but they might be > fixed separately. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5182) Deletable rows are sometimes not removed during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590601#comment-13590601 ] Jonathan Ellis commented on CASSANDRA-5182: --- bq. So overall I do like the last patch attached by Yuki. Of course, the solution of just saying "you shouldn't disable bloom filters on workloads that perform deletes" works too, and I wouldn't oppose it, but it doesn't have my preference because I'm always a bit afraid of solving an issue by saying "don't do this", as it usually end up in people getting bitten first and hearing they shouldn't have done it second. The problem is it's not as simple as "people get bitten if we don't getPosition, and don't if we do" -- they get bitten either way, and IMO the bite from getPosition is worse, since it will destroy compaction performance for any workload where index doesn't fit entirely in ram, which makes BF disabling almost useless. But if we say "only disable BF where you're not doing deletes," it has a legitimate if narrow use case. > Deletable rows are sometimes not removed during compaction > -- > > Key: CASSANDRA-5182 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5182 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.7 >Reporter: Binh Van Nguyen >Assignee: Yuki Morishita > Fix For: 1.2.3 > > Attachments: 5182-1.1.txt, 5182-1.2.txt, test_ttl.tar.gz > > > Our use case is write heavy and read seldom. To optimize the space used, > we've set the bloom_filter_fp_ratio=1.0 That along with the fact that each > row is only written to one time and that there are more than 20 SSTables > keeps the rows from ever being compacted. Here is the code: > https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionController.java#L162 > We hit this conner case and because of this C* keeps consuming more and more > space on disk while it should not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[ https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590604#comment-13590604 ] Jonathan Ellis commented on CASSANDRA-5051: --- v2 attached that makes cleanup-during-compaction always-on. (v2 also switches from comparing based on table name to checking for LocalStrateg, and moves indexColumns list internal to rmIdxRenewCounter.) this highlights a problem, though -- some tests now fail, because StorageService.getLocalRanges will return an empty list until StorageService initializes it. (I think this is either via loading the stored ring through initServer, or via gossip filling things in. Not really sure how gossip fills in my own token if we don't load from the system table. Bit of a mess here.) So (a) obviously this is a bit fragile for the tests. But is there potential for us to also throw away data that we shouldn't if we get behind on gossip somehow? At the very least I think we need to include pending ranges for the local node. Nit: ISTM we ought to be able to move LCR's Iterable into AbstractCompactedRow, but I'm not actually sure how to make generics happy w/ the PR subclass returning Iterator. > Allow automatic cleanup after gc_grace > -- > > Key: CASSANDRA-5051 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5051 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Labels: vnodes > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-5051.patch, 5051-v2.txt > > > When using vnodes, after adding a new node you have to run cleanup on all the > machines, because you don't know which are affected and chances are it was > most if not all of them. As an alternative to this intensive process, we > could allow cleanup during compaction if the data is older than gc_grace (or > perhaps some other time period since people tend to use gc_grace hacks to get > rid of tombstones.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[ https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5051: -- Attachment: 5051-v2.txt > Allow automatic cleanup after gc_grace > -- > > Key: CASSANDRA-5051 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5051 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Labels: vnodes > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-5051.patch, 5051-v2.txt > > > When using vnodes, after adding a new node you have to run cleanup on all the > machines, because you don't know which are affected and chances are it was > most if not all of them. As an alternative to this intensive process, we > could allow cleanup during compaction if the data is older than gc_grace (or > perhaps some other time period since people tend to use gc_grace hacks to get > rid of tombstones.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5255) dsnitch severity is not correctly set for compaction info
[ https://issues.apache.org/jira/browse/CASSANDRA-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590605#comment-13590605 ] Jonathan Ellis commented on CASSANDRA-5255: --- +1 on the fix for negative severity. Please open followup tickets per above discussion. > dsnitch severity is not correctly set for compaction info > - > > Key: CASSANDRA-5255 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5255 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.0 beta 1 >Reporter: Brandon Williams >Assignee: Vijay >Priority: Minor > Fix For: 1.2.3 > > Attachments: 0001-CASSANDRA-5255.patch > > > We're doing two things wrong in CI. First, load can change between calls, > which can cause a negative severity even though it meant to subtract whatever > it added before. Second, we should report based on how much IO we're using, > since a 1T throttled to 5MB/s is less impactful than a 100MB running at full > speed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5081) Support null values in PreparedStatements parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5081: - Reviewer: iamaleksey > Support null values in PreparedStatements parameters > > > Key: CASSANDRA-5081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5081 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Michaël Figuière >Assignee: Sylvain Lebresne > Fix For: 1.2.3 > > Attachments: 5081.txt > > > Currently whenever developers want to use PreparedStatements, they need to > ensure that all their parameters are non null or they need to have several > PreparedStatements for each possible set of non null columns they want to > store. This is obviously not a satisfying solution considering that 'null' > values are a commonplace in applications. > 'null' values should be allowed as parameters of PreparedStatements in Binary > Protocol to solve this issue. > This issue is obviously tightly coupled with CASSANDRA-3783 but they might be > fixed separately. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4937) CRAR improvements (object cache + CompressionMetadata chunk offset storage moved off-heap).
[ https://issues.apache.org/jira/browse/CASSANDRA-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4937: -- Reviewer: yukim (was: jbellis) > CRAR improvements (object cache + CompressionMetadata chunk offset storage > moved off-heap). > --- > > Key: CASSANDRA-4937 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4937 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich > Labels: core > Fix For: 1.2.3 > > Attachments: 4937-v3.txt, CASSANDRA-4937.patch, > CASSANDRA-4937-trunk.patch > > > After good amount of testing on one of the clusters it was found that in > order to improve read latency we need to minimize allocation rate that > compression involves, that minimizes GC (as well as heap usage) and > substantially decreases latency on read heavy workloads. > I have also discovered that RAR skip cache harms performance in situation > when reads are done in parallel with compaction working with relatively big > SSTable files (few GB and more). The attached patch removes possibility to > skip cache from compressed files (I can also add changes to RAR to remove > skip cache functionality as a separate patch). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "KelliYost" by KelliYost
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "KelliYost" page has been changed by KelliYost: http://wiki.apache.org/cassandra/KelliYost New page: I'd been around Xinjiang Tarim Higher educatoin institutions farm h2o conservancy system university students, in May 20XX had been preferred to make sure you Wuhan College for the expert path study. In the form of graduate involving experienced 20XX program in garden waters conservancy assignment for Wuhan College. Happy through four years involving unremitting efforts and hard to educate yourself about, can finish with superb performance today, using the school find out in order to try out, commitment to serve my personal area, his own alma mater, and my own dads and moms.<> College portions about getting to know not to mention expanding produced this will probably, to boost my own self-cultivation. This "pains, some sort of harvesting, Inches! I may try out my better to work flat out, to create the lifespan valuations. Given that the fresh one hundred year youngsters, We've all the will for additional details on, be good at advancement heart and soul.<> Candid persona My goal is to obtain a persons revisit by using candor and energy, Let me make use of initiatives and additionally wisdom to address meant for my personal space, allow the culture to do. Debts sociable practice functions, I will make an effort your far better to handle and handle the software, not to mention establish a sense tough self-confidence, your heart and soul with helpfulness!<> Institution inside the superb your life, When i acquired not simply competent experience, improve the in general good quality, a bigger factor should be to discover ways to be regarded as a dude. That allows you to examine the professional know-how, I personally pursue to greatly improve their selves, to help make their endeavours being a mixture benefits necessary for modern day contemporary culture.<> <> It's my opinion I'm able to get accustomed to present day competitive surrounding local community.<> <> Here is my page [[http://www.weeklyhandbag.com|chanel purse]]
[jira] [Commented] (CASSANDRA-4206) AssertionError: originally calculated column size of 629444349 but now it is 588008950
[
https://issues.apache.org/jira/browse/CASSANDRA-4206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590641#comment-13590641
]
Joey Imbasciano commented on CASSANDRA-4206:
Version: 1.2.2 - 6 nodes, RF3
OS: Centos 6.3
Looking closer at the errors, I'm only seeing this for the system/hints:
{noformat}
INFO [CompactionExecutor:555] 2013-03-01 15:37:10,737
CompactionController.java (line 158) Compacting large row system/hints:384ac791
-d0d7-4f5e-b66b-57af885341d5 (350297131 bytes) incrementally
ERROR [CompactionExecutor:555] 2013-03-01 15:37:28,377 CassandraDaemon.java
(line 132) Exception in thread Thread[CompactionExecutor:5
55,1,main]
{noformat}
> AssertionError: originally calculated column size of 629444349 but now it is
> 588008950
> --
>
> Key: CASSANDRA-4206
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4206
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.9
> Environment: Debian Squeeze Linux, kernel 2.6.32, sun-java6-bin
> 6.26-0squeeze1
>Reporter: Patrik Modesto
>
> I've 4 node cluster of Cassandra 1.0.9. There is a rfTest3 keyspace with RF=3
> and one CF with two secondary indexes. I'm importing data into this CF using
> Hadoop Mapreduce job, each row has less than 10 colkumns. From JMX:
> MaxRowSize: 1597
> MeanRowSize: 369
> And there are some tens of millions of rows.
> It's write-heavy usage and there is a big pressure on each node, there are
> quite some dropped mutations on each node. After ~12 hours of inserting I see
> these assertion exceptiona on 3 out of four nodes:
> {noformat}
> ERROR 06:25:40,124 Fatal exception in thread Thread[HintedHandoff:1,1,main]
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.AssertionError: originally calculated column size of 629444349 but
> now it is 588008950
>at
> org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:388)
>at
> org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:256)
>at
> org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:84)
>at
> org.apache.cassandra.db.HintedHandOffManager$3.runMayThrow(HintedHandOffManager.java:437)
>at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>at java.lang.Thread.run(Thread.java:662)
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.AssertionError: originally calculated column size of
> 629444349 but now it is 588008950
>at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>at java.util.concurrent.FutureTask.get(FutureTask.java:83)
>at
> org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpointInternal(HintedHandOffManager.java:384)
>... 7 more
> Caused by: java.lang.AssertionError: originally calculated column size
> of 629444349 but now it is 588008950
>at
> org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:124)
>at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:160)
>at
> org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:161)
>at
> org.apache.cassandra.db.compaction.CompactionManager$7.call(CompactionManager.java:380)
>at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>... 3 more
> {noformat}
> Few lines regarding Hints from the output.log:
> {noformat}
> INFO 06:21:26,202 Compacting large row
> system/HintsColumnFamily:7000 (1712834057 bytes)
> incrementally
> INFO 06:22:52,610 Compacting large row
> system/HintsColumnFamily:1000 (2616073981 bytes)
> incrementally
> INFO 06:22:59,111 flushing high-traffic column family CFS(Keyspace='system',
> ColumnFamily='HintsColumnFamily') (estimated 305147360 bytes)
> INFO 06:22:59,813 Enqueuing flush of
> Memtable-HintsColumnFamily@833933926(3814342/305147360 serialized/live bytes,
> 7452 ops)
> INFO 06:22:59,814 Writing
> Memtable-HintsColumnFamily@833933926(3814342/305147360 serialized/live bytes,
> 7452 ops)
> {noformat}
> I think the problem may be somehow connected to an IntegerType secondary
> index. I had a different problem with CF with two secondary indexes, the
> first UTF8Type, the second IntegerType. After a few hours of inserting
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590654#comment-13590654 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. I think you're correct that we need to wait for a majority to agree on mostRecentCommitted before proceeding. I certainly don't fully understand your idea, but Paxos doesn't guarantee that only one proposer will commit. So while you wait on a majority to agree on mostRecentCommitted (to erase the state and start the next round of paxos), any concurrent CAS may end up committing (the guarantee of paxos being that the value committed will be the same one than any other commit for that round), which will change the "mostRecentCommitted". bq. Yes, that's the tricky part, and none of the papers go into detail here. I agree on both count. Let me try to describe a bit my own current reasoning on this issue (which mainly correspond to my understanding of what "Paxos made live" describe (even though, they do don't go into very much detail)). Maybe that way you can tell me how your idea differ. So, what we're going to do is successive rounds of paxos. So we make the round explicit. Concretely, we have a round number that is shipped with every message, and each round is a completely separated instance of the paxos algorithm. And so each round will yield a value. The idea is that this way, we build a consistent and replicated log of what operation to apply in which order (operation that we will apply to the data in said order, that the listening part, but paxos is here to ensure consistency of the log of operation). I.e. round N is about "let's agree on what's the Nth operation we'll apply on the data". Concretely, the first thing a proposer does is to fetch his last known committed round N (meaning, during commit, on top of actually applying the value/operation agreed on, we also basically write that round N is committed). Then it start a normal paxos for round N+1 (with whatever value/operation he want to get in). You do the full round of paxos and one operation wins. As said above, the "listening" part just consist in recording that this is the value for round N and to apply it to the actual CF. Note that you don't have to wait for anything during commit in that case. It's ok for a proposer to start a proposal on round N even though that round has been committed already (but the proposer is not aware yet). It's ok because Paxos guarantees said proposer will learn the value committed for this round N (and will commit it itself in fact). After which it will know N is committed and will be free to start a new proposal for round N+1 with the actual value/operation he wanted to get in in the first place. That's actually what happens to a node that fails. When it's back up, it might not be up to date on the most recent round. But that's ok, it will try some old round, will learn the value committed for said round (not his own since it's behind on what's committed), commit it (which has mainly the effect of learning the value locally, it will be old news for other replica) and continue like that until he catches up. That's the basic idea. Now there is 2 things that are clearly not very practical: # this suppose we keep the replicated log of operation (i.e. list of which operation has been agreed on for each round) forever. And that's ever growing. # the part above about back to life replica catching up by redoing all missed round of paxos one by one is obviously a bit lame. I think both problem are linked, and really are the issue discussed in "Paxos made live" in session 5.5-Snapshots. Now, the good news is that they have been able to optimize both of those in practice without breaking correctness, so it's possible :). That being said, their snapshot idea sound fairly heavy-weight. But I think it should be possible to do simpler as we control the data (which they don't and explicitely cite as a difficulty). I have a few idea, but honestly they are not fully though trough yet (though let's say that 1) is the hard part imo. For 2) you can have other replica "repair" a proposer that starts a proposal on an old round so it catches up right away). Now, if I ignore 1) and 2) for a minute, I think I understand the principle enough to be convinced that it is correct. Also, this is really just using paxos to build a consistent and replicated log of the operation applied, but that log is separated from the data itself. So while this does mean we would have to basically have paxos columns for which all update goes through paxos, this also means that there is nothing to do on the read path itself. Obviously, 1) and 2) need to be optimized for the idea to be realistic, and this without breaking correctness. And while I have ideas, I admit I haven't though all the details through. Still, I wanted to
git commit: Fix propertyFileSnitch default DC/Rack behavior
Updated Branches:
refs/heads/cassandra-1.2 7c920b0bb -> 709381387
Fix propertyFileSnitch default DC/Rack behavior
patch by slebresne; reviewed by jbellis for CASSANDRA-5285
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/70938138
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/70938138
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/70938138
Branch: refs/heads/cassandra-1.2
Commit: 7093813870088a8fd4ddacd5a0c29a5fa3c65f9e
Parents: 7c920b0
Author: Sylvain Lebresne
Authored: Fri Mar 1 17:04:00 2013 +0100
Committer: Sylvain Lebresne
Committed: Fri Mar 1 17:04:00 2013 +0100
--
CHANGES.txt|1 +
.../cassandra/locator/PropertyFileSnitch.java |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/70938138/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 231de9c..fd6547f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -5,6 +5,7 @@
* Fix composite comparator with super columns (CASSANDRA-5287)
* Fix insufficient validation of UPDATE queries against counter cfs
(CASSANDRA-5300)
+ * Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/70938138/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
b/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
index 7083b5e..da440af 100644
--- a/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
+++ b/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
@@ -181,8 +181,8 @@ public class PropertyFileSnitch extends
AbstractNetworkTopologySnitch
reloadedMap.put(host, token);
}
}
-if (!reloadedMap.containsKey(FBUtilities.getBroadcastAddress()))
-throw new ConfigurationException(String.format("Snitch definitions
at %s do not define a location for this node's broadcast address %s",
+if (defaultDCRack == null &&
!reloadedMap.containsKey(FBUtilities.getBroadcastAddress()))
+throw new ConfigurationException(String.format("Snitch definitions
at %s do not define a location for this node's broadcast address %s, nor does
it provides a default",
SNITCH_PROPERTIES_FILENAME, FBUtilities.getBroadcastAddress()));
logger.debug("loaded network topology {}",
FBUtilities.toString(reloadedMap));
[1/2] git commit: Fix propertyFileSnitch default DC/Rack behavior
Fix propertyFileSnitch default DC/Rack behavior
patch by slebresne; reviewed by jbellis for CASSANDRA-5285
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/70938138
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/70938138
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/70938138
Branch: refs/heads/trunk
Commit: 7093813870088a8fd4ddacd5a0c29a5fa3c65f9e
Parents: 7c920b0
Author: Sylvain Lebresne
Authored: Fri Mar 1 17:04:00 2013 +0100
Committer: Sylvain Lebresne
Committed: Fri Mar 1 17:04:00 2013 +0100
--
CHANGES.txt|1 +
.../cassandra/locator/PropertyFileSnitch.java |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/70938138/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 231de9c..fd6547f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -5,6 +5,7 @@
* Fix composite comparator with super columns (CASSANDRA-5287)
* Fix insufficient validation of UPDATE queries against counter cfs
(CASSANDRA-5300)
+ * Fix PropertyFileSnitch default DC/Rack behavior (CASSANDRA-5285)
Merged from 1.1:
* nodetool: ability to repair specific range (CASSANDRA-5280)
* Fix possible assertion triggered in SliceFromReadCommand (CASSANDRA-5284)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/70938138/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
b/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
index 7083b5e..da440af 100644
--- a/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
+++ b/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java
@@ -181,8 +181,8 @@ public class PropertyFileSnitch extends
AbstractNetworkTopologySnitch
reloadedMap.put(host, token);
}
}
-if (!reloadedMap.containsKey(FBUtilities.getBroadcastAddress()))
-throw new ConfigurationException(String.format("Snitch definitions
at %s do not define a location for this node's broadcast address %s",
+if (defaultDCRack == null &&
!reloadedMap.containsKey(FBUtilities.getBroadcastAddress()))
+throw new ConfigurationException(String.format("Snitch definitions
at %s do not define a location for this node's broadcast address %s, nor does
it provides a default",
SNITCH_PROPERTIES_FILENAME, FBUtilities.getBroadcastAddress()));
logger.debug("loaded network topology {}",
FBUtilities.toString(reloadedMap));
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/trunk a17f0ed4e -> a562636e5 Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a562636e Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a562636e Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a562636e Branch: refs/heads/trunk Commit: a562636e5d9de8c41a1d6d521c39ef010f90c409 Parents: a17f0ed 7093813 Author: Sylvain Lebresne Authored: Fri Mar 1 17:05:57 2013 +0100 Committer: Sylvain Lebresne Committed: Fri Mar 1 17:05:57 2013 +0100 -- CHANGES.txt|1 + .../cassandra/locator/PropertyFileSnitch.java |4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a562636e/CHANGES.txt --
[jira] [Assigned] (CASSANDRA-5301) Clean up bash scripts in bin/ and tools/bin/
[ https://issues.apache.org/jira/browse/CASSANDRA-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson reassigned CASSANDRA-5301: -- Assignee: Marcus Eriksson > Clean up bash scripts in bin/ and tools/bin/ > > > Key: CASSANDRA-5301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5301 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Trivial > > there is alot of copy-and-pasting going on in the scripts in bin/ and > tools/bin/, create a script to include in the various tool-scripts, it should > do classpath and config file detection etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5182) Deletable rows are sometimes not removed during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590683#comment-13590683 ] Sylvain Lebresne commented on CASSANDRA-5182: - bq. if we say "only disable BF where you're not doing deletes," it has a legitimate if narrow use case I guess I agree on the principle that we should say "only disable BF where you're not doing deletes". That being said, if we do use getPosition, we extend the possible use cases, since it become "only disable BF where you're not doing deletes or your index fit entirely in RAM" (because getPosition will not destroy performance for the "not doing delete case", since we don't even call shouldPurge() unless we know there is tombstones). bq. and IMO the bite from getPosition is worse, since it will destroy compaction performance I'm not totally sure I agree on the worse. As said above, if people have not tombstone, it won't destroy compaction performance. So I guess the question is: for people that 1) do not follow recommendation (cause we should definitively say when disabling BF is ok or not) and that 2) do have deletes, is it better for them to be bitten by a) bad compaction performance or b) their tombstones not being purged ever. I don't doubt that which of a) or b) is worse is a matter of perspective. That being said, my own personal preference goes to avoiding because: * to me b) is a break of correctness which somewhat trumps performance consideration. It purely subjective though. * accumulating tombstones forever is a pretty nasty time-bomb. Having compaction being slow because it hit disk more than it should on the other seems easier to me to detect (and thus fix by following the recommendation of not disabling BF when you shouldn't). So, I still have a preference for using Yuki's last patch (and making it clear that you shall "only disable BF where you're not doing deletes or your index fit entirely in RAM"). If only because that's a bit better than "only disable BF where you're not doing deletes". But if you still prefer keeping the status quo, I won't oppose, do feel free to close that issue (we still should write the recommendation on when to disable BF somewhere in any case). > Deletable rows are sometimes not removed during compaction > -- > > Key: CASSANDRA-5182 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5182 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.7 >Reporter: Binh Van Nguyen >Assignee: Yuki Morishita > Fix For: 1.2.3 > > Attachments: 5182-1.1.txt, 5182-1.2.txt, test_ttl.tar.gz > > > Our use case is write heavy and read seldom. To optimize the space used, > we've set the bloom_filter_fp_ratio=1.0 That along with the fact that each > row is only written to one time and that there are more than 20 SSTables > keeps the rows from ever being compacted. Here is the code: > https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionController.java#L162 > We hit this conner case and because of this C* keeps consuming more and more > space on disk while it should not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590705#comment-13590705 ] Cristian Opris commented on CASSANDRA-5062: --- There is this paper that might be of interest, Consensus on Transaction Commit: http://research.microsoft.com/apps/pubs/default.aspx?id=64636 I haven't yet studied it in detail but may give some ideas. "Paxos made live" seems centered on the idea of having a replicated log. Not sure this applies to what we want to do. There are details on how to do that however in the papers cited, the more relevant I think: Lampson, B. W. How to build a highly available system using consensus. Schneider, F. B. Implementing fault-tolerant services using the state machine approach: A tutorial. Google has links to the papers > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5303) Executing SELECT which uses IN() function, on table with set<> column , returns 'Internal application error'.
Krzysztof Cieslinski Cognitum created CASSANDRA-5303:
Summary: Executing SELECT which uses IN() function, on table with
set<> column , returns 'Internal application error'.
Key: CASSANDRA-5303
URL: https://issues.apache.org/jira/browse/CASSANDRA-5303
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Krzysztof Cieslinski Cognitum
Priority: Minor
For the following table:
{code}CREATE TABLE "Tweets"(
tweet_id uuid,
idx int,
exampleset set,
PRIMARY KEY(tweet_id,idx));{code}
This query:
{code}SELECT idx,tweet_id FROM "Tweets" WHERE idx IN (0, 1, 2) ALLOW
FILTERING;{code}
Returns:
_'Internal application error'_
Comment:
This error won't occur if insted of "IN (0, 1, 2)" we will use "IN (0)" (in
select query).
Comment2:
This error won't occur if we will create table as above, but without set<>
column.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5304) Being able to delete by index
Joachim Haagen Skeie created CASSANDRA-5304: --- Summary: Being able to delete by index Key: CASSANDRA-5304 URL: https://issues.apache.org/jira/browse/CASSANDRA-5304 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.2 Reporter: Joachim Haagen Skeie Priority: Minor I have a Column Family with the following index: CREATE INDEX live_stat_is_calculated ON live_statistics (iscalculated) Then, I would like to delete records based on this index via CQL3 query: delete from live_statistics where iscalculated = true; But Cassandra returns the following error: PRIMARY KEY part iscalculated found in SET part -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-5303) Executing SELECT which uses IN() function, on table with set<> column , returns 'Internal application error'.
[
https://issues.apache.org/jira/browse/CASSANDRA-5303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne reassigned CASSANDRA-5303:
---
Assignee: Sylvain Lebresne
> Executing SELECT which uses IN() function, on table with set<> column ,
> returns 'Internal application error'.
> --
>
> Key: CASSANDRA-5303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5303
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.2.2
>Reporter: Krzysztof Cieslinski Cognitum
>Assignee: Sylvain Lebresne
>Priority: Minor
>
> For the following table:
> {code}CREATE TABLE "Tweets"(
> tweet_id uuid,
> idx int,
> exampleset set,
> PRIMARY KEY(tweet_id,idx));{code}
> This query:
> {code}SELECT idx,tweet_id FROM "Tweets" WHERE idx IN (0, 1, 2) ALLOW
> FILTERING;{code}
> Returns:
> _'Internal application error'_
> Comment:
> This error won't occur if insted of "IN (0, 1, 2)" we will use "IN (0)" (in
> select query).
> Comment2:
> This error won't occur if we will create table as above, but without set<>
> column.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "Melisa08W" by Melisa08W
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Melisa08W" page has been changed by Melisa08W: http://wiki.apache.org/cassandra/Melisa08W New page: Hey fellas !! The name is NOVELLA POPE. I reside in Ogden.<> I am turning 57. I want to become a Computer programmer.<> <> Feel free to surf to my blog: [[http://www.blindchildrenscenter.org/cheapbeatsheadphones.html|headphones beats]]
[jira] [Created] (CASSANDRA-5305) clqsh COPY is broken after strictening validation in 1.2.2 (quotes ints)
Aleksey Yeschenko created CASSANDRA-5305: Summary: clqsh COPY is broken after strictening validation in 1.2.2 (quotes ints) Key: CASSANDRA-5305 URL: https://issues.apache.org/jira/browse/CASSANDRA-5305 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.2 Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko Priority: Minor Fix For: 1.2.3 cqlsh COPY is quoting values when it shouldn't, and that's throwing IRE in 1.2.2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "JimhzJ59" by JimhzJ59
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "JimhzJ59" page has been changed by JimhzJ59: http://wiki.apache.org/cassandra/JimhzJ59 New page: Hi !! I am CHRISTIA MCCARTHY. I might join The Limited Finishing School built at Elkhart.<> I am planning to become a Interpreter. I am a fan of Golfing. My dad name is John and he is a Photographer. My mummy is a Operator.<> <> My blog: [[http://www.reachbeatsbydre.com|dre headphones]]
[jira] [Commented] (CASSANDRA-5081) Support null values in PreparedStatements parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590785#comment-13590785 ] Aleksey Yeschenko commented on CASSANDRA-5081: -- +1 > Support null values in PreparedStatements parameters > > > Key: CASSANDRA-5081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5081 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Michaël Figuière >Assignee: Sylvain Lebresne > Fix For: 1.2.3 > > Attachments: 5081.txt > > > Currently whenever developers want to use PreparedStatements, they need to > ensure that all their parameters are non null or they need to have several > PreparedStatements for each possible set of non null columns they want to > store. This is obviously not a satisfying solution considering that 'null' > values are a commonplace in applications. > 'null' values should be allowed as parameters of PreparedStatements in Binary > Protocol to solve this issue. > This issue is obviously tightly coupled with CASSANDRA-3783 but they might be > fixed separately. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: cqlsh: Ninja-alter blob formatter (prepend '0x')
Updated Branches:
refs/heads/cassandra-1.2 709381387 -> 56b19f4af
cqlsh: Ninja-alter blob formatter (prepend '0x')
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/56b19f4a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/56b19f4a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/56b19f4a
Branch: refs/heads/cassandra-1.2
Commit: 56b19f4af3816aa2f3d1dec26f90179f8b3609cb
Parents: 7093813
Author: Aleksey Yeschenko
Authored: Fri Mar 1 21:54:54 2013 +0300
Committer: Aleksey Yeschenko
Committed: Fri Mar 1 21:54:54 2013 +0300
--
pylib/cqlshlib/formatting.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/56b19f4a/pylib/cqlshlib/formatting.py
--
diff --git a/pylib/cqlshlib/formatting.py b/pylib/cqlshlib/formatting.py
index 6322caf..b970eb9 100644
--- a/pylib/cqlshlib/formatting.py
+++ b/pylib/cqlshlib/formatting.py
@@ -107,7 +107,7 @@ def formatter_for(typname):
@formatter_for('blob')
def format_value_blob(val, colormap, **_):
-bval = ''.join('%02x' % ord(c) for c in val)
+bval = '0x' + ''.join('%02x' % ord(c) for c in val)
return colorme(bval, colormap, 'hex')
def format_python_formatted_type(val, colormap, color):
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/trunk a562636e5 -> 224a6f456 Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/224a6f45 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/224a6f45 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/224a6f45 Branch: refs/heads/trunk Commit: 224a6f456a49db10ef4cd8763aa8db73f667fa10 Parents: a562636 56b19f4 Author: Aleksey Yeschenko Authored: Fri Mar 1 21:56:05 2013 +0300 Committer: Aleksey Yeschenko Committed: Fri Mar 1 21:56:05 2013 +0300 -- pylib/cqlshlib/formatting.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --
[1/2] git commit: cqlsh: Ninja-alter blob formatter (prepend '0x')
cqlsh: Ninja-alter blob formatter (prepend '0x')
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/56b19f4a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/56b19f4a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/56b19f4a
Branch: refs/heads/trunk
Commit: 56b19f4af3816aa2f3d1dec26f90179f8b3609cb
Parents: 7093813
Author: Aleksey Yeschenko
Authored: Fri Mar 1 21:54:54 2013 +0300
Committer: Aleksey Yeschenko
Committed: Fri Mar 1 21:54:54 2013 +0300
--
pylib/cqlshlib/formatting.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/56b19f4a/pylib/cqlshlib/formatting.py
--
diff --git a/pylib/cqlshlib/formatting.py b/pylib/cqlshlib/formatting.py
index 6322caf..b970eb9 100644
--- a/pylib/cqlshlib/formatting.py
+++ b/pylib/cqlshlib/formatting.py
@@ -107,7 +107,7 @@ def formatter_for(typname):
@formatter_for('blob')
def format_value_blob(val, colormap, **_):
-bval = ''.join('%02x' % ord(c) for c in val)
+bval = '0x' + ''.join('%02x' % ord(c) for c in val)
return colorme(bval, colormap, 'hex')
def format_python_formatted_type(val, colormap, color):
[jira] [Commented] (CASSANDRA-4795) replication, compaction, compression? options are not validated
[ https://issues.apache.org/jira/browse/CASSANDRA-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590852#comment-13590852 ] Pavel Yaskevich commented on CASSANDRA-4795: bq. Show me an existing database that lets you attach random crap to a table definition and I will reconsider my position. What is HBase? bq. So, does the absence of review of my 2 first patches mean that everyone decided the status quo was ok? Cause I could live with that. But if we think this should be reverted from 1.2 then let's do that sooner than later. I'm fine with those, I'm fine even with removing those as soon as system doesn't crap on startup. > replication, compaction, compression? options are not validated > --- > > Key: CASSANDRA-4795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4795 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 >Reporter: Brandon Williams >Assignee: Dave Brosius >Priority: Minor > Fix For: 1.2.1 > > Attachments: 0001-Reallow-unexpected-strategy-options-for-thrift.txt, > 0002-Reallow-unexpected-strategy-options-for-thrift.txt, > 0003-Adds-application_metadata-field-to-ks-metadata.txt, > 4795.compaction_strategy.txt, 4795_compaction_strategy_v2.txt, > 4795_compaction_strategy_v3.txt, 4795.replication_strategy.txt > > > When creating a keyspace and specifying strategy options, you can pass any > k/v pair you like. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5182) Deletable rows are sometimes not removed during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590940#comment-13590940 ] Jonathan Ellis commented on CASSANDRA-5182: --- bq. if we do use getPosition, we extend the possible use cases, since it become "only disable BF where you're not doing deletes or your index fit entirely in RAM" That makes sense. Let's ship Yuki's patch. > Deletable rows are sometimes not removed during compaction > -- > > Key: CASSANDRA-5182 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5182 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.0.7 >Reporter: Binh Van Nguyen >Assignee: Yuki Morishita > Fix For: 1.2.3 > > Attachments: 5182-1.1.txt, 5182-1.2.txt, test_ttl.tar.gz > > > Our use case is write heavy and read seldom. To optimize the space used, > we've set the bloom_filter_fp_ratio=1.0 That along with the fact that each > row is only written to one time and that there are more than 20 SSTables > keeps the rows from ever being compacted. Here is the code: > https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionController.java#L162 > We hit this conner case and because of this C* keeps consuming more and more > space on disk while it should not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5304) Clarify error message when delete predicate does not specify the PK
[ https://issues.apache.org/jira/browse/CASSANDRA-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5304: -- Summary: Clarify error message when delete predicate does not specify the PK (was: Being able to delete by index) > Clarify error message when delete predicate does not specify the PK > --- > > Key: CASSANDRA-5304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5304 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.2 >Reporter: Joachim Haagen Skeie >Priority: Minor > > I have a Column Family with the following index: > CREATE INDEX live_stat_is_calculated ON live_statistics (iscalculated) > Then, I would like to delete records based on this index via CQL3 query: > delete from live_statistics where iscalculated = true; > But Cassandra returns the following error: > PRIMARY KEY part iscalculated found in SET part -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5062: -- Attachment: half-baked commit 3.jpg half-baked commit 2.jpg half-baked commit 1.jpg Attached some diagrams for what I am talking about. # shows a no-failures round. (N+1 looks exactly the same, so omitted.) # shows how mostRecentCommitted saves us from "resurrecting" and aborted write # seems to imply that we still need to keep a full log of all operations the way Sylvain suggests, which makes me sad > Support CAS > --- > > Key: CASSANDRA-5062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Jonathan Ellis > Fix For: 2.0 > > Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, > half-baked commit 3.jpg > > > "Strong" consistency is not enough to prevent race conditions. The classic > example is user account creation: we want to ensure usernames are unique, so > we only want to signal account creation success if nobody else has created > the account yet. But naive read-then-write allows clients to race and both > think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "LyndonCom" by LyndonCom
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "LyndonCom" page has been changed by LyndonCom: http://wiki.apache.org/cassandra/LyndonCom New page: Hey guys !! I am CHARISE MEADOWS. I am from Minneapolis.<> My school's name is The Confidential School of Jittery Education which has a branch in Clearwater. I work as a Undertaker. My papa name is Ryan and he is a Pediatrician. My mom is a Veterinarian.<> <> Visit my page ... [[http://www.conreplicahandbags.com|cheap handbags]]
[Cassandra Wiki] Trivial Update of "AbelFaber" by AbelFaber
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "AbelFaber" page has been changed by AbelFaber: http://wiki.apache.org/cassandra/AbelFaber New page: Wassp People !! The name is RANDY QUINN. I am taking admission in The Confidential Prep School in Provo.<> I am working as Scout. My hobby is Hunting. My papa name is Brooke and he is a Geophysicist. My mother is a Archeologist.<> <> Here is my homepage - [[http://www.conreplicahandbags.com|cheap designer handbags]]
[jira] [Commented] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[ https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591228#comment-13591228 ] Brandon Williams commented on CASSANDRA-5051: - bq. But is there potential for us to also throw away data that we shouldn't if we get behind on gossip somehow? I don't see how. We're fairly well protected by persisting the ring, but even without that if we're behind, don't we just own more than we should? This was the impetus for persisting the ring. > Allow automatic cleanup after gc_grace > -- > > Key: CASSANDRA-5051 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5051 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Labels: vnodes > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-5051.patch, 5051-v2.txt > > > When using vnodes, after adding a new node you have to run cleanup on all the > machines, because you don't know which are affected and chances are it was > most if not all of them. As an alternative to this intensive process, we > could allow cleanup during compaction if the data is older than gc_grace (or > perhaps some other time period since people tend to use gc_grace hacks to get > rid of tombstones.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5306) Improve Dsnitch Severity
Vijay created CASSANDRA-5306: Summary: Improve Dsnitch Severity Key: CASSANDRA-5306 URL: https://issues.apache.org/jira/browse/CASSANDRA-5306 Project: Cassandra Issue Type: Improvement Reporter: Vijay Priority: Minor This ticket is to continue the discussion in CASSANDRA-5255. Currently Dsnitch reports the Severity by calculating the amount of data compacting relative to load of the node. It will be nice to report Severity as a factor of load average, N/W Throughput and IO Wait instead. http://www.hyperic.com/products/sigar seem to have it (But personally i have not used it). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: dsnitch severity is not correctly set for compaction info patch by Vijay; reviewed by jbellis for CASSANDRA-5255
Updated Branches:
refs/heads/cassandra-1.2 56b19f4af -> 71b2bd15d
dsnitch severity is not correctly set for compaction info
patch by Vijay; reviewed by jbellis for CASSANDRA-5255
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71b2bd15
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71b2bd15
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71b2bd15
Branch: refs/heads/cassandra-1.2
Commit: 71b2bd15d2957e04eae8cc650a6b48b75deabe58
Parents: 56b19f4
Author: Vijay Parthasarathy
Authored: Fri Mar 1 18:40:04 2013 -0800
Committer: Vijay Parthasarathy
Committed: Fri Mar 1 18:40:04 2013 -0800
--
.../cassandra/db/compaction/CompactionInfo.java| 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71b2bd15/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
b/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
index 295e34f..da67bab 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
@@ -122,7 +122,7 @@ public final class CompactionInfo implements Serializable
private volatile boolean stopRequested = false;
public abstract CompactionInfo getCompactionInfo();
double load = StorageService.instance.getLoad();
-boolean reportedSeverity = false;
+double reportedSeverity = 0d;
public void stop()
{
@@ -138,7 +138,9 @@ public final class CompactionInfo implements Serializable
*/
public void started()
{
-reportedSeverity =
StorageService.instance.reportSeverity(getCompactionInfo().getTotal()/load);
+reportedSeverity = getCompactionInfo().getTotal() / load;
+if (!StorageService.instance.reportSeverity(reportedSeverity))
+reportedSeverity = 0d;
}
/**
@@ -146,9 +148,9 @@ public final class CompactionInfo implements Serializable
*/
public void finished()
{
-if (reportedSeverity)
-
StorageService.instance.reportSeverity(-(getCompactionInfo().getTotal()/load));
-reportedSeverity = false;
+if (reportedSeverity != 0d)
+StorageService.instance.reportSeverity(-(reportedSeverity));
+reportedSeverity = 0d;
}
}
}
[1/2] git commit: dsnitch severity is not correctly set for compaction info patch by Vijay; reviewed by jbellis for CASSANDRA-5255
dsnitch severity is not correctly set for compaction info
patch by Vijay; reviewed by jbellis for CASSANDRA-5255
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71b2bd15
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71b2bd15
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71b2bd15
Branch: refs/heads/trunk
Commit: 71b2bd15d2957e04eae8cc650a6b48b75deabe58
Parents: 56b19f4
Author: Vijay Parthasarathy
Authored: Fri Mar 1 18:40:04 2013 -0800
Committer: Vijay Parthasarathy
Committed: Fri Mar 1 18:40:04 2013 -0800
--
.../cassandra/db/compaction/CompactionInfo.java| 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71b2bd15/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
b/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
index 295e34f..da67bab 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java
@@ -122,7 +122,7 @@ public final class CompactionInfo implements Serializable
private volatile boolean stopRequested = false;
public abstract CompactionInfo getCompactionInfo();
double load = StorageService.instance.getLoad();
-boolean reportedSeverity = false;
+double reportedSeverity = 0d;
public void stop()
{
@@ -138,7 +138,9 @@ public final class CompactionInfo implements Serializable
*/
public void started()
{
-reportedSeverity =
StorageService.instance.reportSeverity(getCompactionInfo().getTotal()/load);
+reportedSeverity = getCompactionInfo().getTotal() / load;
+if (!StorageService.instance.reportSeverity(reportedSeverity))
+reportedSeverity = 0d;
}
/**
@@ -146,9 +148,9 @@ public final class CompactionInfo implements Serializable
*/
public void finished()
{
-if (reportedSeverity)
-
StorageService.instance.reportSeverity(-(getCompactionInfo().getTotal()/load));
-reportedSeverity = false;
+if (reportedSeverity != 0d)
+StorageService.instance.reportSeverity(-(reportedSeverity));
+reportedSeverity = 0d;
}
}
}
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/trunk 224a6f456 -> 589fd5979 Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/589fd597 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/589fd597 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/589fd597 Branch: refs/heads/trunk Commit: 589fd5979d647e00c157bcb9ab99257de3e44cc7 Parents: 224a6f4 71b2bd1 Author: Vijay Parthasarathy Authored: Fri Mar 1 18:43:09 2013 -0800 Committer: Vijay Parthasarathy Committed: Fri Mar 1 18:43:09 2013 -0800 -- .../cassandra/db/compaction/CompactionInfo.java| 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) --
[Cassandra Wiki] Trivial Update of "VickeyIng" by VickeyIng
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "VickeyIng" page has been changed by VickeyIng: http://wiki.apache.org/cassandra/VickeyIng New page: Wassp People !! My name is CLYDE MOONEY. I want to study at The Patient Military School built at Dayton.<> I want to become a Matador. I also like to Scrapbooking. My papa name is Timothy and he is a Orthodontist. My mummy is a Tutor.<> <> Feel free to visit my page; [[http://www.reachbeatsbydre.com|monster beats]]
git commit: more descriptive exception message
Updated Branches:
refs/heads/cassandra-1.2 71b2bd15d -> 8261aa083
more descriptive exception message
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8261aa08
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8261aa08
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8261aa08
Branch: refs/heads/cassandra-1.2
Commit: 8261aa0837646c1d50bcb0fcd0809cde84fe63c5
Parents: 71b2bd1
Author: Dave Brosius
Authored: Sat Mar 2 00:00:58 2013 -0500
Committer: Dave Brosius
Committed: Sat Mar 2 00:00:58 2013 -0500
--
.../cassandra/cql3/statements/DeleteStatement.java |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8261aa08/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
b/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
index c004d72..bb0e8cf 100644
--- a/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
@@ -150,7 +150,7 @@ public class DeleteStatement extends ModificationStatement
{
CFDefinition.Name name = cfDef.get(deletion.affectedColumn());
if (name == null)
-throw new InvalidRequestException(String.format("Unknown
identifier %s", name));
+throw new InvalidRequestException(String.format("Unknown
identifier %s", deletion.affectedColumn()));
// For compact, we only have one value except the key, so the only
form of DELETE that make sense is without a column
// list. However, we support having the value name for coherence
with the static/sparse case
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/trunk 589fd5979 -> 4f0c4b7a2 Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4f0c4b7a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4f0c4b7a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4f0c4b7a Branch: refs/heads/trunk Commit: 4f0c4b7a206a58295b066707fe7e0322ee1bb642 Parents: 589fd59 8261aa0 Author: Dave Brosius Authored: Sat Mar 2 00:01:53 2013 -0500 Committer: Dave Brosius Committed: Sat Mar 2 00:01:53 2013 -0500 -- .../cassandra/cql3/statements/DeleteStatement.java |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4f0c4b7a/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java --
[1/2] git commit: more descriptive exception message
more descriptive exception message
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8261aa08
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8261aa08
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8261aa08
Branch: refs/heads/trunk
Commit: 8261aa0837646c1d50bcb0fcd0809cde84fe63c5
Parents: 71b2bd1
Author: Dave Brosius
Authored: Sat Mar 2 00:00:58 2013 -0500
Committer: Dave Brosius
Committed: Sat Mar 2 00:00:58 2013 -0500
--
.../cassandra/cql3/statements/DeleteStatement.java |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8261aa08/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
b/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
index c004d72..bb0e8cf 100644
--- a/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java
@@ -150,7 +150,7 @@ public class DeleteStatement extends ModificationStatement
{
CFDefinition.Name name = cfDef.get(deletion.affectedColumn());
if (name == null)
-throw new InvalidRequestException(String.format("Unknown
identifier %s", name));
+throw new InvalidRequestException(String.format("Unknown
identifier %s", deletion.affectedColumn()));
// For compact, we only have one value except the key, so the only
form of DELETE that make sense is without a column
// list. However, we support having the value name for coherence
with the static/sparse case
[jira] [Updated] (CASSANDRA-5181) cassandra-all 1.2.0 pom missing netty dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-5181: Reviewer: dbrosius > cassandra-all 1.2.0 pom missing netty dependency > > > Key: CASSANDRA-5181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5181 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Affects Versions: 1.2.0 >Reporter: Carl Lerche >Priority: Minor > Attachments: 5181.txt > > > It seems that cassandra depends on netty now, however the pom excludes this > dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5181) cassandra-all 1.2.0 pom missing netty dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591323#comment-13591323 ] Dave Brosius commented on CASSANDRA-5181: - +1 lgtm > cassandra-all 1.2.0 pom missing netty dependency > > > Key: CASSANDRA-5181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5181 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Affects Versions: 1.2.0 >Reporter: Carl Lerche >Priority: Minor > Attachments: 5181.txt > > > It seems that cassandra depends on netty now, however the pom excludes this > dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5181) cassandra-all 1.2.0 pom missing netty dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-5181: Assignee: Sylvain Lebresne > cassandra-all 1.2.0 pom missing netty dependency > > > Key: CASSANDRA-5181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5181 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Affects Versions: 1.2.0 >Reporter: Carl Lerche >Assignee: Sylvain Lebresne >Priority: Minor > Attachments: 5181.txt > > > It seems that cassandra depends on netty now, however the pom excludes this > dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "RichelleW" by RichelleW
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "RichelleW" page has been changed by RichelleW: http://wiki.apache.org/cassandra/RichelleW New page: Howdy !! My name is MAY HALL. I belong to Danbury. I have a job as Architect.<> My hobby is Digital Photography. My dad name is Bradley and he is a Politician. My mummy is a Cabinet-maker.<> <> Here is my web page; [[http://www.dressesd.com|simple wedding dresses]]
[jira] [Commented] (CASSANDRA-5305) clqsh COPY is broken after strictening validation in 1.2.2 (quotes ints)
[ https://issues.apache.org/jira/browse/CASSANDRA-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591347#comment-13591347 ] Pushkar commented on CASSANDRA-5305: Any workaround for this issue? Not being able to use COPY cmd makes things difficult.. > clqsh COPY is broken after strictening validation in 1.2.2 (quotes ints) > > > Key: CASSANDRA-5305 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5305 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.2.2 >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Minor > Labels: cqlsh > Fix For: 1.2.3 > > > cqlsh COPY is quoting values when it shouldn't, and that's throwing IRE in > 1.2.2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
