[jira] [Commented] (CASSANDRA-6601) WRITETIME of a null value does not return a time
[
https://issues.apache.org/jira/browse/CASSANDRA-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876210#comment-13876210
]
Aleksey Yeschenko commented on CASSANDRA-6601:
--
bq. In other words: had it been the case that writing null to a column was the
same as deleting it I would not have thought this a bug.
It actually is the same. There is no such thing as 'null value', UPDATE SET foo
= null is strictly equivalent to DELETE foo FROM, they'll produce the same cell
tombstone.
> WRITETIME of a null value does not return a time
>
>
> Key: CASSANDRA-6601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6601
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.2
>Reporter: Theo Hultberg
>
> When a cell's value is {{null}} the CQL {{WRITETIME}} function returns null.
> I was expecting it to return a timestamp. Looking at the data in
> {{cassandra-cli}} I can see that the cell has a timestamp.
> Here's a session showing the issue:
> {code}
> cqlsh> CREATE KEYSPACE writetime_test WITH replication = {'class':
> 'SimpleStrategy','replication_factor': '1'};
> cqlsh> USE writetime_test;
> cqlsh:writetime_test> CREATE TABLE writetime_test_table (pk INT, ck INT,
> value INT, PRIMARY KEY (pk, ck));
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (1, 2, null);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 1 AND ck = 2;
> writetime(value)
> --
> null
> (1 rows)
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (2, 3, 4);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 2 AND ck = 3;
> writetime(value)
> --
> 1389967663822000
> (1 rows)
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 3 AND ck = 4;
> (0 rows)
> {code}
> I first insert data where the cell value is {{null}}. When I query its
> writetime I get a row back, but the timestamp is {{null}}.
> I then insert a row with a value, and get a timestamp in the query results,
> as expected.
> Finally I query for the writetime of a cell that does not exist, and get no
> rows back, just to show that there's a difference between calling
> {{WRITETIME}} on {{null}} and on something that doesn't exist.
> Even though the value is {{null}} the cell exists and it has a timestamp. I
> can clearly see the timestamp using {{cassandra-cli}}:
> {code}
> [default@unknown] use writetime_test;
> Authenticated to keyspace: writetime_test
> [default@writetime_test] list writetime_test_table;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 1
> => (name=2:, value=, timestamp=1389967959822000)
> ---
> RowKey: 2
> => (name=3:, value=, timestamp=1389967964749000)
> => (name=3:value, value=0004, timestamp=1389967964749000)
> {code}
> The reason I want to get the {{WRITETIME}} of a {{null}} value is that I have
> a table where I don't care about the value, I use the column keys as sorted
> set. I still want to know when some of them were written though, but I can't
> ask for the {{WRITETIME}} of something that is part of the primary key, so I
> must use the (otherwise unused) value.
> A workaround is to write some dummy value in the cell, and that's probably
> what I need to do, but this felt like it was a bug, it was at least not what
> I expected.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6601) WRITETIME of a null value does not return a time
[
https://issues.apache.org/jira/browse/CASSANDRA-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876182#comment-13876182
]
Theo Hultberg commented on CASSANDRA-6601:
--
In other words: had it been the case that writing null to a column was the same
as deleting it I would not have thought this a bug.
> WRITETIME of a null value does not return a time
>
>
> Key: CASSANDRA-6601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6601
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.2
>Reporter: Theo Hultberg
>
> When a cell's value is {{null}} the CQL {{WRITETIME}} function returns null.
> I was expecting it to return a timestamp. Looking at the data in
> {{cassandra-cli}} I can see that the cell has a timestamp.
> Here's a session showing the issue:
> {code}
> cqlsh> CREATE KEYSPACE writetime_test WITH replication = {'class':
> 'SimpleStrategy','replication_factor': '1'};
> cqlsh> USE writetime_test;
> cqlsh:writetime_test> CREATE TABLE writetime_test_table (pk INT, ck INT,
> value INT, PRIMARY KEY (pk, ck));
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (1, 2, null);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 1 AND ck = 2;
> writetime(value)
> --
> null
> (1 rows)
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (2, 3, 4);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 2 AND ck = 3;
> writetime(value)
> --
> 1389967663822000
> (1 rows)
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 3 AND ck = 4;
> (0 rows)
> {code}
> I first insert data where the cell value is {{null}}. When I query its
> writetime I get a row back, but the timestamp is {{null}}.
> I then insert a row with a value, and get a timestamp in the query results,
> as expected.
> Finally I query for the writetime of a cell that does not exist, and get no
> rows back, just to show that there's a difference between calling
> {{WRITETIME}} on {{null}} and on something that doesn't exist.
> Even though the value is {{null}} the cell exists and it has a timestamp. I
> can clearly see the timestamp using {{cassandra-cli}}:
> {code}
> [default@unknown] use writetime_test;
> Authenticated to keyspace: writetime_test
> [default@writetime_test] list writetime_test_table;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 1
> => (name=2:, value=, timestamp=1389967959822000)
> ---
> RowKey: 2
> => (name=3:, value=, timestamp=1389967964749000)
> => (name=3:value, value=0004, timestamp=1389967964749000)
> {code}
> The reason I want to get the {{WRITETIME}} of a {{null}} value is that I have
> a table where I don't care about the value, I use the column keys as sorted
> set. I still want to know when some of them were written though, but I can't
> ask for the {{WRITETIME}} of something that is part of the primary key, so I
> must use the (otherwise unused) value.
> A workaround is to write some dummy value in the cell, and that's probably
> what I need to do, but this felt like it was a bug, it was at least not what
> I expected.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6601) WRITETIME of a null value does not return a time
[
https://issues.apache.org/jira/browse/CASSANDRA-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876180#comment-13876180
]
Theo Hultberg commented on CASSANDRA-6601:
--
There is a difference between having the value null in a column and having no
column, as I showed in the report. When the column isn't there I get no rows
back, when the column has the value null I get null back.
I'm using the row as a sorted set, so I write null as the value since I only
care about the column key. The key exists, but since the value is null I can't
find the writetime of the key. If I wrote a 0, an empty string or any non-null
value I could get the key writetime.
In this case null is a value, I've explicitly set the column to null. It is
also, demonstrably, different from a non-existent column. I think that it
should have a writetime. Yes I could stop writing null, and I will, but I still
think it's a bug that the value null is special, and its own state, different
from other values, and different from no vaue (i.e. a non-existent column).
> WRITETIME of a null value does not return a time
>
>
> Key: CASSANDRA-6601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6601
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.2
>Reporter: Theo Hultberg
>
> When a cell's value is {{null}} the CQL {{WRITETIME}} function returns null.
> I was expecting it to return a timestamp. Looking at the data in
> {{cassandra-cli}} I can see that the cell has a timestamp.
> Here's a session showing the issue:
> {code}
> cqlsh> CREATE KEYSPACE writetime_test WITH replication = {'class':
> 'SimpleStrategy','replication_factor': '1'};
> cqlsh> USE writetime_test;
> cqlsh:writetime_test> CREATE TABLE writetime_test_table (pk INT, ck INT,
> value INT, PRIMARY KEY (pk, ck));
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (1, 2, null);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 1 AND ck = 2;
> writetime(value)
> --
> null
> (1 rows)
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (2, 3, 4);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 2 AND ck = 3;
> writetime(value)
> --
> 1389967663822000
> (1 rows)
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 3 AND ck = 4;
> (0 rows)
> {code}
> I first insert data where the cell value is {{null}}. When I query its
> writetime I get a row back, but the timestamp is {{null}}.
> I then insert a row with a value, and get a timestamp in the query results,
> as expected.
> Finally I query for the writetime of a cell that does not exist, and get no
> rows back, just to show that there's a difference between calling
> {{WRITETIME}} on {{null}} and on something that doesn't exist.
> Even though the value is {{null}} the cell exists and it has a timestamp. I
> can clearly see the timestamp using {{cassandra-cli}}:
> {code}
> [default@unknown] use writetime_test;
> Authenticated to keyspace: writetime_test
> [default@writetime_test] list writetime_test_table;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 1
> => (name=2:, value=, timestamp=1389967959822000)
> ---
> RowKey: 2
> => (name=3:, value=, timestamp=1389967964749000)
> => (name=3:value, value=0004, timestamp=1389967964749000)
> {code}
> The reason I want to get the {{WRITETIME}} of a {{null}} value is that I have
> a table where I don't care about the value, I use the column keys as sorted
> set. I still want to know when some of them were written though, but I can't
> ask for the {{WRITETIME}} of something that is part of the primary key, so I
> must use the (otherwise unused) value.
> A workaround is to write some dummy value in the cell, and that's probably
> what I need to do, but this felt like it was a bug, it was at least not what
> I expected.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6590) Gossip does not heal after a temporary partition at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876166#comment-13876166 ] Brandon Williams commented on CASSANDRA-6590: - bq. Nit: do_firewall_check is true by default in the yaml but is false in config. I did that on purpose, so someone who isn't diffing the yamls between minors doesn't run into any problems with it, and presumably no firewall problems are going to materialize during a rolling restart. I'll take a look at the patch when I have more time. > Gossip does not heal after a temporary partition at startup > --- > > Key: CASSANDRA-6590 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6590 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Fix For: 2.0.5 > > Attachments: 0001-CASSANDRA-6590.patch, 6590_disable_echo.txt > > > See CASSANDRA-6571 for background. If a node is partitioned on startup when > the echo command is sent, but then the partition heals, the halves of the > partition will never mark each other up despite being able to communicate. > This stems from CASSANDRA-3533. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6590) Gossip does not heal after a temporary partition at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-6590: - Attachment: 0001-CASSANDRA-6590.patch Nit: do_firewall_check is true by default in the yaml but is false in config. Attached patch is on top of the original patch by brandon, Sets the hibernate state (Dead state) as step 1 in joinTokenRing which will be later changed at the end of the method to normal. The main fix (IMHO) is in the OTCP where we timeout so we can reconnect, when the socket hangs and makes the connection un-useable during temp network partition. Please note: this patch changes the streaming_socket_timeout_in_ms configuration to socket_timeout_in_ms and reuses them. > Gossip does not heal after a temporary partition at startup > --- > > Key: CASSANDRA-6590 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6590 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Fix For: 2.0.5 > > Attachments: 0001-CASSANDRA-6590.patch, 6590_disable_echo.txt > > > See CASSANDRA-6571 for background. If a node is partitioned on startup when > the echo command is sent, but then the partition heals, the halves of the > partition will never mark each other up despite being able to communicate. > This stems from CASSANDRA-3533. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[2/4] git commit: Merge branch 'cassandra-1.2' of http://git-wip-us.apache.org/repos/asf/cassandra into cassandra-1.2
Merge branch 'cassandra-1.2' of http://git-wip-us.apache.org/repos/asf/cassandra into cassandra-1.2 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3575fdcc Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3575fdcc Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3575fdcc Branch: refs/heads/trunk Commit: 3575fdccb7b9dee720c06d133aa5895bf0bb0787 Parents: d387240 9be437b Author: Sylvain Lebresne Authored: Sun Jan 19 19:28:24 2014 -0800 Committer: Sylvain Lebresne Committed: Sun Jan 19 19:28:24 2014 -0800 -- CHANGES.txt | 3 + conf/cassandra-env.sh | 15 ++-- .../apache/cassandra/db/BatchlogManager.java| 78 +++ .../apache/cassandra/net/MessagingService.java | 15 +--- .../cassandra/service/StorageService.java | 21 - .../cassandra/thrift/CustomTHsHaServer.java | 7 +- .../cassandra/db/BatchlogManagerTest.java | 82 7 files changed, 178 insertions(+), 43 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3575fdcc/CHANGES.txt -- diff --cc CHANGES.txt index 8626b64,0b49665..639e17c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -10,7 -10,9 +10,10 @@@ * Add ability to throttle batchlog replay (CASSANDRA-6550) * Fix executing LOCAL_QUORUM with SimpleStrategy (CASSANDRA-6545) * Avoid StackOverflow when using large IN queries (CASSANDRA-6567) + * Nodetool upgradesstables includes secondary indexes (CASSANDRA-6589) + * Paginate batchlog replay (CASSANDRA-6569) + * skip blocking on streaming during drain (CASSANDRA-6603) + * Improve error message when schema doesn't match loaded sstable (CASSANDRA-6262) 1.2.13
[4/4] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8e1000f6 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8e1000f6 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8e1000f6 Branch: refs/heads/trunk Commit: 8e1000f602e855faeb62b73eadc2dd597360ae8e Parents: 6aaa023 e9a57fb Author: Sylvain Lebresne Authored: Sun Jan 19 19:38:24 2014 -0800 Committer: Sylvain Lebresne Committed: Sun Jan 19 19:38:24 2014 -0800 -- CHANGES.txt| 1 + .../apache/cassandra/db/marshal/CompositeType.java | 17 +++-- 2 files changed, 16 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8e1000f6/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8e1000f6/src/java/org/apache/cassandra/db/marshal/CompositeType.java --
[1/4] git commit: Improve error message when loaded sstable doesn't match schema
Updated Branches:
refs/heads/trunk 6aaa02317 -> 8e1000f60
Improve error message when loaded sstable doesn't match schema
patch by slebresne; reviewed by driftx for CASSANDRA-6262
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d3872408
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d3872408
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d3872408
Branch: refs/heads/trunk
Commit: d3872408d22ae208a5cb9cdf4c1d76370510459d
Parents: 5f63578
Author: Sylvain Lebresne
Authored: Sun Jan 19 19:24:06 2014 -0800
Committer: Sylvain Lebresne
Committed: Sun Jan 19 19:24:06 2014 -0800
--
CHANGES.txt| 1 +
.../apache/cassandra/db/marshal/CompositeType.java | 17 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d3872408/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 25c105c..8626b64 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* Add ability to throttle batchlog replay (CASSANDRA-6550)
* Fix executing LOCAL_QUORUM with SimpleStrategy (CASSANDRA-6545)
* Avoid StackOverflow when using large IN queries (CASSANDRA-6567)
+ * Improve error message when schema doesn't match loaded sstable
(CASSANDRA-6262)
1.2.13
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d3872408/src/java/org/apache/cassandra/db/marshal/CompositeType.java
--
diff --git a/src/java/org/apache/cassandra/db/marshal/CompositeType.java
b/src/java/org/apache/cassandra/db/marshal/CompositeType.java
index 8cb1e34..138a065 100644
--- a/src/java/org/apache/cassandra/db/marshal/CompositeType.java
+++ b/src/java/org/apache/cassandra/db/marshal/CompositeType.java
@@ -86,12 +86,25 @@ public class CompositeType extends AbstractCompositeType
protected AbstractType getComparator(int i, ByteBuffer bb)
{
-return types.get(i);
+try
+{
+return types.get(i);
+}
+catch (IndexOutOfBoundsException e)
+{
+// We shouldn't get there in general because 1) we shouldn't
construct broken composites
+// from CQL and 2) broken composites coming from thrift should be
rejected by validate.
+// There is a few cases however where, if the schema has changed
since we created/validated
+// the composite, this will be thrown (see #6262). Those cases are
a user error but
+// throwing a more meaningful error message to make understanding
such error easier. .
+throw new RuntimeException("Cannot get comparator " + i + " in " +
this + ". "
+ + "This might due to a mismatch between
the schema and the data read", e);
+}
}
protected AbstractType getComparator(int i, ByteBuffer bb1, ByteBuffer
bb2)
{
-return types.get(i);
+return getComparator(i, bb1);
}
protected AbstractType getAndAppendComparator(int i, ByteBuffer bb,
StringBuilder sb)
[3/4] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e9a57fba Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e9a57fba Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e9a57fba Branch: refs/heads/trunk Commit: e9a57fbaa4ae206c818657a5cc8e06d8fc2b6f57 Parents: 66a8a55 3575fdc Author: Sylvain Lebresne Authored: Sun Jan 19 19:35:50 2014 -0800 Committer: Sylvain Lebresne Committed: Sun Jan 19 19:35:50 2014 -0800 -- CHANGES.txt| 1 + .../apache/cassandra/db/marshal/CompositeType.java | 17 +++-- 2 files changed, 16 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9a57fba/CHANGES.txt -- diff --cc CHANGES.txt index d165c8b,639e17c..b08f04b --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -17,29 -13,10 +17,30 @@@ Merged from 1.2 * Nodetool upgradesstables includes secondary indexes (CASSANDRA-6589) * Paginate batchlog replay (CASSANDRA-6569) * skip blocking on streaming during drain (CASSANDRA-6603) + * Improve error message when schema doesn't match loaded sstable (CASSANDRA-6262) -1.2.13 +2.0.4 + * Allow removing snapshots of no-longer-existing CFs (CASSANDRA-6418) + * add StorageService.stopDaemon() (CASSANDRA-4268) + * add IRE for invalid CF supplied to get_count (CASSANDRA-5701) + * add client encryption support to sstableloader (CASSANDRA-6378) + * Fix accept() loop for SSL sockets post-shutdown (CASSANDRA-6468) + * Fix size-tiered compaction in LCS L0 (CASSANDRA-6496) + * Fix assertion failure in filterColdSSTables (CASSANDRA-6483) + * Fix row tombstones in larger-than-memory compactions (CASSANDRA-6008) + * Fix cleanup ClassCastException (CASSANDRA-6462) + * Reduce gossip memory use by interning VersionedValue strings (CASSANDRA-6410) + * Allow specifying datacenters to participate in a repair (CASSANDRA-6218) + * Fix divide-by-zero in PCI (CASSANDRA-6403) + * Fix setting last compacted key in the wrong level for LCS (CASSANDRA-6284) + * Add millisecond precision formats to the timestamp parser (CASSANDRA-6395) + * Expose a total memtable size metric for a CF (CASSANDRA-6391) + * cqlsh: handle symlinks properly (CASSANDRA-6425) + * Fix potential infinite loop when paging query with IN (CASSANDRA-6464) + * Fix assertion error in AbstractQueryPager.discardFirst (CASSANDRA-6447) + * Fix streaming older SSTable yields unnecessary tombstones (CASSANDRA-6527) +Merged from 1.2: * Improved error message on bad properties in DDL queries (CASSANDRA-6453) * Randomize batchlog candidates selection (CASSANDRA-6481) * Fix thundering herd on endpoint cache invalidation (CASSANDRA-6345, 6485) http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9a57fba/src/java/org/apache/cassandra/db/marshal/CompositeType.java --
[1/3] git commit: Improve error message when loaded sstable doesn't match schema
Updated Branches:
refs/heads/cassandra-2.0 66a8a5575 -> e9a57fbaa
Improve error message when loaded sstable doesn't match schema
patch by slebresne; reviewed by driftx for CASSANDRA-6262
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d3872408
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d3872408
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d3872408
Branch: refs/heads/cassandra-2.0
Commit: d3872408d22ae208a5cb9cdf4c1d76370510459d
Parents: 5f63578
Author: Sylvain Lebresne
Authored: Sun Jan 19 19:24:06 2014 -0800
Committer: Sylvain Lebresne
Committed: Sun Jan 19 19:24:06 2014 -0800
--
CHANGES.txt| 1 +
.../apache/cassandra/db/marshal/CompositeType.java | 17 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d3872408/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 25c105c..8626b64 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* Add ability to throttle batchlog replay (CASSANDRA-6550)
* Fix executing LOCAL_QUORUM with SimpleStrategy (CASSANDRA-6545)
* Avoid StackOverflow when using large IN queries (CASSANDRA-6567)
+ * Improve error message when schema doesn't match loaded sstable
(CASSANDRA-6262)
1.2.13
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d3872408/src/java/org/apache/cassandra/db/marshal/CompositeType.java
--
diff --git a/src/java/org/apache/cassandra/db/marshal/CompositeType.java
b/src/java/org/apache/cassandra/db/marshal/CompositeType.java
index 8cb1e34..138a065 100644
--- a/src/java/org/apache/cassandra/db/marshal/CompositeType.java
+++ b/src/java/org/apache/cassandra/db/marshal/CompositeType.java
@@ -86,12 +86,25 @@ public class CompositeType extends AbstractCompositeType
protected AbstractType getComparator(int i, ByteBuffer bb)
{
-return types.get(i);
+try
+{
+return types.get(i);
+}
+catch (IndexOutOfBoundsException e)
+{
+// We shouldn't get there in general because 1) we shouldn't
construct broken composites
+// from CQL and 2) broken composites coming from thrift should be
rejected by validate.
+// There is a few cases however where, if the schema has changed
since we created/validated
+// the composite, this will be thrown (see #6262). Those cases are
a user error but
+// throwing a more meaningful error message to make understanding
such error easier. .
+throw new RuntimeException("Cannot get comparator " + i + " in " +
this + ". "
+ + "This might due to a mismatch between
the schema and the data read", e);
+}
}
protected AbstractType getComparator(int i, ByteBuffer bb1, ByteBuffer
bb2)
{
-return types.get(i);
+return getComparator(i, bb1);
}
protected AbstractType getAndAppendComparator(int i, ByteBuffer bb,
StringBuilder sb)
[3/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e9a57fba Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e9a57fba Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e9a57fba Branch: refs/heads/cassandra-2.0 Commit: e9a57fbaa4ae206c818657a5cc8e06d8fc2b6f57 Parents: 66a8a55 3575fdc Author: Sylvain Lebresne Authored: Sun Jan 19 19:35:50 2014 -0800 Committer: Sylvain Lebresne Committed: Sun Jan 19 19:35:50 2014 -0800 -- CHANGES.txt| 1 + .../apache/cassandra/db/marshal/CompositeType.java | 17 +++-- 2 files changed, 16 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9a57fba/CHANGES.txt -- diff --cc CHANGES.txt index d165c8b,639e17c..b08f04b --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -17,29 -13,10 +17,30 @@@ Merged from 1.2 * Nodetool upgradesstables includes secondary indexes (CASSANDRA-6589) * Paginate batchlog replay (CASSANDRA-6569) * skip blocking on streaming during drain (CASSANDRA-6603) + * Improve error message when schema doesn't match loaded sstable (CASSANDRA-6262) -1.2.13 +2.0.4 + * Allow removing snapshots of no-longer-existing CFs (CASSANDRA-6418) + * add StorageService.stopDaemon() (CASSANDRA-4268) + * add IRE for invalid CF supplied to get_count (CASSANDRA-5701) + * add client encryption support to sstableloader (CASSANDRA-6378) + * Fix accept() loop for SSL sockets post-shutdown (CASSANDRA-6468) + * Fix size-tiered compaction in LCS L0 (CASSANDRA-6496) + * Fix assertion failure in filterColdSSTables (CASSANDRA-6483) + * Fix row tombstones in larger-than-memory compactions (CASSANDRA-6008) + * Fix cleanup ClassCastException (CASSANDRA-6462) + * Reduce gossip memory use by interning VersionedValue strings (CASSANDRA-6410) + * Allow specifying datacenters to participate in a repair (CASSANDRA-6218) + * Fix divide-by-zero in PCI (CASSANDRA-6403) + * Fix setting last compacted key in the wrong level for LCS (CASSANDRA-6284) + * Add millisecond precision formats to the timestamp parser (CASSANDRA-6395) + * Expose a total memtable size metric for a CF (CASSANDRA-6391) + * cqlsh: handle symlinks properly (CASSANDRA-6425) + * Fix potential infinite loop when paging query with IN (CASSANDRA-6464) + * Fix assertion error in AbstractQueryPager.discardFirst (CASSANDRA-6447) + * Fix streaming older SSTable yields unnecessary tombstones (CASSANDRA-6527) +Merged from 1.2: * Improved error message on bad properties in DDL queries (CASSANDRA-6453) * Randomize batchlog candidates selection (CASSANDRA-6481) * Fix thundering herd on endpoint cache invalidation (CASSANDRA-6345, 6485) http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9a57fba/src/java/org/apache/cassandra/db/marshal/CompositeType.java --
[2/3] git commit: Merge branch 'cassandra-1.2' of http://git-wip-us.apache.org/repos/asf/cassandra into cassandra-1.2
Merge branch 'cassandra-1.2' of http://git-wip-us.apache.org/repos/asf/cassandra into cassandra-1.2 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3575fdcc Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3575fdcc Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3575fdcc Branch: refs/heads/cassandra-2.0 Commit: 3575fdccb7b9dee720c06d133aa5895bf0bb0787 Parents: d387240 9be437b Author: Sylvain Lebresne Authored: Sun Jan 19 19:28:24 2014 -0800 Committer: Sylvain Lebresne Committed: Sun Jan 19 19:28:24 2014 -0800 -- CHANGES.txt | 3 + conf/cassandra-env.sh | 15 ++-- .../apache/cassandra/db/BatchlogManager.java| 78 +++ .../apache/cassandra/net/MessagingService.java | 15 +--- .../cassandra/service/StorageService.java | 21 - .../cassandra/thrift/CustomTHsHaServer.java | 7 +- .../cassandra/db/BatchlogManagerTest.java | 82 7 files changed, 178 insertions(+), 43 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3575fdcc/CHANGES.txt -- diff --cc CHANGES.txt index 8626b64,0b49665..639e17c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -10,7 -10,9 +10,10 @@@ * Add ability to throttle batchlog replay (CASSANDRA-6550) * Fix executing LOCAL_QUORUM with SimpleStrategy (CASSANDRA-6545) * Avoid StackOverflow when using large IN queries (CASSANDRA-6567) + * Nodetool upgradesstables includes secondary indexes (CASSANDRA-6589) + * Paginate batchlog replay (CASSANDRA-6569) + * skip blocking on streaming during drain (CASSANDRA-6603) + * Improve error message when schema doesn't match loaded sstable (CASSANDRA-6262) 1.2.13
[1/2] git commit: Improve error message when loaded sstable doesn't match schema
Updated Branches:
refs/heads/cassandra-1.2 9be437bd7 -> 3575fdccb
Improve error message when loaded sstable doesn't match schema
patch by slebresne; reviewed by driftx for CASSANDRA-6262
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d3872408
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d3872408
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d3872408
Branch: refs/heads/cassandra-1.2
Commit: d3872408d22ae208a5cb9cdf4c1d76370510459d
Parents: 5f63578
Author: Sylvain Lebresne
Authored: Sun Jan 19 19:24:06 2014 -0800
Committer: Sylvain Lebresne
Committed: Sun Jan 19 19:24:06 2014 -0800
--
CHANGES.txt| 1 +
.../apache/cassandra/db/marshal/CompositeType.java | 17 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d3872408/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 25c105c..8626b64 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,7 @@
* Add ability to throttle batchlog replay (CASSANDRA-6550)
* Fix executing LOCAL_QUORUM with SimpleStrategy (CASSANDRA-6545)
* Avoid StackOverflow when using large IN queries (CASSANDRA-6567)
+ * Improve error message when schema doesn't match loaded sstable
(CASSANDRA-6262)
1.2.13
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d3872408/src/java/org/apache/cassandra/db/marshal/CompositeType.java
--
diff --git a/src/java/org/apache/cassandra/db/marshal/CompositeType.java
b/src/java/org/apache/cassandra/db/marshal/CompositeType.java
index 8cb1e34..138a065 100644
--- a/src/java/org/apache/cassandra/db/marshal/CompositeType.java
+++ b/src/java/org/apache/cassandra/db/marshal/CompositeType.java
@@ -86,12 +86,25 @@ public class CompositeType extends AbstractCompositeType
protected AbstractType getComparator(int i, ByteBuffer bb)
{
-return types.get(i);
+try
+{
+return types.get(i);
+}
+catch (IndexOutOfBoundsException e)
+{
+// We shouldn't get there in general because 1) we shouldn't
construct broken composites
+// from CQL and 2) broken composites coming from thrift should be
rejected by validate.
+// There is a few cases however where, if the schema has changed
since we created/validated
+// the composite, this will be thrown (see #6262). Those cases are
a user error but
+// throwing a more meaningful error message to make understanding
such error easier. .
+throw new RuntimeException("Cannot get comparator " + i + " in " +
this + ". "
+ + "This might due to a mismatch between
the schema and the data read", e);
+}
}
protected AbstractType getComparator(int i, ByteBuffer bb1, ByteBuffer
bb2)
{
-return types.get(i);
+return getComparator(i, bb1);
}
protected AbstractType getAndAppendComparator(int i, ByteBuffer bb,
StringBuilder sb)
[2/2] git commit: Merge branch 'cassandra-1.2' of http://git-wip-us.apache.org/repos/asf/cassandra into cassandra-1.2
Merge branch 'cassandra-1.2' of http://git-wip-us.apache.org/repos/asf/cassandra into cassandra-1.2 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3575fdcc Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3575fdcc Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3575fdcc Branch: refs/heads/cassandra-1.2 Commit: 3575fdccb7b9dee720c06d133aa5895bf0bb0787 Parents: d387240 9be437b Author: Sylvain Lebresne Authored: Sun Jan 19 19:28:24 2014 -0800 Committer: Sylvain Lebresne Committed: Sun Jan 19 19:28:24 2014 -0800 -- CHANGES.txt | 3 + conf/cassandra-env.sh | 15 ++-- .../apache/cassandra/db/BatchlogManager.java| 78 +++ .../apache/cassandra/net/MessagingService.java | 15 +--- .../cassandra/service/StorageService.java | 21 - .../cassandra/thrift/CustomTHsHaServer.java | 7 +- .../cassandra/db/BatchlogManagerTest.java | 82 7 files changed, 178 insertions(+), 43 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3575fdcc/CHANGES.txt -- diff --cc CHANGES.txt index 8626b64,0b49665..639e17c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -10,7 -10,9 +10,10 @@@ * Add ability to throttle batchlog replay (CASSANDRA-6550) * Fix executing LOCAL_QUORUM with SimpleStrategy (CASSANDRA-6545) * Avoid StackOverflow when using large IN queries (CASSANDRA-6567) + * Nodetool upgradesstables includes secondary indexes (CASSANDRA-6589) + * Paginate batchlog replay (CASSANDRA-6569) + * skip blocking on streaming during drain (CASSANDRA-6603) + * Improve error message when schema doesn't match loaded sstable (CASSANDRA-6262) 1.2.13
[jira] [Commented] (CASSANDRA-6262) Nodetool compact throws an error after importing data with sstableloader
[
https://issues.apache.org/jira/browse/CASSANDRA-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876096#comment-13876096
]
Brandon Williams commented on CASSANDRA-6262:
-
+1
> Nodetool compact throws an error after importing data with sstableloader
>
>
> Key: CASSANDRA-6262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6262
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: J.B. Langston
> Fix For: 1.2.14
>
> Attachments: 6262.patch
>
>
> Exception when running nodetool compact:
> {code}
> Error occurred during compaction
> java.util.concurrent.ExecutionException: java.lang.IndexOutOfBoundsException:
> index (2) must be less than size (2)
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
> at java.util.concurrent.FutureTask.get(FutureTask.java:111)
> at
> org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:331)
> at
> org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1691)
> at
> org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:2198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.IndexOutOfBoundsException: index (2) must be less than
> size (2)
> at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:305)
> at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:284)
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:81)
> at
> org.apache.cassandra.db.marshal.CompositeType.getComparator(CompositeType.java:94)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:76)
> at
> org.apache.cassandra.db.marshal.A
[jira] [Commented] (CASSANDRA-6601) WRITETIME of a null value does not return a time
[
https://issues.apache.org/jira/browse/CASSANDRA-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876080#comment-13876080
]
Sylvain Lebresne commented on CASSANDRA-6601:
-
bq. When a cell's value is null the CQL WRITETIME function returns null. I was
expecting it to return a timestamp.
Not entirely sure why you would. A null in CQL means the absence of said column
basically, so there is no timestamp to return and I don't see what else than
null we could return. What you are seeing with the CLI is the row marker, but
the timestamp of that is potentially unrelated to the column you're asking the
timestamp with so ...
> WRITETIME of a null value does not return a time
>
>
> Key: CASSANDRA-6601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6601
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.2
>Reporter: Theo Hultberg
>
> When a cell's value is {{null}} the CQL {{WRITETIME}} function returns null.
> I was expecting it to return a timestamp. Looking at the data in
> {{cassandra-cli}} I can see that the cell has a timestamp.
> Here's a session showing the issue:
> {code}
> cqlsh> CREATE KEYSPACE writetime_test WITH replication = {'class':
> 'SimpleStrategy','replication_factor': '1'};
> cqlsh> USE writetime_test;
> cqlsh:writetime_test> CREATE TABLE writetime_test_table (pk INT, ck INT,
> value INT, PRIMARY KEY (pk, ck));
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (1, 2, null);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 1 AND ck = 2;
> writetime(value)
> --
> null
> (1 rows)
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (2, 3, 4);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 2 AND ck = 3;
> writetime(value)
> --
> 1389967663822000
> (1 rows)
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 3 AND ck = 4;
> (0 rows)
> {code}
> I first insert data where the cell value is {{null}}. When I query its
> writetime I get a row back, but the timestamp is {{null}}.
> I then insert a row with a value, and get a timestamp in the query results,
> as expected.
> Finally I query for the writetime of a cell that does not exist, and get no
> rows back, just to show that there's a difference between calling
> {{WRITETIME}} on {{null}} and on something that doesn't exist.
> Even though the value is {{null}} the cell exists and it has a timestamp. I
> can clearly see the timestamp using {{cassandra-cli}}:
> {code}
> [default@unknown] use writetime_test;
> Authenticated to keyspace: writetime_test
> [default@writetime_test] list writetime_test_table;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 1
> => (name=2:, value=, timestamp=1389967959822000)
> ---
> RowKey: 2
> => (name=3:, value=, timestamp=1389967964749000)
> => (name=3:value, value=0004, timestamp=1389967964749000)
> {code}
> The reason I want to get the {{WRITETIME}} of a {{null}} value is that I have
> a table where I don't care about the value, I use the column keys as sorted
> set. I still want to know when some of them were written though, but I can't
> ask for the {{WRITETIME}} of something that is part of the primary key, so I
> must use the (otherwise unused) value.
> A workaround is to write some dummy value in the cell, and that's probably
> what I need to do, but this felt like it was a bug, it was at least not what
> I expected.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CASSANDRA-6601) WRITETIME of a null value does not return a time
[
https://issues.apache.org/jira/browse/CASSANDRA-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-6601.
-
Resolution: Not A Problem
> WRITETIME of a null value does not return a time
>
>
> Key: CASSANDRA-6601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6601
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.0.2
>Reporter: Theo Hultberg
>
> When a cell's value is {{null}} the CQL {{WRITETIME}} function returns null.
> I was expecting it to return a timestamp. Looking at the data in
> {{cassandra-cli}} I can see that the cell has a timestamp.
> Here's a session showing the issue:
> {code}
> cqlsh> CREATE KEYSPACE writetime_test WITH replication = {'class':
> 'SimpleStrategy','replication_factor': '1'};
> cqlsh> USE writetime_test;
> cqlsh:writetime_test> CREATE TABLE writetime_test_table (pk INT, ck INT,
> value INT, PRIMARY KEY (pk, ck));
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (1, 2, null);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 1 AND ck = 2;
> writetime(value)
> --
> null
> (1 rows)
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES
> (2, 3, 4);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 2 AND ck = 3;
> writetime(value)
> --
> 1389967663822000
> (1 rows)
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE
> pk = 3 AND ck = 4;
> (0 rows)
> {code}
> I first insert data where the cell value is {{null}}. When I query its
> writetime I get a row back, but the timestamp is {{null}}.
> I then insert a row with a value, and get a timestamp in the query results,
> as expected.
> Finally I query for the writetime of a cell that does not exist, and get no
> rows back, just to show that there's a difference between calling
> {{WRITETIME}} on {{null}} and on something that doesn't exist.
> Even though the value is {{null}} the cell exists and it has a timestamp. I
> can clearly see the timestamp using {{cassandra-cli}}:
> {code}
> [default@unknown] use writetime_test;
> Authenticated to keyspace: writetime_test
> [default@writetime_test] list writetime_test_table;
> Using default limit of 100
> Using default cell limit of 100
> ---
> RowKey: 1
> => (name=2:, value=, timestamp=1389967959822000)
> ---
> RowKey: 2
> => (name=3:, value=, timestamp=1389967964749000)
> => (name=3:value, value=0004, timestamp=1389967964749000)
> {code}
> The reason I want to get the {{WRITETIME}} of a {{null}} value is that I have
> a table where I don't care about the value, I use the column keys as sorted
> set. I still want to know when some of them were written though, but I can't
> ask for the {{WRITETIME}} of something that is part of the primary key, so I
> must use the (otherwise unused) value.
> A workaround is to write some dummy value in the cell, and that's probably
> what I need to do, but this felt like it was a bug, it was at least not what
> I expected.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6262) Nodetool compact throws an error after importing data with sstableloader
[
https://issues.apache.org/jira/browse/CASSANDRA-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-6262:
Attachment: 6262.patch
Not against improving the error message. Attaching a tentative patch for this.
I'll note though that CompositeType seems like the only logical place to catch
this and rethrow with more info, but that also mean we can't be absolutely sure
of what the problem is when we're there, so I've attempted to throw an helpful
error message without being too specific that it would be confusing in some
other cases (than the one of this issue). It's also possible that an
incompatible schema would throw another kind of exception, so this may not be
enough, but well, that's progress so we can start there I guess.
> Nodetool compact throws an error after importing data with sstableloader
>
>
> Key: CASSANDRA-6262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6262
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: J.B. Langston
> Fix For: 1.2.14
>
> Attachments: 6262.patch
>
>
> Exception when running nodetool compact:
> {code}
> Error occurred during compaction
> java.util.concurrent.ExecutionException: java.lang.IndexOutOfBoundsException:
> index (2) must be less than size (2)
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
> at java.util.concurrent.FutureTask.get(FutureTask.java:111)
> at
> org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:331)
> at
> org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1691)
> at
> org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:2198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.IndexOutOfBoundsExc
[jira] [Commented] (CASSANDRA-6588) Add a 'NO EMPTY RESULTS' filter to SELECT
[
https://issues.apache.org/jira/browse/CASSANDRA-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876059#comment-13876059
]
Sylvain Lebresne commented on CASSANDRA-6588:
-
Let me try to clarity my points/position.
The issue this ticket wants to solve (the "we read all columns of a CQL row")
is a minor one. I've explained why on CASSANDRA-6586 but the short version is
that it noticeably affects only a small amount of use cases and even in those
affected cases there is the workaround of making-two-tables. We could very well
leave things as they are btw, I'm not throwing away that option, but it feels
to me that the suggestion of this ticket requires little additional complexity
(in terms of implementation and of compexity added to the CQL language) and is
a bit better that the make-two-tables workaround.
Regarding per-row TTL, if we think there is major problems with the current TTL
design that per-row TTL solves and that justify such revamping, then let's
maybe add a specific ticket with a rational, a vague description of what the
semantic would be, what's the backward compatibility story looks like, and
let's move from there. But my initial anylisis of that is that adding per-row
TTL today in C* is likely far from simple. I'm not sure how the exact semantic
could be kept the same as today in particular, even if we ignore the case of
actually wanting per-column TTL (not that I think we should ignore it :)). So
I suspect per-row TTL may break a fair amount of current TTL users. And what
about thrift? The thrift API pretty clearly assumes that TTL are per-cell, and
we pinky swore we wouldn't break it. Do we really want to support 2 separate
TTL implementations internally? Lastly, it doesn't seems like adding per-row
TTL will be a trivial amount of code/work to write. Overall, this is a non
negligible amount of drawbacks for switching to per-row TTL imo (granted, those
are not intrinsic drawbacks of per-row TTL, but there are still things we'll
have to deal with).
And the pros of switching to per-row TTL feels rather small? Yes, it might
allow to fix this issue, but as said above, this issue is minor. And yes, it
might have a slightly smaller storage footprint than the current mechanism.
But I've heard no-one complaining that the TTL footprint is a big problem,
especially now that we have sstable compression, so I really don't think it's a
big deal. Even combined, those two still sound like pretty minor advantages
imo. I could probably be convinced to leave per-column TTL out for the sake of
those advantages if we were to rewrite C* today, but doing it now is not that
simple.
So I continue to think that doing this issue, and leaving TTL be, feels to me
like a better practical trade-off: breaking changes shouldn't be considered
lightly, even if it doesn't break many people, and we have more important
things to do imo. But again, if you guys think per-row TTL solves important
problems, let's open a separate ticket and work out the pros and cons in more
details. I'm happy to hold off on this ticket for now if we do that. Just
saying it sound to me like a relatively clear waste of time/resources. I'll
admit I might be wrong :)
> Add a 'NO EMPTY RESULTS' filter to SELECT
> -
>
> Key: CASSANDRA-6588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6588
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Priority: Minor
> Fix For: 2.1
>
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns, which, given that no PK columns
> can be null, means that it's enough to have the PK set for a row to exist).
> This does means that the result to
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v1 int, v2 int);
> INSERT INTO test(k, v1) VALUES (0, 4);
> SELECT v2 FROM test;
> {noformat}
> must be (and is)
> {noformat}
> v2
> --
> null
> {noformat}
> That fact does mean however that when we only select a few columns of a row,
> we still need to find out rows that exist but have no values for the selected
> columns. Long story short, given how the storage engine works, this means we
> need to query full (CQL) rows even when only some of the columns are selected
> because that's the only way to distinguish between "the row exists but have
> no value for the selected columns" and "the row doesn't exist". I'll note in
> particular that, due to CASSANDRA-5762, we can't unfortunately rely on the
> row marker to optimize that out.
> Now, when you selects only a subsets of the columns of a row, there is many
> cases where you don't care about rows that exists but have no value for the
> columns you requested and are happy to filter those out. So, for
[jira] [Updated] (CASSANDRA-6596) Split out outgoing stream throughput within a DC and inter-DC
[
https://issues.apache.org/jira/browse/CASSANDRA-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay updated CASSANDRA-6596:
-
Attachment: 0001-CASSANDRA-6596.patch
Attached patch introduces inter_dc_stream_throughput_outbound_megabits_per_sec
which is a subset of stream_throughput_outbound_megabits_per_sec.
Currently the node throttles all the traffic which it streams (this doesn't
change after this patch). In addition, this patch adds additional throttle
across the DC's.
One more thing: There might be a bug (in trunk) where the throttle is applied
on bytes instead of bits... Since its not related to this ticket, i have not
changed it.
{code}
int toTransfer = (int) Math.min(transferBuffer.length, length -
bytesTransferred);
int minReadable = (int) Math.min(transferBuffer.length, reader.length()
- reader.getFilePointer());
reader.readFully(transferBuffer, 0, minReadable);
if (validator != null)
validator.validate(transferBuffer, 0, minReadable);
limiter.acquire(toTransfer);
{code}
> Split out outgoing stream throughput within a DC and inter-DC
> -
>
> Key: CASSANDRA-6596
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6596
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jeremy Hanna
>Assignee: Vijay
>Priority: Minor
> Fix For: 2.1
>
> Attachments: 0001-CASSANDRA-6596.patch
>
>
> Currently the outgoing stream throughput setting doesn't differentiate
> between when it goes to another node in the same DC and when it goes to
> another DC across a potentially bandwidth limited link. It would be nice to
> have that split out so that it could be tuned for each type of link.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6604) AssertionError: Verb COUNTER_MUTATION should not legally be dropped
[
https://issues.apache.org/jira/browse/CASSANDRA-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876038#comment-13876038
]
Jonathan Ellis commented on CASSANDRA-6604:
---
The real problem is that your server is overloaded enough to drop writes on the
floor.
> AssertionError: Verb COUNTER_MUTATION should not legally be dropped
> ---
>
> Key: CASSANDRA-6604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6604
> Project: Cassandra
> Issue Type: Bug
>Reporter: Bartłomiej Romański
> Fix For: 1.2.14, 2.0.5
>
>
> We're seeing the following errors in our logs from time to time (about once
> an hour):
> {code}
> ERROR [MutationStage:10] 2014-01-19 10:36:26,659 CassandraDaemon.java (line
> 187) Exception in thread Thread[MutationStage:10,5,main]
> java.lang.AssertionError: Verb COUNTER_MUTATION should not legally be dropped
> at
> org.apache.cassandra.net.MessagingService.incrementDroppedMessages(MessagingService.java:779)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1925)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {code}
> They always appear in groups. About 50-100 errors in a row.
> We've got a 12-nodes cluster recently upgraded from 1.2.10 to 2.0.4. It's
> under pretty heavy load.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CASSANDRA-6604) AssertionError: Verb COUNTER_MUTATION should not legally be dropped
[
https://issues.apache.org/jira/browse/CASSANDRA-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko resolved CASSANDRA-6604.
--
Resolution: Fixed
Fix Version/s: 2.0.5
1.2.14
It's cosmetic - COUNTER_MUTATION wasn't added to MS.DROPPABLE_VERBS.
Ninja-fixed in 9be437bd7b268c88901745b361aba271f2dbe5ec.
> AssertionError: Verb COUNTER_MUTATION should not legally be dropped
> ---
>
> Key: CASSANDRA-6604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6604
> Project: Cassandra
> Issue Type: Bug
>Reporter: Bartłomiej Romański
> Fix For: 1.2.14, 2.0.5
>
>
> We're seeing the following errors in our logs from time to time (about once
> an hour):
> {code}
> ERROR [MutationStage:10] 2014-01-19 10:36:26,659 CassandraDaemon.java (line
> 187) Exception in thread Thread[MutationStage:10,5,main]
> java.lang.AssertionError: Verb COUNTER_MUTATION should not legally be dropped
> at
> org.apache.cassandra.net.MessagingService.incrementDroppedMessages(MessagingService.java:779)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1925)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {code}
> They always appear in groups. About 50-100 errors in a row.
> We've got a 12-nodes cluster recently upgraded from 1.2.10 to 2.0.4. It's
> under pretty heavy load.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[3/3] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6aaa0231 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6aaa0231 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6aaa0231 Branch: refs/heads/trunk Commit: 6aaa023171162ee1b42c6de21f2ef60a49948fc5 Parents: 68baaed 66a8a55 Author: Aleksey Yeschenko Authored: Sun Jan 19 11:16:18 2014 -0800 Committer: Aleksey Yeschenko Committed: Sun Jan 19 11:16:18 2014 -0800 -- src/java/org/apache/cassandra/net/MessagingService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6aaa0231/src/java/org/apache/cassandra/net/MessagingService.java --
[1/3] git commit: Ninja-add COUNTER_MUTATION to DROPPABLE_VERBS
Updated Branches: refs/heads/trunk 68baaedd6 -> 6aaa02317 Ninja-add COUNTER_MUTATION to DROPPABLE_VERBS Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9be437bd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9be437bd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9be437bd Branch: refs/heads/trunk Commit: 9be437bd7b268c88901745b361aba271f2dbe5ec Parents: 3de8454 Author: Aleksey Yeschenko Authored: Sun Jan 19 11:13:48 2014 -0800 Committer: Aleksey Yeschenko Committed: Sun Jan 19 11:13:48 2014 -0800 -- src/java/org/apache/cassandra/net/MessagingService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9be437bd/src/java/org/apache/cassandra/net/MessagingService.java -- diff --git a/src/java/org/apache/cassandra/net/MessagingService.java b/src/java/org/apache/cassandra/net/MessagingService.java index 3ec3267..bfc3957 100644 --- a/src/java/org/apache/cassandra/net/MessagingService.java +++ b/src/java/org/apache/cassandra/net/MessagingService.java @@ -275,6 +275,7 @@ public final class MessagingService implements MessagingServiceMBean public static final EnumSet DROPPABLE_VERBS = EnumSet.of(Verb.BINARY, Verb._TRACE, Verb.MUTATION, + Verb.COUNTER_MUTATION, Verb.READ_REPAIR, Verb.READ, Verb.RANGE_SLICE,
[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/66a8a557 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/66a8a557 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/66a8a557 Branch: refs/heads/trunk Commit: 66a8a55754a8e0dfb56bcbcf42c8cf420812dda7 Parents: 24af352 9be437b Author: Aleksey Yeschenko Authored: Sun Jan 19 11:14:07 2014 -0800 Committer: Aleksey Yeschenko Committed: Sun Jan 19 11:14:07 2014 -0800 -- src/java/org/apache/cassandra/net/MessagingService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/66a8a557/src/java/org/apache/cassandra/net/MessagingService.java --
[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/66a8a557 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/66a8a557 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/66a8a557 Branch: refs/heads/cassandra-2.0 Commit: 66a8a55754a8e0dfb56bcbcf42c8cf420812dda7 Parents: 24af352 9be437b Author: Aleksey Yeschenko Authored: Sun Jan 19 11:14:07 2014 -0800 Committer: Aleksey Yeschenko Committed: Sun Jan 19 11:14:07 2014 -0800 -- src/java/org/apache/cassandra/net/MessagingService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/66a8a557/src/java/org/apache/cassandra/net/MessagingService.java --
[1/2] git commit: Ninja-add COUNTER_MUTATION to DROPPABLE_VERBS
Updated Branches: refs/heads/cassandra-2.0 24af3525f -> 66a8a5575 Ninja-add COUNTER_MUTATION to DROPPABLE_VERBS Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9be437bd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9be437bd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9be437bd Branch: refs/heads/cassandra-2.0 Commit: 9be437bd7b268c88901745b361aba271f2dbe5ec Parents: 3de8454 Author: Aleksey Yeschenko Authored: Sun Jan 19 11:13:48 2014 -0800 Committer: Aleksey Yeschenko Committed: Sun Jan 19 11:13:48 2014 -0800 -- src/java/org/apache/cassandra/net/MessagingService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9be437bd/src/java/org/apache/cassandra/net/MessagingService.java -- diff --git a/src/java/org/apache/cassandra/net/MessagingService.java b/src/java/org/apache/cassandra/net/MessagingService.java index 3ec3267..bfc3957 100644 --- a/src/java/org/apache/cassandra/net/MessagingService.java +++ b/src/java/org/apache/cassandra/net/MessagingService.java @@ -275,6 +275,7 @@ public final class MessagingService implements MessagingServiceMBean public static final EnumSet DROPPABLE_VERBS = EnumSet.of(Verb.BINARY, Verb._TRACE, Verb.MUTATION, + Verb.COUNTER_MUTATION, Verb.READ_REPAIR, Verb.READ, Verb.RANGE_SLICE,
git commit: Ninja-add COUNTER_MUTATION to DROPPABLE_VERBS
Updated Branches: refs/heads/cassandra-1.2 3de845426 -> 9be437bd7 Ninja-add COUNTER_MUTATION to DROPPABLE_VERBS Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9be437bd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9be437bd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9be437bd Branch: refs/heads/cassandra-1.2 Commit: 9be437bd7b268c88901745b361aba271f2dbe5ec Parents: 3de8454 Author: Aleksey Yeschenko Authored: Sun Jan 19 11:13:48 2014 -0800 Committer: Aleksey Yeschenko Committed: Sun Jan 19 11:13:48 2014 -0800 -- src/java/org/apache/cassandra/net/MessagingService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9be437bd/src/java/org/apache/cassandra/net/MessagingService.java -- diff --git a/src/java/org/apache/cassandra/net/MessagingService.java b/src/java/org/apache/cassandra/net/MessagingService.java index 3ec3267..bfc3957 100644 --- a/src/java/org/apache/cassandra/net/MessagingService.java +++ b/src/java/org/apache/cassandra/net/MessagingService.java @@ -275,6 +275,7 @@ public final class MessagingService implements MessagingServiceMBean public static final EnumSet DROPPABLE_VERBS = EnumSet.of(Verb.BINARY, Verb._TRACE, Verb.MUTATION, + Verb.COUNTER_MUTATION, Verb.READ_REPAIR, Verb.READ, Verb.RANGE_SLICE,
[jira] [Created] (CASSANDRA-6604) AssertionError: Verb COUNTER_MUTATION should not legally be dropped
Bartłomiej Romański created CASSANDRA-6604:
--
Summary: AssertionError: Verb COUNTER_MUTATION should not legally
be dropped
Key: CASSANDRA-6604
URL: https://issues.apache.org/jira/browse/CASSANDRA-6604
Project: Cassandra
Issue Type: Bug
Reporter: Bartłomiej Romański
We're seeing the following errors in our logs from time to time (about once an
hour):
{code}
ERROR [MutationStage:10] 2014-01-19 10:36:26,659 CassandraDaemon.java (line
187) Exception in thread Thread[MutationStage:10,5,main]
java.lang.AssertionError: Verb COUNTER_MUTATION should not legally be dropped
at
org.apache.cassandra.net.MessagingService.incrementDroppedMessages(MessagingService.java:779)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1925)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
{code}
They always appear in groups. About 50-100 errors in a row.
We've got a 12-nodes cluster recently upgraded from 1.2.10 to 2.0.4. It's under
pretty heavy load.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
