[jira] [Updated] (CASSANDRA-5626) Support empty IN queries
[ https://issues.apache.org/jira/browse/CASSANDRA-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5626: - Reviewer: slebresne Affects Version/s: 1.2.0 Labels: cql3 (was: ) > Support empty IN queries > > > Key: CASSANDRA-5626 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5626 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.2.0 >Reporter: Alexander Solovyev >Assignee: Aleksey Yeschenko >Priority: Minor > Labels: cql3 > Attachments: 5626.txt > > > It would be nice to have support of empty IN queries. > Example: "SELECT a FROM t WHERE aKey IN ()". > One of the reasons is to have such support in DataStax Java Driver (see > discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106). -- 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-5626) Support empty IN queries
[ https://issues.apache.org/jira/browse/CASSANDRA-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5626: - Attachment: 5626.txt > Support empty IN queries > > > Key: CASSANDRA-5626 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5626 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Alexander Solovyev >Assignee: Aleksey Yeschenko >Priority: Minor > Attachments: 5626.txt > > > It would be nice to have support of empty IN queries. > Example: "SELECT a FROM t WHERE aKey IN ()". > One of the reasons is to have such support in DataStax Java Driver (see > discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106). -- 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-5798) Cqlsh should support multiline comments
[
https://issues.apache.org/jira/browse/CASSANDRA-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717928#comment-13717928
]
Jonathan Ellis commented on CASSANDRA-5798:
---
Since I bothered looking it up:
http://stackoverflow.com/questions/728172/are-there-multiline-comment-delimiters-in-sql-that-are-vendor-agnostic
> Cqlsh should support multiline comments
> ---
>
> Key: CASSANDRA-5798
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5798
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michaël Figuière
>Priority: Trivial
>
> Right now cqlsh doesn't support multiline comments that are available in the
> CQL grammar:
> {quote}
> {code}
> MULTILINE_COMMENT
> : '/*' .* '*/' { $channel = HIDDEN; }
> ;
> {code}
> {quote}
> These should be supported both in file and interactive mode (where copy
> pasting large chunks of CQL scripts containing such comments might be
> convenient).
--
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-5515) Track sstable coldness
[ https://issues.apache.org/jira/browse/CASSANDRA-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717923#comment-13717923 ] Jonathan Ellis commented on CASSANDRA-5515: --- Maybe get fancy and do a reservoir-sampling histogram? Metrics makes that easy. > Track sstable coldness > -- > > Key: CASSANDRA-5515 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5515 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Tyler Hobbs > Fix For: 2.0.1 > > Attachments: 0001-Track-row-read-counts-in-SSTR.patch > > > Keeping a count of reads per-sstable would allow STCS to automatically ignore > cold data rather than recompacting it constantly with hot data, dramatically > reducing compaction load for typical time series applications and others with > time-correlated access patterns. We would not need a separate age-tiered > compaction strategy. > (This will really be useful in conjunction with CASSANDRA-5514.) -- 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-5798) Cqlsh should support multiline comments
Michaël Figuière created CASSANDRA-5798:
---
Summary: Cqlsh should support multiline comments
Key: CASSANDRA-5798
URL: https://issues.apache.org/jira/browse/CASSANDRA-5798
Project: Cassandra
Issue Type: Improvement
Reporter: Michaël Figuière
Priority: Trivial
Right now cqlsh doesn't support multiline comments that are available in the
CQL grammar:
{quote}
{code}
MULTILINE_COMMENT
: '/*' .* '*/' { $channel = HIDDEN; }
;
{code}
{quote}
These should be supported both in file and interactive mode (where copy pasting
large chunks of CQL scripts containing such comments might be convenient).
--
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-5797) DC-local CAS
Jonathan Ellis created CASSANDRA-5797:
-
Summary: DC-local CAS
Key: CASSANDRA-5797
URL: https://issues.apache.org/jira/browse/CASSANDRA-5797
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 2.0
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 2.0.1
For two-datacenter deployments where the second DC is strictly for disaster
failover, it would be useful to restrict CAS to a single DC to avoid cross-DC
round trips.
(This would require manually truncating {{system.paxos}} when failing over.)
--
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-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717917#comment-13717917
]
Jonathan Ellis commented on CASSANDRA-5797:
---
Not sure what CQL syntax for this is. Is it protocol level the way CL is?
> DC-local CAS
>
>
> Key: CASSANDRA-5797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5797
> Project: Cassandra
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 2.0.1
>
>
> For two-datacenter deployments where the second DC is strictly for disaster
> failover, it would be useful to restrict CAS to a single DC to avoid cross-DC
> round trips.
> (This would require manually truncating {{system.paxos}} when failing over.)
--
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-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE
[
https://issues.apache.org/jira/browse/CASSANDRA-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michaël Figuière updated CASSANDRA-5796:
Description:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
regular {{INSERT/UPDATE}} statements, that if without displaying anything is
there were no error.
Ideally it should display the ResultSet returned by these CAS statements as
defined in CASSANDRA-5619.
was:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
regular {{INSERT/UPDATE}} statements, that is without displaying anything is
there were no error.
Ideally it should display the ResultSet returned by these CAS statements as
defined in CASSANDRA-5619.
> Cqlsh should return a result in the case of a CAS INSERT/UPDATE
> ---
>
> Key: CASSANDRA-5796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 2.0 beta 1
>Reporter: Michaël Figuière
>Priority: Minor
>
> Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
> regular {{INSERT/UPDATE}} statements, that if without displaying anything is
> there were no error.
> Ideally it should display the ResultSet returned by these CAS statements as
> defined in CASSANDRA-5619.
--
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-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE
[
https://issues.apache.org/jira/browse/CASSANDRA-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michaël Figuière updated CASSANDRA-5796:
Description:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
regular {{INSERT/UPDATE}} statements, that is without displaying anything if
there were no error.
Ideally it should display the ResultSet returned by these CAS statements as
defined in CASSANDRA-5619.
was:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
regular {{INSERT/UPDATE}} statements, that if without displaying anything is
there were no error.
Ideally it should display the ResultSet returned by these CAS statements as
defined in CASSANDRA-5619.
> Cqlsh should return a result in the case of a CAS INSERT/UPDATE
> ---
>
> Key: CASSANDRA-5796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 2.0 beta 1
>Reporter: Michaël Figuière
>Priority: Minor
>
> Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
> regular {{INSERT/UPDATE}} statements, that is without displaying anything if
> there were no error.
> Ideally it should display the ResultSet returned by these CAS statements as
> defined in CASSANDRA-5619.
--
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-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE
[
https://issues.apache.org/jira/browse/CASSANDRA-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michaël Figuière updated CASSANDRA-5796:
Description:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
regular {{INSERT/UPDATE}} statements, that is without displaying anything is
there were no error.
Ideally it should display the ResultSet returned by these CAS statements as
defined in CASSANDRA-5619.
was:
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
regular INSERT/UPDATE statements, that is without displaying anything is there
were no error.
Ideally it should display the ResultSet returned by these CAS statements as
defined in CASSANDRA-5619.
> Cqlsh should return a result in the case of a CAS INSERT/UPDATE
> ---
>
> Key: CASSANDRA-5796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 2.0 beta 1
>Reporter: Michaël Figuière
>Priority: Minor
>
> Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
> regular {{INSERT/UPDATE}} statements, that is without displaying anything is
> there were no error.
> Ideally it should display the ResultSet returned by these CAS statements as
> defined in CASSANDRA-5619.
--
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-5796) Cqlsh should return a result in the case of a CAS INSERT/UPDATE
Michaël Figuière created CASSANDRA-5796:
---
Summary: Cqlsh should return a result in the case of a CAS
INSERT/UPDATE
Key: CASSANDRA-5796
URL: https://issues.apache.org/jira/browse/CASSANDRA-5796
Project: Cassandra
Issue Type: Improvement
Affects Versions: 2.0 beta 1
Reporter: Michaël Figuière
Priority: Minor
Right now cqlsh behave with {{INSERT/UPDATE...IF}} the same way it does for
regular INSERT/UPDATE statements, that is without displaying anything is there
were no error.
Ideally it should display the ResultSet returned by these CAS statements as
defined in CASSANDRA-5619.
--
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-5614) W/O specified columns ASPCSI does not get notified of deletes
[
https://issues.apache.org/jira/browse/CASSANDRA-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717914#comment-13717914
]
Jonathan Ellis commented on CASSANDRA-5614:
---
Thanks! Do you have a github branch for this?
> W/O specified columns ASPCSI does not get notified of deletes
> -
>
> Key: CASSANDRA-5614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5614
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Benjamin Coverston
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 1.2.7
>
> Attachments:
> 0001-CASSANDRA-5614-PreCompactedRow-updates-2i-correctly.patch,
> 0002-CASSANDRA-5614-LazilyCompactedRow-outputs-SSTables-a.patch,
> 0003-CASSANDRA-5614-Memtable-updates-with-RowTombstone-up.patch
>
>
> I'm working on a secondary index implementation based on the composite index
> type.
> AbstractSimplePerColumnSecondaryIndex.java#delete is not called when CQL
> delete statements do not specify columns.
> When I specify columns it is called. Pretty sure this is a bug.
> Setup:
> {code}
> cqlsh> create KEYSPACE foo WITH replication = {'class': 'SimpleStrategy' ,
> 'replication_factor': 1};
> cqlsh> use foo;
> cqlsh:foo> CREATE TABLE albums (artist text, album text, rating int, release
> int, PRIMARY KEY (artist, album));
> cqlsh:foo> CREATE INDEX ON albums (rating);
> {code}
> {code}
> cqlsh:foo> insert into albums (artist, album, rating, release) VALUES
> ('artist', 'album', 1, 2);
> {code}
> Does not get called here:
> {code}
> cqlsh:foo> DELETE FROM albums where artist='artist' and album='album';
> {code}
> {code}
> cqlsh:foo> insert into albums (artist, album, rating, release) VALUES
> ('artist', 'album', 1, 2);
> {code}
> gets called here:
> {code}
> cqlsh:foo> DELETE rating FROM albums where artist='artist' and album='album';
> {code}
--
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-5795) now() is being rejected in INSERTs when inside collections
Aleksey Yeschenko created CASSANDRA-5795:
Summary: now() is being rejected in INSERTs when inside collections
Key: CASSANDRA-5795
URL: https://issues.apache.org/jira/browse/CASSANDRA-5795
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.6
Reporter: Aleksey Yeschenko
Assignee: Sylvain Lebresne
Lists, Sets and Maps reject NonTerminal terms in prepare:
{code}
if (t instanceof Term.NonTerminal)
throw new InvalidRequestException(String.format("Invalid
list literal for %s: bind variables are not supported inside collection
literals", receiver));
{code}
and now() is instanceof NonTerminal since CASSANDRA-5616, hence
{noformat}
cqlsh:test> insert into demo (id, timeuuids) values (0, [now()]);
Bad Request: Invalid list literal for tus: bind variables are not supported
inside collection literals
{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] [Assigned] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey reassigned CASSANDRA-5794: -- Assignee: Nick Bailey > BulkOutputFormat sometimes hangs when loading small SSTables > > > Key: CASSANDRA-5794 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5794 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.6 > Environment: linux (centos 6 server, ubuntu 13.04 client) >Reporter: Jim Zamata >Assignee: Nick Bailey > > We have seen the bulk loader hang under some conditions. This only seems to > occur when the last SSTable loaded is relatively small (1144 bytes in this > case). Turning on debug logging shows the StreamInSession starting to stream > a file, "en_oef_834_thrift-MessageData-ic-1-Data.db" below, and apparently > getting a Thrift transport error. This loader was able to other files, some > of them even smaller, without any problems. > The Thrift exception only appears in the debug logs, and apparently does not > cause the stream session to fail. It just hangs the session on both the > server and the client until the client is killed. When the client process is > killed, the server then gets an unexpected EOF exception. -- 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
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Conflicts: src/java/org/apache/cassandra/cql3/statements/SelectStatement.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7b841aad Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7b841aad Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7b841aad Branch: refs/heads/trunk Commit: 7b841aade2c7136b00f17815aa293fdbcdfac1dc Parents: 931be48 25a46ea Author: Aleksey Yeschenko Authored: Wed Jul 24 00:57:03 2013 +0300 Committer: Aleksey Yeschenko Committed: Wed Jul 24 00:57:03 2013 +0300 -- --
[1/2] git commit: Fix exception text in SelectStatement
Updated Branches:
refs/heads/trunk 931be4803 -> 7b841aade
Fix exception text in SelectStatement
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/25a46eae
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/25a46eae
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/25a46eae
Branch: refs/heads/trunk
Commit: 25a46eae5d1f6b48a490a4e77eb4df7c81a436d9
Parents: 66bd605
Author: Aleksey Yeschenko
Authored: Wed Jul 24 00:49:52 2013 +0300
Committer: Aleksey Yeschenko
Committed: Wed Jul 24 00:49:52 2013 +0300
--
src/java/org/apache/cassandra/cql3/statements/SelectStatement.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/25a46eae/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 2a2b33a..8343d1e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -1157,7 +1157,7 @@ public class SelectStatement implements CQLStatement
// We don't support IN for indexed values (basically this
would require supporting a form of OR)
if (restriction.eqValues.size() > 1)
-throw new InvalidRequestException("Cannot use IN
operator on column not part of the PRIMARY KEY");
+throw new InvalidRequestException("Cannot use IN
operator on column not part of the partition key");
if (indexedNames.contains(entry.getKey().name.key))
{
git commit: Fix exception text in SelectStatement
Updated Branches:
refs/heads/cassandra-1.2 66bd60590 -> 25a46eae5
Fix exception text in SelectStatement
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/25a46eae
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/25a46eae
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/25a46eae
Branch: refs/heads/cassandra-1.2
Commit: 25a46eae5d1f6b48a490a4e77eb4df7c81a436d9
Parents: 66bd605
Author: Aleksey Yeschenko
Authored: Wed Jul 24 00:49:52 2013 +0300
Committer: Aleksey Yeschenko
Committed: Wed Jul 24 00:49:52 2013 +0300
--
src/java/org/apache/cassandra/cql3/statements/SelectStatement.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/25a46eae/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 2a2b33a..8343d1e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -1157,7 +1157,7 @@ public class SelectStatement implements CQLStatement
// We don't support IN for indexed values (basically this
would require supporting a form of OR)
if (restriction.eqValues.size() > 1)
-throw new InvalidRequestException("Cannot use IN
operator on column not part of the PRIMARY KEY");
+throw new InvalidRequestException("Cannot use IN
operator on column not part of the partition key");
if (indexedNames.contains(entry.getKey().name.key))
{
[jira] [Updated] (CASSANDRA-5789) Data not fully replicated with 2 nodes and replication factor 2
[ https://issues.apache.org/jira/browse/CASSANDRA-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-5789: Assignee: (was: Alex Zarutin) Check if hints were generated and force hint delivery if so. > Data not fully replicated with 2 nodes and replication factor 2 > --- > > Key: CASSANDRA-5789 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5789 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.2, 1.2.6 > Environment: Official Datastax Cassandra 1.2.6, running on Linux RHEL > 6.2. I've seen the same behavior with Cassandra 1.2.2. > Sun Java 1.7.0_10-b18 64-bit > Java heap settings: -Xms8192M -Xmx8192M -Xmn2048M >Reporter: James Lee > > I'm seeing a problem with a 2-node Cassandra test deployment, where it seems > that data isn't being replicated among the nodes as I would expect. > The setup and test is as follows: > - Two Cassandra nodes in the cluster (they each have themselves and the other > node as seeds in cassandra.yaml). > - Create 40 keyspaces, each with simple replication strategy and > replication factor 2. > - Populate 125,000 rows into each keyspace, using a pycassa client with a > connection pool pointed at both nodes. These are populated with writes using > consistency level of 1. > - Wait until nodetool on each node reports that there are no hinted handoffs > outstanding (see output below). > - Do random reads of the rows in the keyspaces, again using a pycassa client > with a connection pool pointed at both nodes. These are read using > consistency level 1. > I'm finding that the vast majority of reads are successful, but a small > proportion (~0.1%) are returned as Not Found. If I manually try to look up > those keys using cassandra-cli, I see that they are returned when querying > one of the nodes, but not when querying the other. So it seems like some of > the rows have simply not been replicated, even though the write for these > rows was reported to the client as successful. > If I reduce the rate at which the test tool initially writes data into the > database then I don't see any failed reads, so this seems like a load-related > issue. My understanding is that if all writes were successful and there are > no pending hinted handoffs, then the data should be fully-replicated and > reads should return it (even with read and write consistency of 1). > Here's the output from notetool on the two nodes: > comet-mvs01:/dsc-cassandra-1.2.6# ./bin/nodetool tpstats > Pool NameActive Pending Completed Blocked All > time blocked > ReadStage 0 0 2 0 > 0 > RequestResponseStage 0 0 878494 0 > 0 > MutationStage 0 02869107 0 > 0 > ReadRepairStage 0 0 0 0 > 0 > ReplicateOnWriteStage 0 0 0 0 > 0 > GossipStage 0 0 2208 0 > 0 > AntiEntropyStage 0 0 0 0 > 0 > MigrationStage0 0994 0 > 0 > MemtablePostFlusher 0 0 4399 0 > 0 > FlushWriter 0 0 2264 0 >556 > MiscStage 0 0 0 0 > 0 > commitlog_archiver0 0 0 0 > 0 > InternalResponseStage 0 0153 0 > 0 > HintedHandoff 0 0 2 0 > 0 > Message type Dropped > RANGE_SLICE 0 > READ_REPAIR 0 > BINARY 0 > READ 0 > MUTATION 87655 > _TRACE 0 > REQUEST_RESPONSE 0 > comet-mvs02:/dsc-cassandra-1.2.6# ./bin/nodetool tpstats > Pool NameActive Pending Completed Blocked All > time blocked > ReadStage 0 0868 0 > 0 > RequestResponseStage 0 03919665 0 > 0 > MutationStage 0 08177325 0 > 0 > ReadRepairStage 0 0113 0 > 0 > ReplicateOnWriteStage 0 0 0
[jira] [Commented] (CASSANDRA-5515) Track sstable coldness
[
https://issues.apache.org/jira/browse/CASSANDRA-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717492#comment-13717492
]
Tyler Hobbs commented on CASSANDRA-5515:
bq. If we're not going to take the simple approach with a map, should we keep
more data like this?
That's what I was thinking with the exception of the {{hour_ending_at}} column;
I was thinking we would periodically overwrite a single read count row per
sstable instead of tracking it in time-series fashion. Are you specifically
looking to have both "recent" read rates and total historic read rates? If so,
just using two counters would be lighter weight. I don't foresee compaction
strategies using more than the recent and total rates, but I suppose users
might find full time series data useful.
> Track sstable coldness
> --
>
> Key: CASSANDRA-5515
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Jonathan Ellis
>Assignee: Tyler Hobbs
> Fix For: 2.0.1
>
> Attachments: 0001-Track-row-read-counts-in-SSTR.patch
>
>
> Keeping a count of reads per-sstable would allow STCS to automatically ignore
> cold data rather than recompacting it constantly with hot data, dramatically
> reducing compaction load for typical time series applications and others with
> time-correlated access patterns. We would not need a separate age-tiered
> compaction strategy.
> (This will really be useful in conjunction with CASSANDRA-5514.)
--
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-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs reassigned CASSANDRA-4573:
--
Assignee: Tyler Hobbs (was: Vijay)
> HSHA doesn't handle large messages gracefully
> -
>
> Key: CASSANDRA-4573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
> Attachments: repro.py
>
>
> HSHA doesn't seem to enforce any kind of max message length, and when
> messages are too large, it doesn't fail gracefully.
> With debug logs enabled, you'll see this:
> {{DEBUG 13:13:31,805 Unexpected state 16}}
> Which seems to mean that there's a SelectionKey that's valid, but isn't ready
> for reading, writing, or accepting.
> Client-side, you'll get this thrift error (while trying to read a frame as
> part of {{recv_batch_mutate}}):
> {{TTransportException: TSocket read 0 bytes}}
--
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-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717485#comment-13717485
]
Tyler Hobbs commented on CASSANDRA-4573:
bq. Tyler, is this ticket still valid?
The changes for CASSANDRA-5582 probably make this invalid for 2.0, which I'm
fine with. I'll assign to myself, test against 2.0, close this ticket and open
a new one for the 2.0 implementation if needed.
> HSHA doesn't handle large messages gracefully
> -
>
> Key: CASSANDRA-4573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Vijay
> Attachments: repro.py
>
>
> HSHA doesn't seem to enforce any kind of max message length, and when
> messages are too large, it doesn't fail gracefully.
> With debug logs enabled, you'll see this:
> {{DEBUG 13:13:31,805 Unexpected state 16}}
> Which seems to mean that there's a SelectionKey that's valid, but isn't ready
> for reading, writing, or accepting.
> Client-side, you'll get this thrift error (while trying to read a frame as
> part of {{recv_batch_mutate}}):
> {{TTransportException: TSocket read 0 bytes}}
--
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-5614) W/O specified columns ASPCSI does not get notified of deletes
[
https://issues.apache.org/jira/browse/CASSANDRA-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716905#comment-13716905
]
Sam Tunnicliffe commented on CASSANDRA-5614:
First, we aren't doing the right thing in compaction either. Neither PCR or LCR
clean up the index in the face of range tombstones, relying on repairs at read
time to purge obsolete entries.
Looking into this, it also seems that PCR & LCR actually generate different
SSTables. Although they're functionally equivalent, those that come from PCR
don't have any columns covered by a RangeTombstone. SSTables generated by LCR
do contain these redundant extra columns.
eg: if we have two SSTables:
{code}
[{"key": "6e697276616e61","columns":
[
["bleach:","",1374246211348000],
["bleach:rating","4",1374246211348000],
["bleach:release","1",1374246211348000],
["nevermind:","",1374246211365000],
["nevermind:rating","5",1374246211365000],
["nevermind:release","2",1374246211365000]
]
}]
[{"key": "6e697276616e61","columns":
[
["nevermind","nevermind:!",1374246212053000,"t",1374246212]
]
}]
{code}
When compacted with PCR we end up with in :
{code}
[{
"key": "6e697276616e61",
"columns": [
["bleach:","",1374246658577000],
["bleach:rating","4",1374246658577000],
["bleach:release","1",1374246658577000],
["nevermind","nevermind:!",1374246659274000,"t",1374246659]
]
}]
{code}
But with LCR we get:
{code}
[{
"key": "6e697276616e61",
"columns": [
["bleach:","",1374246211348000],
["bleach:rating","4",1374246211348000],
["bleach:release","1",1374246211348000],
["nevermind","nevermind:!",1374246212053000,"t",1374246212],
["nevermind:","",1374246211365000],
["nevermind:rating","5",1374246211365000],
["nevermind:release","2",1374246211365000]
]
}]
{code}
The first patch fixes PCR to clean up indexes properly.
The second fixes LCR so that it generates SSTables like PCR & fixes its index
cleanup.
The third adds the index cleanup for memtable updates with RT.
> W/O specified columns ASPCSI does not get notified of deletes
> -
>
> Key: CASSANDRA-5614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5614
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Benjamin Coverston
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 1.2.7
>
> Attachments:
> 0001-CASSANDRA-5614-PreCompactedRow-updates-2i-correctly.patch,
> 0002-CASSANDRA-5614-LazilyCompactedRow-outputs-SSTables-a.patch,
> 0003-CASSANDRA-5614-Memtable-updates-with-RowTombstone-up.patch
>
>
> I'm working on a secondary index implementation based on the composite index
> type.
> AbstractSimplePerColumnSecondaryIndex.java#delete is not called when CQL
> delete statements do not specify columns.
> When I specify columns it is called. Pretty sure this is a bug.
> Setup:
> {code}
> cqlsh> create KEYSPACE foo WITH replication = {'class': 'SimpleStrategy' ,
> 'replication_factor': 1};
> cqlsh> use foo;
> cqlsh:foo> CREATE TABLE albums (artist text, album text, rating int, release
> int, PRIMARY KEY (artist, album));
> cqlsh:foo> CREATE INDEX ON albums (rating);
> {code}
> {code}
> cqlsh:foo> insert into albums (artist, album, rating, release) VALUES
> ('artist', 'album', 1, 2);
> {code}
> Does not get called here:
> {code}
> cqlsh:foo> DELETE FROM albums where artist='artist' and album='album';
> {code}
> {code}
> cqlsh:foo> insert into albums (artist, album, rating, release) VALUES
> ('artist', 'album', 1, 2);
> {code}
> gets called here:
> {code}
> cqlsh:foo> DELETE rating FROM albums where artist='artist' and album='album';
> {code}
--
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-5614) W/O specified columns ASPCSI does not get notified of deletes
[
https://issues.apache.org/jira/browse/CASSANDRA-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-5614:
---
Attachment: 0003-CASSANDRA-5614-Memtable-updates-with-RowTombstone-up.patch
0002-CASSANDRA-5614-LazilyCompactedRow-outputs-SSTables-a.patch
0001-CASSANDRA-5614-PreCompactedRow-updates-2i-correctly.patch
> W/O specified columns ASPCSI does not get notified of deletes
> -
>
> Key: CASSANDRA-5614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5614
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Benjamin Coverston
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 1.2.7
>
> Attachments:
> 0001-CASSANDRA-5614-PreCompactedRow-updates-2i-correctly.patch,
> 0002-CASSANDRA-5614-LazilyCompactedRow-outputs-SSTables-a.patch,
> 0003-CASSANDRA-5614-Memtable-updates-with-RowTombstone-up.patch
>
>
> I'm working on a secondary index implementation based on the composite index
> type.
> AbstractSimplePerColumnSecondaryIndex.java#delete is not called when CQL
> delete statements do not specify columns.
> When I specify columns it is called. Pretty sure this is a bug.
> Setup:
> {code}
> cqlsh> create KEYSPACE foo WITH replication = {'class': 'SimpleStrategy' ,
> 'replication_factor': 1};
> cqlsh> use foo;
> cqlsh:foo> CREATE TABLE albums (artist text, album text, rating int, release
> int, PRIMARY KEY (artist, album));
> cqlsh:foo> CREATE INDEX ON albums (rating);
> {code}
> {code}
> cqlsh:foo> insert into albums (artist, album, rating, release) VALUES
> ('artist', 'album', 1, 2);
> {code}
> Does not get called here:
> {code}
> cqlsh:foo> DELETE FROM albums where artist='artist' and album='album';
> {code}
> {code}
> cqlsh:foo> insert into albums (artist, album, rating, release) VALUES
> ('artist', 'album', 1, 2);
> {code}
> gets called here:
> {code}
> cqlsh:foo> DELETE rating FROM albums where artist='artist' and album='album';
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Zamata resolved CASSANDRA-5794. --- Resolution: Not A Problem These errors were due to regular columns being written to SSTables for super column families. > BulkOutputFormat sometimes hangs when loading small SSTables > > > Key: CASSANDRA-5794 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5794 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.6 > Environment: linux (centos 6 server, ubuntu 13.04 client) >Reporter: Jim Zamata > > We have seen the bulk loader hang under some conditions. This only seems to > occur when the last SSTable loaded is relatively small (1144 bytes in this > case). Turning on debug logging shows the StreamInSession starting to stream > a file, "en_oef_834_thrift-MessageData-ic-1-Data.db" below, and apparently > getting a Thrift transport error. This loader was able to other files, some > of them even smaller, without any problems. > The Thrift exception only appears in the debug logs, and apparently does not > cause the stream session to fail. It just hangs the session on both the > server and the client until the client is killed. When the client process is > killed, the server then gets an unexpected EOF exception. -- 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: change stream message priority(make received/retry proorities higher than complete).
Updated Branches:
refs/heads/trunk 283b1a33b -> 931be4803
change stream message priority(make received/retry proorities higher than
complete).
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/931be480
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/931be480
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/931be480
Branch: refs/heads/trunk
Commit: 931be4803b1f21dc1605612364df128dce74a6ef
Parents: 283b1a3
Author: Yuki Morishita
Authored: Tue Jul 23 13:12:34 2013 -0500
Committer: Yuki Morishita
Committed: Tue Jul 23 13:12:34 2013 -0500
--
.../org/apache/cassandra/streaming/messages/StreamMessage.java | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/931be480/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
--
diff --git
a/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
b/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
index 11e9955..8ba731a 100644
--- a/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
+++ b/src/java/org/apache/cassandra/streaming/messages/StreamMessage.java
@@ -65,9 +65,9 @@ public abstract class StreamMessage
{
PREPARE(1, 5, PrepareMessage.serializer),
FILE(2, 0, FileMessage.serializer),
-RECEIVED(3, 1, ReceivedMessage.serializer),
-RETRY(4, 1, RetryMessage.serializer),
-COMPLETE(5, 4, CompleteMessage.serializer),
+RECEIVED(3, 4, ReceivedMessage.serializer),
+RETRY(4, 4, RetryMessage.serializer),
+COMPLETE(5, 1, CompleteMessage.serializer),
SESSION_FAILED(6, 5, SessionFailedMessage.serializer);
public static Type get(byte type)
[jira] [Commented] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716610#comment-13716610 ] Jim Zamata commented on CASSANDRA-5794: --- Client logs: Client logs: 2013-07-23 16:25:12,775 INFO org.apache.cassandra.io.sstable.SSTableReader: Opening /mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1 (8 bytes) 2013-07-23 16:25:12,800 INFO org.apache.cassandra.streaming.StreamOut: Stream context metadata [/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db sections=1 progress=0/8 - 0%], 1 sstables. 2013-07-23 16:25:12,803 INFO org.apache.cassandra.streaming.StreamOutSession: Streaming to /10.165.12.229 2013-07-23 16:25:12,816 INFO org.apache.cassandra.streaming.StreamOut: Stream context metadata [/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db sections=1 progress=0/8 - 0%], 1 sstables. 2013-07-23 16:25:12,816 INFO org.apache.cassandra.streaming.StreamOutSession: Streaming to /10.164.44.90 2013-07-23 16:25:12,817 INFO org.apache.cassandra.streaming.StreamOut: Stream context metadata [/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db sections=1 progress=0/8 - 0%], 1 sstables. 2013-07-23 16:25:12,817 INFO org.apache.cassandra.streaming.StreamOutSession: Streaming to /10.164.41.26 2013-07-23 16:25:12,876 INFO org.apache.cassandra.streaming.StreamReplyVerbHandler: Successfully sent /mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db to /10.164.44.90 2013-07-23 16:25:12,877 INFO org.apache.cassandra.streaming.FileStreamTask: Finished streaming session to /10.164.44.90 2013-07-23 16:25:12,877 INFO org.apache.cassandra.streaming.StreamReplyVerbHandler: Successfully sent /mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db to /10.164.41.26 2013-07-23 16:25:12,878 INFO org.apache.cassandra.streaming.FileStreamTask: Finished streaming session to /10.164.41.26 2013-07-23 16:25:12,882 INFO org.apache.cassandra.streaming.StreamReplyVerbHandler: Successfully sent /mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/RankingData/en_oef_834_thrift-RankingData-ic-1-Data.db to /10.165.12.229 2013-07-23 16:25:12,883 INFO org.apache.cassandra.streaming.FileStreamTask: Finished streaming session to /10.165.12.229 2013-07-23 16:25:12,905 INFO org.apache.cassandra.io.sstable.SSTableReader: Opening /mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1 (1144 bytes) 2013-07-23 16:25:12,907 INFO org.apache.cassandra.streaming.StreamOut: Stream context metadata [/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db sections=1 progress=0/1144 - 0%], 1 sstables. 2013-07-23 16:25:12,907 INFO org.apache.cassandra.streaming.StreamOutSession: Streaming to /10.165.12.229 2013-07-23 16:25:12,908 INFO org.apache.cassandra.streaming.StreamOut: Stream context metadata [/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db sections=1 progress=0/1144 - 0%], 1 sstables. 2013-07-23 16:25:12,908 INFO org.apache.cassandra.streaming.StreamOutSession: Streaming to /10.164.44.90 2013-07-23 16:25:12,909 INFO org.apache.cassandra.streaming.StreamOut: Stream context metadata [/mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/attempt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db sections=1 progress=0/1144 - 0%], 1 sstables. 2013-07-23 16:25:12,910 INFO org.apache.cassandra.streaming.StreamOutSession: Streaming to /10.164.41.26 > BulkOutputFormat sometimes hangs when loadi
[jira] [Commented] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716608#comment-13716608 ] Jim Zamata commented on CASSANDRA-5794: --- Server logs after Killing hung client process: DEBUG [Thread-17] 2013-07-23 16:54:53,914 FileUtils.java (line 110) Deleting en_oef_834_thrift-MessageData-tmp-ic-12-Data.db DEBUG [Thread-17] 2013-07-23 16:54:53,914 FileUtils.java (line 110) Deleting en_oef_834_thrift-MessageData-tmp-ic-12-Filter.db DEBUG [Thread-17] 2013-07-23 16:54:53,915 FileUtils.java (line 110) Deleting en_oef_834_thrift-MessageData-tmp-ic-12-Index.db DEBUG [Thread-17] 2013-07-23 16:54:53,915 FileUtils.java (line 110) Deleting en_oef_834_thrift-MessageData-tmp-ic-12-TOC.txt DEBUG [Thread-17] 2013-07-23 16:54:53,915 FileUtils.java (line 110) Deleting en_oef_834_thrift-MessageData-tmp-ic-12-CompressionInfo.db DEBUG [Thread-17] 2013-07-23 16:54:53,915 SSTable.java (line 154) Deleted /mnt/cassandra/data/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-tmp-ic-12 ERROR [Thread-17] 2013-07-23 16:54:53,915 CassandraDaemon.java (line 192) Exception in thread Thread[Thread-17,5,main] java.io.IOError: java.io.EOFException at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:255) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:271) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:228) at edu.stanford.ppl.concurrent.SnapTreeMap.(SnapTreeMap.java:453) at org.apache.cassandra.db.AtomicSortedColumns$Holder.(AtomicSortedColumns.java:310) at org.apache.cassandra.db.AtomicSortedColumns.(AtomicSortedColumns.java:79) at org.apache.cassandra.db.AtomicSortedColumns.(AtomicSortedColumns.java:50) at org.apache.cassandra.db.AtomicSortedColumns$1.fromSorted(AtomicSortedColumns.java:63) at org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:423) at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:80) at org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:250) at org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:185) at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238) at org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78) Caused by: java.io.EOFException at java.io.DataInputStream.readFully(Unknown Source) at java.io.DataInputStream.readFully(Unknown Source) at org.apache.cassandra.utils.BytesReadTracker.readFully(BytesReadTracker.java:94) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:395) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:371) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:80) at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:251) ... 15 more > BulkOutputFormat sometimes hangs when loading small SSTables > > > Key: CASSANDRA-5794 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5794 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.6 > Environment: linux (centos 6 server, ubuntu 13.04 client) >Reporter: Jim Zamata > > We have seen the bulk loader hang under some conditions. This only seems to > occur when the last SSTable loaded is relatively small (1144 bytes in this > case). Turning on debug logging shows the StreamInSession starting to stream > a file, "en_oef_834_thrift-MessageData-ic-1-Data.db" below, and apparently > getting a Thrift transport error. This loader was able to other files, some > of them even smaller, without any problems. > The Thrift exception only appears in the debug logs, and apparently does not > cause the stream session to fail. It just hangs the session on both the > server and the client until the client is killed. When the client process is > killed, the server then gets an unexpected EOF exception. -- 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-5794) BulkOutputFormat sometimes hangs when loading small SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716606#comment-13716606 ] Jim Zamata commented on CASSANDRA-5794: --- Stack Trace showing request to stream file and Thrift errors: DEBUG [Thread-16] 2013-07-23 16:25:34,081 IncomingTcpConnection.java (line 75) Connection version 6 from /10.171.6.226 DEBUG [Thread-16] 2013-07-23 16:25:34,082 StreamInSession.java (line 104) Adding file /mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/atte mpt_201307200231_0561_r_02_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db to Stream Request queue DEBUG [Thread-16] 2013-07-23 16:25:34,082 IncomingStreamReader.java (line 112) Receiving stream DEBUG [Thread-16] 2013-07-23 16:25:34,082 IncomingStreamReader.java (line 113) Creating file for /mnt/cassandra/data/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageD ata-tmp-ic-11-Data.db with 128 estimated keys DEBUG [Thread-16] 2013-07-23 16:25:34,083 ColumnFamilyStore.java (line 862) Checking for sstables overlapping [] DEBUG [Thrift:40] 2013-07-23 16:25:34,092 StorageService.java (line 2578) computing ranges for -3074457345618258603, 3074457345618258602, 9223372036854775807 DEBUG [Thread-17] 2013-07-23 16:25:34,117 IncomingTcpConnection.java (line 75) Connection version 6 from /10.171.6.226 DEBUG [Thread-17] 2013-07-23 16:25:34,117 StreamInSession.java (line 104) Adding file /mnt/hadoop-local/mapred/local/taskTracker/ec2-user/jobcache/job_201307200231_0561/atte mpt_201307200231_0561_r_00_0/work/tmp/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageData-ic-1-Data.db to Stream Request queue DEBUG [Thread-17] 2013-07-23 16:25:34,117 IncomingStreamReader.java (line 112) Receiving stream DEBUG [Thread-17] 2013-07-23 16:25:34,117 IncomingStreamReader.java (line 113) Creating file for /mnt/cassandra/data/en_oef_834_thrift/MessageData/en_oef_834_thrift-MessageD ata-tmp-ic-12-Data.db with 128 estimated keys DEBUG [Thread-17] 2013-07-23 16:25:34,118 ColumnFamilyStore.java (line 862) Checking for sstables overlapping [] DEBUG [Thrift:8] 2013-07-23 16:25:45,135 StorageService.java (line 2578) computing ranges for -3074457345618258603, 3074457345618258602, 9223372036854775807 DEBUG [ScheduledTasks:1] 2013-07-23 16:26:05,875 LoadBroadcaster.java (line 87) Disseminating load info ... DEBUG [Thrift:16] 2013-07-23 16:26:19,491 StorageService.java (line 2578) computing ranges for -3074457345618258603, 3074457345618258602, 9223372036854775807 DEBUG [OptionalTasks:1] 2013-07-23 16:26:33,926 BatchlogManager.java (line 157) Started replayAllFailedBatches DEBUG [MemtablePostFlusher:1] 2013-07-23 16:26:33,927 ColumnFamilyStore.java (line 693) forceFlush requested but everything is clean in batchlog DEBUG [OptionalTasks:1] 2013-07-23 16:26:33,927 BatchlogManager.java (line 171) Finished replayAllFailedBatches DEBUG [Thrift:1] 2013-07-23 16:26:35,638 StorageService.java (line 2578) computing ranges for -3074457345618258603, 3074457345618258602, 9223372036854775807 DEBUG [Thrift:10] 2013-07-23 16:27:00,383 StorageService.java (line 2578) computing ranges for -3074457345618258603, 3074457345618258602, 9223372036854775807 DEBUG [ScheduledTasks:1] 2013-07-23 16:27:05,876 LoadBroadcaster.java (line 87) Disseminating load info ... DEBUG [Thrift:7] 2013-07-23 16:27:15,167 StorageService.java (line 2578) computing ranges for -3074457345618258603, 3074457345618258602, 9223372036854775807 DEBUG [OptionalTasks:1] 2013-07-23 16:27:33,927 BatchlogManager.java (line 157) Started replayAllFailedBatches DEBUG [MemtablePostFlusher:1] 2013-07-23 16:27:33,928 ColumnFamilyStore.java (line 693) forceFlush requested but everything is clean in batchlog DEBUG [OptionalTasks:1] 2013-07-23 16:27:33,928 BatchlogManager.java (line 171) Finished replayAllFailedBatches DEBUG [Thrift:42] 2013-07-23 16:27:48,489 CustomTThreadPoolServer.java (line 209) Thrift transport error occurred during processing of message. org.apache.thrift.transport.TTransportException at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132) at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84) at org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:129) at org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101) at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84) at org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378) at org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297) at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:204) at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:22) at org.apache.cassandra.thrift.Cu
[jira] [Created] (CASSANDRA-5794) BulkOutputFormat sometimes hangs when loading small SSTables
Jim Zamata created CASSANDRA-5794: - Summary: BulkOutputFormat sometimes hangs when loading small SSTables Key: CASSANDRA-5794 URL: https://issues.apache.org/jira/browse/CASSANDRA-5794 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.6 Environment: linux (centos 6 server, ubuntu 13.04 client) Reporter: Jim Zamata We have seen the bulk loader hang under some conditions. This only seems to occur when the last SSTable loaded is relatively small (1144 bytes in this case). Turning on debug logging shows the StreamInSession starting to stream a file, "en_oef_834_thrift-MessageData-ic-1-Data.db" below, and apparently getting a Thrift transport error. This loader was able to other files, some of them even smaller, without any problems. The Thrift exception only appears in the debug logs, and apparently does not cause the stream session to fail. It just hangs the session on both the server and the client until the client is killed. When the client process is killed, the server then gets an unexpected EOF exception. -- 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
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk Conflicts: build.xml debian/changelog Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/283b1a33 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/283b1a33 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/283b1a33 Branch: refs/heads/trunk Commit: 283b1a33b47e6b9acbd30efd320ec47f8b029af4 Parents: db70bbe 66bd605 Author: Sylvain Lebresne Authored: Tue Jul 23 19:00:36 2013 +0200 Committer: Sylvain Lebresne Committed: Tue Jul 23 19:00:36 2013 +0200 -- doc/cql3/CQL.textile | 4 1 file changed, 4 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/283b1a33/doc/cql3/CQL.textile --
[1/3] git commit: Update versions for 1.2.7 release
Updated Branches: refs/heads/trunk db70bbe41 -> 283b1a33b Update versions for 1.2.7 release Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae62c947 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae62c947 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae62c947 Branch: refs/heads/trunk Commit: ae62c947fc245295785324502bf6bc2c1c8477f9 Parents: 0f0a11c Author: Sylvain Lebresne Authored: Tue Jul 23 15:44:09 2013 +0200 Committer: Sylvain Lebresne Committed: Tue Jul 23 15:44:09 2013 +0200 -- NEWS.txt | 1 + build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 8 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index d4d127b..9a7dd51 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -15,6 +15,7 @@ using the provided 'sstableupgrade' tool. 1.2.7 = + Upgrading - - If you have decommissioned a node in the past 72 hours, it is imperative http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/build.xml -- diff --git a/build.xml b/build.xml index 8d54554..523a225 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ - + http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/> http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/debian/changelog -- diff --git a/debian/changelog b/debian/changelog index 3be9ba0..d0c7017 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (1.2.7) unstable; urgency=low + + * New release + + -- Sylvain Lebresne Tue, 23 Jul 2013 15:42:51 +0200 + cassandra (1.2.6) unstable; urgency=low * New release
[2/3] git commit: Document multiline comments
Document multiline comments Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/66bd6059 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/66bd6059 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/66bd6059 Branch: refs/heads/trunk Commit: 66bd60590a82d78790c279bf1d2130b82a7d6475 Parents: ae62c94 Author: Sylvain Lebresne Authored: Tue Jul 23 18:59:43 2013 +0200 Committer: Sylvain Lebresne Committed: Tue Jul 23 18:59:43 2013 +0200 -- doc/cql3/CQL.textile | 4 1 file changed, 4 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/66bd6059/doc/cql3/CQL.textile -- diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile index f7d2dda..44c4dd2 100644 --- a/doc/cql3/CQL.textile +++ b/doc/cql3/CQL.textile @@ -61,9 +61,13 @@ h3. Comments A comment in CQL is a line beginning by either double dashes (@--@) or double slash (@//@). +Multi-line comments are also supported through enclosure withing @/*@ and @*/@ (but nesting is not supported). + bc(sample). -- This is a comment // This is a comment too +/* This is + a multiline comment */ h3(#statements). Statements
git commit: Document multiline comments
Updated Branches: refs/heads/cassandra-1.2 ae62c947f -> 66bd60590 Document multiline comments Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/66bd6059 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/66bd6059 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/66bd6059 Branch: refs/heads/cassandra-1.2 Commit: 66bd60590a82d78790c279bf1d2130b82a7d6475 Parents: ae62c94 Author: Sylvain Lebresne Authored: Tue Jul 23 18:59:43 2013 +0200 Committer: Sylvain Lebresne Committed: Tue Jul 23 18:59:43 2013 +0200 -- doc/cql3/CQL.textile | 4 1 file changed, 4 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/66bd6059/doc/cql3/CQL.textile -- diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile index f7d2dda..44c4dd2 100644 --- a/doc/cql3/CQL.textile +++ b/doc/cql3/CQL.textile @@ -61,9 +61,13 @@ h3. Comments A comment in CQL is a line beginning by either double dashes (@--@) or double slash (@//@). +Multi-line comments are also supported through enclosure withing @/*@ and @*/@ (but nesting is not supported). + bc(sample). -- This is a comment // This is a comment too +/* This is + a multiline comment */ h3(#statements). Statements
git commit: Add CAS to the CQL doc
Updated Branches:
refs/heads/trunk 27056ece4 -> db70bbe41
Add CAS to the CQL doc
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/db70bbe4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/db70bbe4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/db70bbe4
Branch: refs/heads/trunk
Commit: db70bbe41438d17387e714537a4f705dae418515
Parents: 27056ec
Author: Sylvain Lebresne
Authored: Tue Jul 23 18:41:22 2013 +0200
Committer: Sylvain Lebresne
Committed: Tue Jul 23 18:41:32 2013 +0200
--
doc/cql3/CQL.textile | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/db70bbe4/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 34a0c12..9a24ec0 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -409,7 +409,7 @@ CREATE INDEX userIndex ON NerdMovies (user);
CREATE INDEX ON Mutants (abilityId);
CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass';
-The @CREATE INDEX@ statement is used to create a new (automatic) secondary
index for a given (existing) column in a given table. A name for the index
itself can be specified before the @ON@ keyword, if desired. If data already
exists for the column, it will be indexed during the execution of this
statement. After the index is created, new data for the column is indexed
automatically at insertion time.
+The @CREATE INDEX@ statement is used to create a new (automatic) secondary
index for a given (existing) column in a given table. A name for the index
itself can be specified before the @ON@ keyword, if desired. If data already
exists for the column, it will be indexed asynchronously. After the index is
created, new data for the column is indexed automatically at insertion time.
Attempting to create an already existing index will return an error unless the
@IF NOT EXISTS@ option is used. If it is used, the statement will be a no-op if
the index already exists.
@@ -437,6 +437,7 @@ bc(syntax)..
::= INSERT INTO
'(' ( ',' )* ')'
VALUES '(' ( ',' )*
')'
+ ( IF NOT EXISTS )?
( USING ( AND )* )?
::=
@@ -454,7 +455,9 @@ USING TTL 86400;
The @INSERT@ statement writes one or more columns for a given row in a table.
Note that since a row is identified by its @PRIMARY KEY@, the columns that
compose it must be specified. Also, since a row only exists when it contains
one value for a column not part of the @PRIMARY KEY@, one such value must be
specified too.
-Note that unlike in SQL, @INSERT@ does not check the prior existence of the
row: the row is created if none existed before, and updated otherwise.
Furthermore, there is no mean to know which of creation or update happened. In
fact, the semantic of @INSERT@ and @UPDATE@ are identical.
+Note that unlike in SQL, @INSERT@ does not check the prior existence of the
row by default: the row is created if none existed before, and updated
otherwise. Furthermore, there is no mean to know which of creation or update
happened.
+
+It is however possible to use the @IF NOT EXISTS@ condition to only insert if
the row does not exist prior to the insertion. But please note that using @IF
NOT EXISTS@ will incur a non negligible performance cost (internally, Paxos
will be used) so this should be used sparingly.
All updates for an @INSERT@ are applied atomically and in isolation.
@@ -469,6 +472,7 @@ bc(syntax)..
( USING ( AND )* )?
SET ( ',' )*
WHERE
+ ( IF '=' ( AND '='
)* )?
::= '='
| '=' ('+' | '-') ( |
| )
@@ -494,7 +498,9 @@ UPDATE UserActions SET total = total + 2 WHERE user =
B70DE1D0-9908-4AE3-BE34-55
p.
The @UPDATE@ statement writes one or more columns for a given row in a table.
The @@ is used to select the row to update and must include all
columns composing the @PRIMARY KEY@. Other columns values are specified through
@@ after the @SET@ keyword.
-Note that unlike in SQL, @UPDATE@ does not check the prior existence of the
row: the row is created if none existed before, and updated otherwise.
Furthermore, there is no mean to know which of creation or update happened. In
fact, the semantic of @INSERT@ and @UPDATE@ are identical.
+Note that unlike in SQL, @UPDATE@ does not check the prior existence of the
row by default: the row is created if none existed before, and updated
otherwise. Furthermore, there is no mean to know which of creation or update
happened.
+
+It is however possible to use the conditions on some columns through @IF@,
[jira] [Commented] (CASSANDRA-5788) StorageProxy#cas() doesn't order columns names correctly when querying
[
https://issues.apache.org/jira/browse/CASSANDRA-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716527#comment-13716527
]
Jonathan Ellis commented on CASSANDRA-5788:
---
We've rolled a release w/ this now so probably best to make a new ticket, sorry.
> StorageProxy#cas() doesn't order columns names correctly when querying
> --
>
> Key: CASSANDRA-5788
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5788
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 2.0 beta 1
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0 beta 2
>
> Attachments: 5788.txt
>
>
> When querying columns for CAS, we build the SortedSet with:
> {noformat}
> new NamesQueryFilter(ImmutableSortedSet.copyOf(expected.getColumnNames())
> {noformat}
> but ImmutableSortedSet.copyOf() uses the natural order of keys unless a
> comparator is given, which is not what we want.
--
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-5788) StorageProxy#cas() doesn't order columns names correctly when querying
[
https://issues.apache.org/jira/browse/CASSANDRA-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716509#comment-13716509
]
Edward Capriolo commented on CASSANDRA-5788:
Can we re-open so I can put a unit test around this? I see we said this is
trivial but I think a test could help prevent this from happening again.
> StorageProxy#cas() doesn't order columns names correctly when querying
> --
>
> Key: CASSANDRA-5788
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5788
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 2.0 beta 1
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0 beta 2
>
> Attachments: 5788.txt
>
>
> When querying columns for CAS, we build the SortedSet with:
> {noformat}
> new NamesQueryFilter(ImmutableSortedSet.copyOf(expected.getColumnNames())
> {noformat}
> but ImmutableSortedSet.copyOf() uses the natural order of keys unless a
> comparator is given, which is not what we want.
--
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-5792) Buffer Underflow during streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-5792:
--
Attachment: 5792.txt
There is a chance we get nothing from socket, like when socket gets closed.
Patch attached to check we actually read something from socket.
> Buffer Underflow during streaming
> -
>
> Key: CASSANDRA-5792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5792
> Project: Cassandra
> Issue Type: Bug
>Reporter: Brandon Williams
>Assignee: Yuki Morishita
> Fix For: 2.0
>
> Attachments: 5792.txt
>
>
> {noformat}
> ERROR [STREAM-IN-/127.0.0.3] 2013-07-22 16:19:50,597 StreamSession.java (line
> 414) Streaming error occurred
> java.nio.BufferUnderflowException
> at java.nio.Buffer.nextGetIndex(Buffer.java:492)
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:135)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:52)
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:288)
> at java.lang.Thread.run(Thread.java:722)
> {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-5704) add cassandra.unsafesystem property (Truncate flushes to disk again in 1.2, even with durable_writes=false)
[
https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Spriegel updated CASSANDRA-5704:
--
Summary: add cassandra.unsafesystem property (Truncate flushes to disk
again in 1.2, even with durable_writes=false) (was: Truncate flushes to disk
again in 1.2, even with durable_writes=false)
> add cassandra.unsafesystem property (Truncate flushes to disk again in 1.2,
> even with durable_writes=false)
> ---
>
> Key: CASSANDRA-5704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.5
>Reporter: Christian Spriegel
>Assignee: Jonathan Ellis
>Priority: Minor
> Fix For: 1.2.7, 2.0 beta 2
>
> Attachments: 5704_unsafeSystem.txt, 5704-v2.txt,
> CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch
>
>
> I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my
> JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
> With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
> My proposal is to make saveTruncationRecord() only flush when durableWrites
> are enabled.
> My assumption is that if somebody turn off durable writes then he does not
> mind if truncate is not guaranteed to be durable either.
> I successfully tested the following patch with my testsuite. Its as fast as
> it was with 1.1 (maybe even faster!):
> {code}
> @@ -186,5 +186,8 @@ public class SystemTable
> String req = "UPDATE system.%s SET truncated_at = truncated_at + %s
> WHERE key = '%s'";
> processInternal(String.format(req, LOCAL_CF,
> truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
> -forceBlockingFlush(LOCAL_CF);
> +
> +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
> +if (ksm.durableWrites) // flush only when durable_writes are enabled
> +forceBlockingFlush(LOCAL_CF);
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5704) add cassandra.unsafesystem property (Truncate flushes to disk again in 1.2, even with durable_writes=false)
[
https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13712662#comment-13712662
]
Christian Spriegel edited comment on CASSANDRA-5704 at 7/23/13 3:03 PM:
Awesome, thanks!
For documentation purposes: The property is: -Dcassandra.unsafesystem=true
was (Author: christianmovi):
Awesome, thanks!
For documentation purposes: The property in 2.0 is:
-Dcassandra.unsafesystem=true
> add cassandra.unsafesystem property (Truncate flushes to disk again in 1.2,
> even with durable_writes=false)
> ---
>
> Key: CASSANDRA-5704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.5
>Reporter: Christian Spriegel
>Assignee: Jonathan Ellis
>Priority: Minor
> Fix For: 1.2.7, 2.0 beta 2
>
> Attachments: 5704_unsafeSystem.txt, 5704-v2.txt,
> CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch
>
>
> I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my
> JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
> With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
> My proposal is to make saveTruncationRecord() only flush when durableWrites
> are enabled.
> My assumption is that if somebody turn off durable writes then he does not
> mind if truncate is not guaranteed to be durable either.
> I successfully tested the following patch with my testsuite. Its as fast as
> it was with 1.1 (maybe even faster!):
> {code}
> @@ -186,5 +186,8 @@ public class SystemTable
> String req = "UPDATE system.%s SET truncated_at = truncated_at + %s
> WHERE key = '%s'";
> processInternal(String.format(req, LOCAL_CF,
> truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
> -forceBlockingFlush(LOCAL_CF);
> +
> +KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
> +if (ksm.durableWrites) // flush only when durable_writes are enabled
> +forceBlockingFlush(LOCAL_CF);
> }
> {code}
--
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 Push Summary
Updated Tags: refs/tags/1.2.7-tentative [created] ae62c947f
git commit: Update versions for 1.2.7 release
Updated Branches: refs/heads/cassandra-1.2 0f0a11c97 -> ae62c947f Update versions for 1.2.7 release Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ae62c947 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ae62c947 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ae62c947 Branch: refs/heads/cassandra-1.2 Commit: ae62c947fc245295785324502bf6bc2c1c8477f9 Parents: 0f0a11c Author: Sylvain Lebresne Authored: Tue Jul 23 15:44:09 2013 +0200 Committer: Sylvain Lebresne Committed: Tue Jul 23 15:44:09 2013 +0200 -- NEWS.txt | 1 + build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 8 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/NEWS.txt -- diff --git a/NEWS.txt b/NEWS.txt index d4d127b..9a7dd51 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -15,6 +15,7 @@ using the provided 'sstableupgrade' tool. 1.2.7 = + Upgrading - - If you have decommissioned a node in the past 72 hours, it is imperative http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/build.xml -- diff --git a/build.xml b/build.xml index 8d54554..523a225 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ - + http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/> http://git-wip-us.apache.org/repos/asf/cassandra/blob/ae62c947/debian/changelog -- diff --git a/debian/changelog b/debian/changelog index 3be9ba0..d0c7017 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (1.2.7) unstable; urgency=low + + * New release + + -- Sylvain Lebresne Tue, 23 Jul 2013 15:42:51 +0200 + cassandra (1.2.6) unstable; urgency=low * New release
[jira] [Commented] (CASSANDRA-5793) OPP seems completely unsupported
[ https://issues.apache.org/jira/browse/CASSANDRA-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716384#comment-13716384 ] Jonathan Ellis commented on CASSANDRA-5793: --- bq. One possibility is that getToken of OPP can return hex value if it fails to encode bytes to UTF-8 instead of throwing error. I can't think of how it would break anything to accept keys we previously rejected. > OPP seems completely unsupported > > > Key: CASSANDRA-5793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5793 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.5 > Environment: Cassandra on Ubuntu >Reporter: Vara Kumar > Fix For: 1.2.7 > > > We were using 0.7.6 version. And upgraded to 1.2.5 today. We were using OPP > (OrderPreservingPartitioner). > OPP throws error when any node join the cluster. Cluster can not be brought > up due to this error. After digging little deep, We realized that "peers" > column family is defined with key as type "inet". Looks like many other > column families in system keyspace has same issue. > Exception trace: > java.lang.RuntimeException: The provided key was not UTF8 encoded. > at > org.apache.cassandra.dht.OrderPreservingPartitioner.getToken(OrderPreservingPartitioner.java:172) > at > org.apache.cassandra.dht.OrderPreservingPartitioner.decorateKey(OrderPreservingPartitioner.java:44) > at org.apache.cassandra.db.Table.apply(Table.java:379) > at org.apache.cassandra.db.Table.apply(Table.java:353) > at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:258) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:117) > at > org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:172) > at > org.apache.cassandra.db.SystemTable.updatePeerInfo(SystemTable.java:258) > at > org.apache.cassandra.service.StorageService.onChange(StorageService.java:1231) > at > org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1948) > at > org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:823) > at > org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:901) > at > org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:50) > Possibilities: > - Changing partitioner to BOP (or something else) fails while loading > schema_keyspaces. So, it does not look like an option. > - One possibility is that getToken of OPP can return hex value if it fails to > encode bytes to UTF-8 instead of throwing error. By this system tables seem > to be working fine with OPP. > - Or Completely remove OPP from code base & configuration files. Mark clearly > that OPP is no longer supported in upgrade instructions. -- 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-5793) OPP seems completely unsupported
[ https://issues.apache.org/jira/browse/CASSANDRA-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716366#comment-13716366 ] Jeremy Hanna commented on CASSANDRA-5793: - I suppose I was assuming that you were using the now removed COPP, but since you're using just the OPP, that *should* work. Sorry for the confusion. > OPP seems completely unsupported > > > Key: CASSANDRA-5793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5793 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.5 > Environment: Cassandra on Ubuntu >Reporter: Vara Kumar > Fix For: 1.2.7 > > > We were using 0.7.6 version. And upgraded to 1.2.5 today. We were using OPP > (OrderPreservingPartitioner). > OPP throws error when any node join the cluster. Cluster can not be brought > up due to this error. After digging little deep, We realized that "peers" > column family is defined with key as type "inet". Looks like many other > column families in system keyspace has same issue. > Exception trace: > java.lang.RuntimeException: The provided key was not UTF8 encoded. > at > org.apache.cassandra.dht.OrderPreservingPartitioner.getToken(OrderPreservingPartitioner.java:172) > at > org.apache.cassandra.dht.OrderPreservingPartitioner.decorateKey(OrderPreservingPartitioner.java:44) > at org.apache.cassandra.db.Table.apply(Table.java:379) > at org.apache.cassandra.db.Table.apply(Table.java:353) > at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:258) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:117) > at > org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:172) > at > org.apache.cassandra.db.SystemTable.updatePeerInfo(SystemTable.java:258) > at > org.apache.cassandra.service.StorageService.onChange(StorageService.java:1231) > at > org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1948) > at > org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:823) > at > org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:901) > at > org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:50) > Possibilities: > - Changing partitioner to BOP (or something else) fails while loading > schema_keyspaces. So, it does not look like an option. > - One possibility is that getToken of OPP can return hex value if it fails to > encode bytes to UTF-8 instead of throwing error. By this system tables seem > to be working fine with OPP. > - Or Completely remove OPP from code base & configuration files. Mark clearly > that OPP is no longer supported in upgrade instructions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5793) OPP seems completely unsupported
[ https://issues.apache.org/jira/browse/CASSANDRA-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716289#comment-13716289 ] Jeremy Hanna edited comment on CASSANDRA-5793 at 7/23/13 10:40 AM: --- See https://github.com/apache/cassandra/blob/cassandra-1.2.6/NEWS.txt#L184-L186 You can't change partitioner once the data has been written. Rows of data are ordered in sstables according to the partitioner. You can upgrade to 1.1.x or stay at 0.7, then using Hadoop or a batch job, you can read from your existing cluster and write to a different cluster running 1.2.6 with your new partitioner. was (Author: jeromatron): See https://github.com/apache/cassandra/blob/cassandra-1.2.6/NEWS.txt#L184-L186 You can't change partitioner once the data has been written. Row of data are ordered in sstables according to the partitioner. You can upgrade to 1.1.x or stay at 0.7, then using Hadoop or a batch job, you can read from your existing cluster and write to a different cluster running 1.2.6 with your new partitioner. > OPP seems completely unsupported > > > Key: CASSANDRA-5793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5793 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.5 > Environment: Cassandra on Ubuntu >Reporter: Vara Kumar > Fix For: 1.2.7 > > > We were using 0.7.6 version. And upgraded to 1.2.5 today. We were using OPP > (OrderPreservingPartitioner). > OPP throws error when any node join the cluster. Cluster can not be brought > up due to this error. After digging little deep, We realized that "peers" > column family is defined with key as type "inet". Looks like many other > column families in system keyspace has same issue. > Exception trace: > java.lang.RuntimeException: The provided key was not UTF8 encoded. > at > org.apache.cassandra.dht.OrderPreservingPartitioner.getToken(OrderPreservingPartitioner.java:172) > at > org.apache.cassandra.dht.OrderPreservingPartitioner.decorateKey(OrderPreservingPartitioner.java:44) > at org.apache.cassandra.db.Table.apply(Table.java:379) > at org.apache.cassandra.db.Table.apply(Table.java:353) > at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:258) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:117) > at > org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:172) > at > org.apache.cassandra.db.SystemTable.updatePeerInfo(SystemTable.java:258) > at > org.apache.cassandra.service.StorageService.onChange(StorageService.java:1231) > at > org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1948) > at > org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:823) > at > org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:901) > at > org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:50) > Possibilities: > - Changing partitioner to BOP (or something else) fails while loading > schema_keyspaces. So, it does not look like an option. > - One possibility is that getToken of OPP can return hex value if it fails to > encode bytes to UTF-8 instead of throwing error. By this system tables seem > to be working fine with OPP. > - Or Completely remove OPP from code base & configuration files. Mark clearly > that OPP is no longer supported in upgrade instructions. -- 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-5793) OPP seems completely unsupported
[ https://issues.apache.org/jira/browse/CASSANDRA-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716289#comment-13716289 ] Jeremy Hanna commented on CASSANDRA-5793: - See https://github.com/apache/cassandra/blob/cassandra-1.2.6/NEWS.txt#L184-L186 You can't change partitioner once the data has been written. Row of data are ordered in sstables according to the partitioner. You can upgrade to 1.1.x or stay at 0.7, then using Hadoop or a batch job, you can read from your existing cluster and write to a different cluster running 1.2.6 with your new partitioner. > OPP seems completely unsupported > > > Key: CASSANDRA-5793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5793 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.5 > Environment: Cassandra on Ubuntu >Reporter: Vara Kumar > Fix For: 1.2.7 > > > We were using 0.7.6 version. And upgraded to 1.2.5 today. We were using OPP > (OrderPreservingPartitioner). > OPP throws error when any node join the cluster. Cluster can not be brought > up due to this error. After digging little deep, We realized that "peers" > column family is defined with key as type "inet". Looks like many other > column families in system keyspace has same issue. > Exception trace: > java.lang.RuntimeException: The provided key was not UTF8 encoded. > at > org.apache.cassandra.dht.OrderPreservingPartitioner.getToken(OrderPreservingPartitioner.java:172) > at > org.apache.cassandra.dht.OrderPreservingPartitioner.decorateKey(OrderPreservingPartitioner.java:44) > at org.apache.cassandra.db.Table.apply(Table.java:379) > at org.apache.cassandra.db.Table.apply(Table.java:353) > at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:258) > at > org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:117) > at > org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:172) > at > org.apache.cassandra.db.SystemTable.updatePeerInfo(SystemTable.java:258) > at > org.apache.cassandra.service.StorageService.onChange(StorageService.java:1231) > at > org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1948) > at > org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:823) > at > org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:901) > at > org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:50) > Possibilities: > - Changing partitioner to BOP (or something else) fails while loading > schema_keyspaces. So, it does not look like an option. > - One possibility is that getToken of OPP can return hex value if it fails to > encode bytes to UTF-8 instead of throwing error. By this system tables seem > to be working fine with OPP. > - Or Completely remove OPP from code base & configuration files. Mark clearly > that OPP is no longer supported in upgrade instructions. -- 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-5793) OPP seems completely unsupported
Vara Kumar created CASSANDRA-5793: - Summary: OPP seems completely unsupported Key: CASSANDRA-5793 URL: https://issues.apache.org/jira/browse/CASSANDRA-5793 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.5 Environment: Cassandra on Ubuntu Reporter: Vara Kumar Fix For: 1.2.7 We were using 0.7.6 version. And upgraded to 1.2.5 today. We were using OPP (OrderPreservingPartitioner). OPP throws error when any node join the cluster. Cluster can not be brought up due to this error. After digging little deep, We realized that "peers" column family is defined with key as type "inet". Looks like many other column families in system keyspace has same issue. Exception trace: java.lang.RuntimeException: The provided key was not UTF8 encoded. at org.apache.cassandra.dht.OrderPreservingPartitioner.getToken(OrderPreservingPartitioner.java:172) at org.apache.cassandra.dht.OrderPreservingPartitioner.decorateKey(OrderPreservingPartitioner.java:44) at org.apache.cassandra.db.Table.apply(Table.java:379) at org.apache.cassandra.db.Table.apply(Table.java:353) at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:258) at org.apache.cassandra.cql3.statements.ModificationStatement.executeInternal(ModificationStatement.java:117) at org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:172) at org.apache.cassandra.db.SystemTable.updatePeerInfo(SystemTable.java:258) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1231) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1948) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:823) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:901) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:50) Possibilities: - Changing partitioner to BOP (or something else) fails while loading schema_keyspaces. So, it does not look like an option. - One possibility is that getToken of OPP can return hex value if it fails to encode bytes to UTF-8 instead of throwing error. By this system tables seem to be working fine with OPP. - Or Completely remove OPP from code base & configuration files. Mark clearly that OPP is no longer supported in upgrade instructions. -- 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-5626) Support empty IN queries
[ https://issues.apache.org/jira/browse/CASSANDRA-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716264#comment-13716264 ] Alexander Solovyev commented on CASSANDRA-5626: --- Thank you, guys. Looking forward. > Support empty IN queries > > > Key: CASSANDRA-5626 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5626 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Alexander Solovyev >Assignee: Aleksey Yeschenko >Priority: Minor > > It would be nice to have support of empty IN queries. > Example: "SELECT a FROM t WHERE aKey IN ()". > One of the reasons is to have such support in DataStax Java Driver (see > discussion here: https://datastax-oss.atlassian.net/browse/JAVA-106). -- 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-5138) Provide a better CQL error when table data does not conform to CQL metadata.
[ https://issues.apache.org/jira/browse/CASSANDRA-5138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5138: Attachment: 5138-2.txt I guess all I meant is that since people tends to get touchy when you limit the thrift interface, doing the minimum validation so as not to crash CQL could be an option. Anyway, doesn't matter, attaching v2 patch that does the extra check. > Provide a better CQL error when table data does not conform to CQL metadata. > > > Key: CASSANDRA-5138 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5138 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.2.0 > Environment: Mac OS X running 1.2 >Reporter: Brian ONeill >Assignee: Sylvain Lebresne >Priority: Minor > Fix For: 1.2.7 > > Attachments: 5138-2.txt, 5138.txt, northpole.cql > > > When you create a table via CQL, then insert into it via Thrift. If you > inadvertently leave out a component of the column name, in CQL you receive a: > TSocket read 0 bytes > Server-side the following exception is logged: > ERROR 15:19:18,016 Error occurred during processing of message. > java.lang.ArrayIndexOutOfBoundsException: 3 > at > org.apache.cassandra.cql3.statements.ColumnGroupMap.add(ColumnGroupMap.java:43) > at > org.apache.cassandra.cql3.statements.ColumnGroupMap.access$200(ColumnGroupMap.java:31) > at > org.apache.cassandra.cql3.statements.ColumnGroupMap$Builder.add(ColumnGroupMap.java:138) > at > org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:805) > at > org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:145) > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:134) > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:61) > at > org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:132) > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:140) > at > org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1686) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4074) > at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4062) > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) > at > org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199) > 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:680) > I'll submit a schema, and steps to reproduce. -- 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
