[jira] [Updated] (CASSANDRA-5099) Since 1.1, get_count sometimes returns value smaller than actual column count
[
https://issues.apache.org/jira/browse/CASSANDRA-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Harvey updated CASSANDRA-5099:
Summary: Since 1.1, get_count sometimes returns value smaller than actual
column count (was: get_count sometimes returns value smaller than actual
column count)
Since 1.1, get_count sometimes returns value smaller than actual column count
-
Key: CASSANDRA-5099
URL: https://issues.apache.org/jira/browse/CASSANDRA-5099
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.7
Reporter: Jason Harvey
Priority: Minor
We have a CF where rows have thousands of TTLd columns. The columns are
continually added at a regular rate, and TTL out after 15 minutes. We
continually run a 'get_count' on these keys to get a count of the number of
live columns.
Since we upgrade from 1.0 to 1.1.7, get_count regularly returns much
smaller values than are possible. For example, with roughly 15,000 columns
that have well-distributed TTLs, running a get_count 10 times will result in
1 or 2 results that are up to half the actual column count. Using a normal
'get' to count those columns always results in proper values.
For example:
(all of these counts were ran within a second or less of eachother)
{code}
[default@reddit] count AccountsActiveBySR['2qh0u'];
13665 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13665 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13666 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
3069 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13660 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13661 columns
{code}
I should note that this issue happens much more frequently with larger (10k
columns) rows than smaller rows. It never seems to happen with rows having
fewer than 1k columns.
There are no supercolumns in use. The key names and column names are very
short, and there are no column values. The CF is LCS, and due to the TTL only
hovers around a few MB in size. GC grace is normally at zero, but the problem
is consistent with non-zero gc grace times.
It appears that there was an issue (CASSANDRA-4833) fixed in 1.1.7 regarding
get_count. Some logic was added to prevent an infinite loop case. Could that
change have resulted in this problem somehow? I can't find any other relevant
1.1 changes that might explain this issue.
--
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-5099) Since 1.1, get_count sometimes returns value smaller than actual column count
[
https://issues.apache.org/jira/browse/CASSANDRA-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13545698#comment-13545698
]
Jason Harvey commented on CASSANDRA-5099:
-
I've ported the 1.0.11 get_count code from CassandraServer.java to 1.1.7. Doing
so resolves this issue.
Since 1.1, get_count sometimes returns value smaller than actual column count
-
Key: CASSANDRA-5099
URL: https://issues.apache.org/jira/browse/CASSANDRA-5099
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.7
Reporter: Jason Harvey
Priority: Minor
We have a CF where rows have thousands of TTLd columns. The columns are
continually added at a regular rate, and TTL out after 15 minutes. We
continually run a 'get_count' on these keys to get a count of the number of
live columns.
Since we upgrade from 1.0 to 1.1.7, get_count regularly returns much
smaller values than are possible. For example, with roughly 15,000 columns
that have well-distributed TTLs, running a get_count 10 times will result in
1 or 2 results that are up to half the actual column count. Using a normal
'get' to count those columns always results in proper values.
For example:
(all of these counts were ran within a second or less of eachother)
{code}
[default@reddit] count AccountsActiveBySR['2qh0u'];
13665 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13665 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13666 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
3069 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13660 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13661 columns
{code}
I should note that this issue happens much more frequently with larger (10k
columns) rows than smaller rows. It never seems to happen with rows having
fewer than 1k columns.
There are no supercolumns in use. The key names and column names are very
short, and there are no column values. The CF is LCS, and due to the TTL only
hovers around a few MB in size. GC grace is normally at zero, but the problem
is consistent with non-zero gc grace times.
It appears that there was an issue (CASSANDRA-4833) fixed in 1.1.7 regarding
get_count. Some logic was added to prevent an infinite loop case. Could that
change have resulted in this problem somehow? I can't find any other relevant
1.1 changes that might explain this issue.
--
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-5112) Setting up authentication tables with custom authentication plugin
[ https://issues.apache.org/jira/browse/CASSANDRA-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13545716#comment-13545716 ] Dirkjan Bussink commented on CASSANDRA-5112: Having that onJoined / onReady and onBootstrapped would be great. Would be really nice if those could be used to properly setup these tables for authentication. Regarding the setup for the users table. Originally I asked whether creating a separate strategy that replicates data across all nodes would be a good idea, but that idea wasn't considered to be the best approach. Would love to hear about other ideas, having the cluster become inaccessible if the user account for a certain user happens to be on a node that is down seems like very problematic to me. Setting up authentication tables with custom authentication plugin -- Key: CASSANDRA-5112 URL: https://issues.apache.org/jira/browse/CASSANDRA-5112 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.2.0 Reporter: Dirkjan Bussink Priority: Minor I'm working on updating https://github.com/nedap/cassandra-auth with the new authentication API's in Cassandra 1.2.0. I have stumbled on an issue and I'm not really sure how to handle it. For the authentication I want to setup additional column families for the passwords and permissions. As recommended in the documentation of IAuthorizer, I'm trying to create these tables during setup(): Setup is called once upon system startup to initialize the IAuthorizer. For example, use this method to create any required keyspaces/column families.. The problem is that doing this seems to be a lot harder than I would think, or I'm perhaps missing something obvious. I've tried various attempts, but all have failed: - CQL and QueryProcessor.processInternal to setup additional column families. This fails, since processInternal will throw a UnsupportedOperationException due to it being a SchemaAlteringStatement. - CQL and QueryProcessor.process. This works after the system has successfully started, but due to the moment setup() is called in the Cassandra boot process, it will fail. It will throw an AssertionError in MigrationManager.java:320, because the gossiper hasn't been started yet. - Internal API's. Mimicking how other column families are set up, using CFMetadata and Schema.load. This seems to get the system in some inconsistent state where some parts do see the additional column family, but others don't. Does anyone have a recommendation for the path to follow here? What would be the recommended approach for actually setting up those column families during starting for authentication? From working on this, I also have another question. I see the default system_auth keyspace is created with a SimpleStrategy and a replication factor of 1. Is this a deliberate choice? I can imagine that if a node in a cluster dies, losing the authentication information that happens to be available on that code could be very problematic. If I'm missing any reasoning here, please let me know, but it struck me as something that could cause potential problems. I also don't see a way I could reconfigure this at the moment, and API's such as CREATE USER do seem to depend on this keyspace. -- 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: Ensure CL guarantees on digest mismatch
Updated Branches:
refs/heads/cassandra-1.2 af8a477cc - 3d787b78c
Ensure CL guarantees on digest mismatch
patch by slebresne; reviewed by jbellis for CASSANDRA-5113
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3d787b78
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3d787b78
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3d787b78
Branch: refs/heads/cassandra-1.2
Commit: 3d787b78c155773edcf29af8290ef1bea62a4206
Parents: af8a477
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon Jan 7 11:11:45 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon Jan 7 11:11:45 2013 +0100
--
CHANGES.txt|1 +
src/java/org/apache/cassandra/db/ReadCommand.java |4 +-
.../apache/cassandra/db/SliceFromReadCommand.java |6 +-
.../cassandra/service/AsyncRepairCallback.java |4 +-
.../cassandra/service/DatacenterReadCallback.java | 13 +-
.../service/RangeSliceResponseResolver.java|4 +-
.../org/apache/cassandra/service/ReadCallback.java | 26 ++-
.../apache/cassandra/service/RepairCallback.java | 86 ---
.../apache/cassandra/service/RowDataResolver.java | 182 +++
.../cassandra/service/RowDigestResolver.java |2 +-
.../cassandra/service/RowRepairResolver.java | 182 ---
.../org/apache/cassandra/service/StorageProxy.java | 16 +-
.../apache/cassandra/service/RowResolverTest.java | 20 +-
13 files changed, 247 insertions(+), 299 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d787b78/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 2ec66c9..95aad22 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -20,6 +20,7 @@
* cqlsh: Add default limit to SELECT statements (CASSANDRA-4972)
* cqlsh: fix DESCRIBE for 1.1 cfs in CQL3 (CASSANDRA-5101)
* Correctly gossip with nodes = 1.1.7 (CASSANDRA-5102)
+ * Ensure CL guarantees on digest mismatch (CASSANDRA-5113)
Merged from 1.1:
* Pig: correctly decode row keys in widerow mode (CASSANDRA-5098)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d787b78/src/java/org/apache/cassandra/db/ReadCommand.java
--
diff --git a/src/java/org/apache/cassandra/db/ReadCommand.java
b/src/java/org/apache/cassandra/db/ReadCommand.java
index f3494e5..6c364cb 100644
--- a/src/java/org/apache/cassandra/db/ReadCommand.java
+++ b/src/java/org/apache/cassandra/db/ReadCommand.java
@@ -32,7 +32,7 @@ import org.apache.cassandra.io.IVersionedSerializer;
import org.apache.cassandra.net.MessageOut;
import org.apache.cassandra.net.MessagingService;
import org.apache.cassandra.service.IReadCommand;
-import org.apache.cassandra.service.RepairCallback;
+import org.apache.cassandra.service.RowDataResolver;
import org.apache.cassandra.utils.IFilter;
@@ -94,7 +94,7 @@ public abstract class ReadCommand implements IReadCommand
}
// maybeGenerateRetryCommand is used to generate a retry for short reads
-public ReadCommand maybeGenerateRetryCommand(RepairCallback handler, Row
row)
+public ReadCommand maybeGenerateRetryCommand(RowDataResolver resolver, Row
row)
{
return null;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d787b78/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
--
diff --git a/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
b/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
index d52826b..8a08a42 100644
--- a/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
+++ b/src/java/org/apache/cassandra/db/SliceFromReadCommand.java
@@ -30,7 +30,7 @@ import org.apache.cassandra.db.filter.QueryFilter;
import org.apache.cassandra.db.filter.QueryPath;
import org.apache.cassandra.db.filter.SliceQueryFilter;
import org.apache.cassandra.io.IVersionedSerializer;
-import org.apache.cassandra.service.RepairCallback;
+import org.apache.cassandra.service.RowDataResolver;
import org.apache.cassandra.service.StorageService;
import org.apache.cassandra.thrift.ColumnParent;
import org.apache.cassandra.utils.ByteBufferUtil;
@@ -71,9 +71,9 @@ public class SliceFromReadCommand extends ReadCommand
}
@Override
-public ReadCommand maybeGenerateRetryCommand(RepairCallback handler, Row
row)
+public ReadCommand maybeGenerateRetryCommand(RowDataResolver resolver, Row
row)
{
-int maxLiveColumns = handler.getMaxLiveCount();
+int maxLiveColumns = resolver.getMaxLiveCount();
int count = filter.count;
assert maxLiveColumns = count;
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/trunk f6df04dbd - 94d76aa6c Merge branch 'cassandra-1.2' into trunk Conflicts: src/java/org/apache/cassandra/db/SliceFromReadCommand.java test/unit/org/apache/cassandra/service/RowResolverTest.java Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/94d76aa6 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/94d76aa6 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/94d76aa6 Branch: refs/heads/trunk Commit: 94d76aa6c6a63d22fead4adb2df725af75274f7f Parents: f6df04d 3d787b7 Author: Sylvain Lebresne sylv...@datastax.com Authored: Mon Jan 7 11:14:36 2013 +0100 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Mon Jan 7 11:14:36 2013 +0100 -- CHANGES.txt|1 + src/java/org/apache/cassandra/db/ReadCommand.java |4 +- .../apache/cassandra/db/SliceFromReadCommand.java |6 +- .../cassandra/service/AsyncRepairCallback.java |4 +- .../cassandra/service/DatacenterReadCallback.java | 13 +- .../service/RangeSliceResponseResolver.java|4 +- .../org/apache/cassandra/service/ReadCallback.java | 26 ++- .../apache/cassandra/service/RepairCallback.java | 86 --- .../apache/cassandra/service/RowDataResolver.java | 181 +++ .../cassandra/service/RowDigestResolver.java |2 +- .../cassandra/service/RowRepairResolver.java | 181 --- .../org/apache/cassandra/service/StorageProxy.java | 16 +- .../apache/cassandra/service/RowResolverTest.java | 14 +- 13 files changed, 243 insertions(+), 295 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/94d76aa6/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/94d76aa6/src/java/org/apache/cassandra/db/ReadCommand.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/94d76aa6/src/java/org/apache/cassandra/db/SliceFromReadCommand.java -- diff --cc src/java/org/apache/cassandra/db/SliceFromReadCommand.java index 3a05ce0,8a08a42..523646d --- a/src/java/org/apache/cassandra/db/SliceFromReadCommand.java +++ b/src/java/org/apache/cassandra/db/SliceFromReadCommand.java @@@ -31,12 -29,10 +31,12 @@@ import org.apache.cassandra.db.filter.I import org.apache.cassandra.db.filter.QueryFilter; import org.apache.cassandra.db.filter.QueryPath; import org.apache.cassandra.db.filter.SliceQueryFilter; +import org.apache.cassandra.db.marshal.AbstractType; +import org.apache.cassandra.db.marshal.CompositeType; import org.apache.cassandra.io.IVersionedSerializer; +import org.apache.cassandra.net.MessagingService; - import org.apache.cassandra.service.RepairCallback; + import org.apache.cassandra.service.RowDataResolver; import org.apache.cassandra.service.StorageService; -import org.apache.cassandra.thrift.ColumnParent; import org.apache.cassandra.utils.ByteBufferUtil; public class SliceFromReadCommand extends ReadCommand http://git-wip-us.apache.org/repos/asf/cassandra/blob/94d76aa6/src/java/org/apache/cassandra/service/RowDataResolver.java -- diff --cc src/java/org/apache/cassandra/service/RowDataResolver.java index 000,5545293..e04d7c5 mode 00,100644..100644 --- a/src/java/org/apache/cassandra/service/RowDataResolver.java +++ b/src/java/org/apache/cassandra/service/RowDataResolver.java @@@ -1,0 -1,182 +1,181 @@@ + /* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * License); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + package org.apache.cassandra.service; + + import java.io.IOException; + import java.net.InetAddress; + import java.nio.ByteBuffer; + import java.util.ArrayList; + import java.util.Collections; + import java.util.List; + + import com.google.common.collect.Iterables; + + import org.apache.cassandra.db.*; + import
[jira] [Updated] (CASSANDRA-5117) CQL 3 ALTER TABLE ... ADD causes OOB
[
https://issues.apache.org/jira/browse/CASSANDRA-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5117:
Attachment: 5117-v2.txt
I don't think the attached patch is correct (that is, it fixes the fact that
componentIndex be set to a negative value, but it's not the correct fix). The
problem is that in the case where we add a collection but we had not collection
previous, we should not do the {{component--}} at all. Attaching a v2 to fix
that.
CQL 3 ALTER TABLE ... ADD causes OOB
Key: CASSANDRA-5117
URL: https://issues.apache.org/jira/browse/CASSANDRA-5117
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Mac OSX, DS Java Driver, apache-cassandra-1.2.0-src
downloaded from project Jan 2, 2013
Reporter: Kristine Hahn
Assignee: Dave Brosius
Fix For: 1.2.1
Attachments: 5117.txt, 5117-v2.txt, OOB.txt
To reproduce:
./cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 2.3.0 | Cassandra 1.2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.35.0]
Use HELP for help.
cqlsh create keyspace music with replication = {'CLASS' :
... 'SimpleStrategy', 'replication_factor' : 3};
cqlsh use music
... ;
cqlsh:music CREATE TABLE songs (
... id uuid PRIMARY KEY,
... title text,
... album text,
... artist text,
... data blob
... );
cqlsh:music insert into songs (id, title, artist, album) values
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', 'La Grange', 'ZZ Top', 'Tres
Hombres');
cqlsh:music insert into songs (id, title, artist, album) values
('8a172618-b121-4136-bb10-f665cfc469eb', 'Moving in Stereo', 'Fu Manchu', 'We
Must Obey');
cqlsh:music insert into songs (id, title, artist, album) values
('62c36092-82a1-3a00-93d1-46196ee77204', 'Outside Woman Blues', 'Back Door
Slam', 'Roll Away');
cqlsh:music CREATE TABLE song_tags (
... id uuid,
... tag_name text,
... PRIMARY KEY (id, tag_name)
... );
cqlsh:music select * from song_tags;
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', 'blues');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('8a172618-b121-4136-bb10-f665cfc469eb', 'covers');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', '1973');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('8a172618-b121-4136-bb10-f665cfc469eb', '2007');
cqlsh:music select * from song_tags;
id | tag_name
--+--
a3e64f8f-bd44-4f28-b8d9-6938726e34d4 | 1973
a3e64f8f-bd44-4f28-b8d9-6938726e34d4 |blues
8a172618-b121-4136-bb10-f665cfc469eb | 2007
8a172618-b121-4136-bb10-f665cfc469eb | covers
cqlsh:music drop table song_tags;
cqlsh:music ALTER TABLE songs ADD tags settext;
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
[Cassandra Wiki] Trivial Update of VirtualNodes/Balance by 0track
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The VirtualNodes/Balance page has been changed by 0track: http://wiki.apache.org/cassandra/VirtualNodes/Balance?action=diffrev1=7rev2=8 Anchor(imbalance) == Imbalance == - By default, a nodes tokens are randomly generated with the expectation that an even distribution of the namespace will result. However, variations of as much as 7% have been reported on small clusters when using the `num_tokens` default of 256. + By default, nodes tokens are randomly generated with the expectation that an even distribution of the namespace will result. However, variations of as much as 7% have been reported on small clusters when using the `num_tokens` default of 256. These randomly generated tokens are MD5 sums, so entropy isn't the problem here, at least not in the sense that using a better RNG would create a more even distribution of ranges. Increasing the token count (either by increasing num_tokens, or the number of nodes) will improve this, (the more tokens, the more the distribution will even out).
[jira] [Commented] (CASSANDRA-5121) system.peers.tokens is empty after node restart
[
https://issues.apache.org/jira/browse/CASSANDRA-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13545782#comment-13545782
]
Sam Overton commented on CASSANDRA-5121:
In StorageService.handleStateNormal, when we see an endpoint come up which we
already knew about:
{noformat}
else if (endpoint.equals(currentOwner))
{
// set state back to normal, since the node may have tried to leave, but
failed and is now back up
// no need to persist, token/ip did not change
{noformat}
I think the bug is that then we call
{noformat}
SystemTable.updateTokens(endpoint, tokensToUpdateInSystemTable);
{noformat}
with an empty collection and SystemTable.updateTokens overwrites the current
entry rather than adding to it.
Fix would be
{noformat}
- // no need to persist, token/ip did not change
+ if (!isClientMode)
+tokensToUpdateInSystemTable.add(token);
{noformat}
system.peers.tokens is empty after node restart
---
Key: CASSANDRA-5121
URL: https://issues.apache.org/jira/browse/CASSANDRA-5121
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Windows 8 / Java 1.6.0_37-b06
Reporter: Pierre Chalamet
Priority: Minor
Using a 2 nodes fresh cluster (127.0.0.1 127.0.0.2) running latest 1.2, I’m
querying system.peers to get the nodes of the cluster and their respective
token. But it seems there is a problem after either node restart.
When both node starts up, querying system.peers seems ok:
{code}
127.0.0.1 select * from system.peers;
+-+--+---+---+-+-+--+---+
| data_center | host_id | peer
| rack | release_version | rpc_address | schema_version
| tokens|
+=+==+===+===+=+=+==+===+
| datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | 127.0.0.2
| rack1 | 1.2.0 | 127.0.0.2 |
59adb24e-f3cd-3e02-97f0-5b395827453f |
56713727820156410577229101238628035242|
+-+--+---+---+-+-+--+---+
{code}
But as soon as one node is restarted (let’s say 127.0.0.2), tokens column is
then empty:
{code}
127.0.0.1 select * from system.peers;
+-+--+---+---+-+-+--+-+
| data_center | host_id | peer
| rack | release_version | rpc_address | schema_version
| tokens |
+=+==+===+===+=+=+==+=+
| datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | 127.0.0.2
| rack1 | 1.2.0 | 127.0.0.2 |
59adb24e-f3cd-3e02-97f0-5b395827453f | |
+-+--+---+---+-+-+--+-+
{code}
{code}
Log server side:
DEBUG 22:08:01,608 Responding: ROWS [peer(system, peers),
org.apache.cassandra.db.marshal.InetAddressType][data_center(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][host_id(system, peers),
org.apache.cassandra.db.marshal.UUIDType][rack(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][release_version(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][rpc_address(system, peers),
org.apache.cassandra.db.marshal.InetAddressType][schema_version(system,
peers), org.apache.cassandra.db.marshal.UUIDType][tokens(system, peers),
org.apache.cassandra.db.marshal.SetType(org.apache.cassandra.db.marshal.UTF8Type)]
| 127.0.0.2 | datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | rack1 |
1.2.0 | 127.0.0.2 | 59adb24e-f3cd-3e02-97f0-5b395827453f | null
{code}
Restarting the other node (127.0.0.1) restore back the tokens column.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
[jira] [Updated] (CASSANDRA-5121) system.peers.tokens is empty after node restart
[
https://issues.apache.org/jira/browse/CASSANDRA-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5121:
Attachment: 5121.txt
I agree on Sam's analysis but I would suggest the slightly different patch
attached, because I think the intend was that if tokensToUpdateInSystemTable is
empty, we don't update anything. In particular, in the case where we are
relocating, I don't think we want remove the tokens from the system table
either (and in the case where there is a token conflict I think the initial
intent was also to leave things as they are, even though in that case maybe
actually removing the token is not a bad idea?).
system.peers.tokens is empty after node restart
---
Key: CASSANDRA-5121
URL: https://issues.apache.org/jira/browse/CASSANDRA-5121
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Windows 8 / Java 1.6.0_37-b06
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 5121.txt
Using a 2 nodes fresh cluster (127.0.0.1 127.0.0.2) running latest 1.2, I’m
querying system.peers to get the nodes of the cluster and their respective
token. But it seems there is a problem after either node restart.
When both node starts up, querying system.peers seems ok:
{code}
127.0.0.1 select * from system.peers;
+-+--+---+---+-+-+--+---+
| data_center | host_id | peer
| rack | release_version | rpc_address | schema_version
| tokens|
+=+==+===+===+=+=+==+===+
| datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | 127.0.0.2
| rack1 | 1.2.0 | 127.0.0.2 |
59adb24e-f3cd-3e02-97f0-5b395827453f |
56713727820156410577229101238628035242|
+-+--+---+---+-+-+--+---+
{code}
But as soon as one node is restarted (let’s say 127.0.0.2), tokens column is
then empty:
{code}
127.0.0.1 select * from system.peers;
+-+--+---+---+-+-+--+-+
| data_center | host_id | peer
| rack | release_version | rpc_address | schema_version
| tokens |
+=+==+===+===+=+=+==+=+
| datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | 127.0.0.2
| rack1 | 1.2.0 | 127.0.0.2 |
59adb24e-f3cd-3e02-97f0-5b395827453f | |
+-+--+---+---+-+-+--+-+
{code}
{code}
Log server side:
DEBUG 22:08:01,608 Responding: ROWS [peer(system, peers),
org.apache.cassandra.db.marshal.InetAddressType][data_center(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][host_id(system, peers),
org.apache.cassandra.db.marshal.UUIDType][rack(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][release_version(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][rpc_address(system, peers),
org.apache.cassandra.db.marshal.InetAddressType][schema_version(system,
peers), org.apache.cassandra.db.marshal.UUIDType][tokens(system, peers),
org.apache.cassandra.db.marshal.SetType(org.apache.cassandra.db.marshal.UTF8Type)]
| 127.0.0.2 | datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | rack1 |
1.2.0 | 127.0.0.2 | 59adb24e-f3cd-3e02-97f0-5b395827453f | null
{code}
Restarting the other node (127.0.0.1) restore back the tokens column.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5122) Select on composite partition keys are not validated correctly
Sylvain Lebresne created CASSANDRA-5122:
---
Summary: Select on composite partition keys are not validated
correctly
Key: CASSANDRA-5122
URL: https://issues.apache.org/jira/browse/CASSANDRA-5122
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.1
From Kais Ahmed on the mailing list:
{noformat}
--
[cqlsh 2.3.0 | Cassandra 1.2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.35.0]
cqlsh:test CREATE TABLE foo ( a int, b text, c uuid, PRIMARY KEY
((a, b)) );
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'aze',
'4d481800-4c5f-11e1-82e0-3f484de45426');
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'ert',
'693f5800-8acb-11e3-82e0-3f484de45426');
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'opl',
'd4815800-2d8d-11e0-82e0-3f484de45426');
-
cqlsh:test SELECT * FROM foo;
a | b | c
---+-+--
1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426
1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426
1 | aze | 4d481800-4c5f-11e1-82e0-3f484de45426
-
cqlsh:test SELECT * FROM foo where a=1;
a | b | c
---+-+--
1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426
1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426
{noformat}
The last request should be invalid (since we don't have a good way to do it, at
least not with a random partitioner).
--
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-5122) Select on composite partition keys are not validated correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5122:
Attachment: 5122.txt
Select on composite partition keys are not validated correctly
--
Key: CASSANDRA-5122
URL: https://issues.apache.org/jira/browse/CASSANDRA-5122
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.1
Attachments: 5122.txt
From Kais Ahmed on the mailing list:
{noformat}
--
[cqlsh 2.3.0 | Cassandra 1.2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.35.0]
cqlsh:test CREATE TABLE foo ( a int, b text, c uuid, PRIMARY KEY
((a, b)) );
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'aze',
'4d481800-4c5f-11e1-82e0-3f484de45426');
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'ert',
'693f5800-8acb-11e3-82e0-3f484de45426');
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'opl',
'd4815800-2d8d-11e0-82e0-3f484de45426');
-
cqlsh:test SELECT * FROM foo;
a | b | c
---+-+--
1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426
1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426
1 | aze | 4d481800-4c5f-11e1-82e0-3f484de45426
-
cqlsh:test SELECT * FROM foo where a=1;
a | b | c
---+-+--
1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426
1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426
{noformat}
The last request should be invalid (since we don't have a good way to do it,
at least not with a random partitioner).
--
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/3] git commit: disallow bloom filter false positive chance of 0 patch by jbellis and brandonwilliams for CASSANDRA-5013
disallow bloom filter false positive chance of 0
patch by jbellis and brandonwilliams for CASSANDRA-5013
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/dac6048c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/dac6048c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/dac6048c
Branch: refs/heads/trunk
Commit: dac6048c50a8dff0b4522c669c2f7115876483eb
Parents: 3d787b7
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jan 4 12:16:33 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jan 7 09:36:41 2013 -0600
--
CHANGES.txt|1 +
.../org/apache/cassandra/config/CFMetaData.java|6 +-
.../apache/cassandra/io/sstable/SSTableWriter.java | 10 +-
3 files changed, 7 insertions(+), 10 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/dac6048c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 95aad22..78643d5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.2.1
+ * disallow bloom filter false positive chance of 0 (CASSANDRA-5013)
* add threadpool size adjustment methods to JMXEnabledThreadPoolExecutor and
CompactionManagerMBean (CASSANDRA-5044)
* Improve handling a changing target throttle rate mid-compaction
(CASSANDRA-5087)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/dac6048c/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 3a2e2b6..5f6c1fe 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -536,7 +536,8 @@ public final class CFMetaData
public double getBloomFilterFpChance()
{
-return bloomFilterFpChance == null
+// we disallow bFFPC==null starting in 1.2.1 but tolerated it before
that
+return (bloomFilterFpChance == null || bloomFilterFpChance == 0)
? compactionStrategyClass == LeveledCompactionStrategy.class ?
0.1 : 0.01
: bloomFilterFpChance;
}
@@ -1125,6 +1126,9 @@ public final class CFMetaData
validateCompactionThresholds();
+if (bloomFilterFpChance != null bloomFilterFpChance == 0)
+throw new ConfigurationException(Zero false positives is
impossible; bloom filter false positive chance bffpc must be 0 bffpc = 1);
+
return this;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/dac6048c/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
b/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
index a3a8fe9..f578064 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
@@ -442,15 +442,7 @@ public class SSTableWriter extends SSTable
!DatabaseDescriptor.populateIOCacheOnFlush());
builder =
SegmentedFile.getBuilder(DatabaseDescriptor.getIndexAccessMode());
summary = new IndexSummary(keyCount);
-
-double fpChance = metadata.getBloomFilterFpChance();
-if (fpChance == 0)
-{
-// paranoia -- we've had bugs in the thrift - avro - CfDef
dance before, let's not let that break things
-logger.error(Bloom filter FP chance of zero isn't supposed to
happen);
-fpChance = 0.01;
-}
-bf = FilterFactory.getFilter(keyCount, fpChance, true);
+bf = FilterFactory.getFilter(keyCount,
metadata.getBloomFilterFpChance(), true);
}
public void append(DecoratedKey key, RowIndexEntry indexEntry)
[1/3] git commit: disallow bloom filter false positive chance of 0 patch by jbellis and brandonwilliams for CASSANDRA-5013
disallow bloom filter false positive chance of 0
patch by jbellis and brandonwilliams for CASSANDRA-5013
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/dac6048c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/dac6048c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/dac6048c
Branch: refs/heads/cassandra-1.2
Commit: dac6048c50a8dff0b4522c669c2f7115876483eb
Parents: 3d787b7
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jan 4 12:16:33 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jan 7 09:36:41 2013 -0600
--
CHANGES.txt|1 +
.../org/apache/cassandra/config/CFMetaData.java|6 +-
.../apache/cassandra/io/sstable/SSTableWriter.java | 10 +-
3 files changed, 7 insertions(+), 10 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/dac6048c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 95aad22..78643d5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.2.1
+ * disallow bloom filter false positive chance of 0 (CASSANDRA-5013)
* add threadpool size adjustment methods to JMXEnabledThreadPoolExecutor and
CompactionManagerMBean (CASSANDRA-5044)
* Improve handling a changing target throttle rate mid-compaction
(CASSANDRA-5087)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/dac6048c/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 3a2e2b6..5f6c1fe 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -536,7 +536,8 @@ public final class CFMetaData
public double getBloomFilterFpChance()
{
-return bloomFilterFpChance == null
+// we disallow bFFPC==null starting in 1.2.1 but tolerated it before
that
+return (bloomFilterFpChance == null || bloomFilterFpChance == 0)
? compactionStrategyClass == LeveledCompactionStrategy.class ?
0.1 : 0.01
: bloomFilterFpChance;
}
@@ -1125,6 +1126,9 @@ public final class CFMetaData
validateCompactionThresholds();
+if (bloomFilterFpChance != null bloomFilterFpChance == 0)
+throw new ConfigurationException(Zero false positives is
impossible; bloom filter false positive chance bffpc must be 0 bffpc = 1);
+
return this;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/dac6048c/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
b/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
index a3a8fe9..f578064 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
@@ -442,15 +442,7 @@ public class SSTableWriter extends SSTable
!DatabaseDescriptor.populateIOCacheOnFlush());
builder =
SegmentedFile.getBuilder(DatabaseDescriptor.getIndexAccessMode());
summary = new IndexSummary(keyCount);
-
-double fpChance = metadata.getBloomFilterFpChance();
-if (fpChance == 0)
-{
-// paranoia -- we've had bugs in the thrift - avro - CfDef
dance before, let's not let that break things
-logger.error(Bloom filter FP chance of zero isn't supposed to
happen);
-fpChance = 0.01;
-}
-bf = FilterFactory.getFilter(keyCount, fpChance, true);
+bf = FilterFactory.getFilter(keyCount,
metadata.getBloomFilterFpChance(), true);
}
public void append(DecoratedKey key, RowIndexEntry indexEntry)
[3/3] git commit: merge from 1.2
Updated Branches:
refs/heads/cassandra-1.2 3d787b78c - dac6048c5
refs/heads/trunk 94d76aa6c - af404f211
merge from 1.2
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/af404f21
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/af404f21
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/af404f21
Branch: refs/heads/trunk
Commit: af404f2116ae15dc0aba5676a337321e15d47dfb
Parents: 94d76aa dac6048
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jan 7 09:40:17 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jan 7 09:40:17 2013 -0600
--
CHANGES.txt|1 +
.../org/apache/cassandra/config/CFMetaData.java|6 +-
.../apache/cassandra/io/sstable/SSTableWriter.java | 10 +-
3 files changed, 7 insertions(+), 10 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/af404f21/CHANGES.txt
--
diff --cc CHANGES.txt
index f290829,78643d5..c0e403f
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,11 -1,5 +1,12 @@@
+1.3
+ * make index_interval configurable per columnfamily (CASSANDRA-3961)
+ * add default_tim_to_live (CASSANDRA-3974)
+ * add memtable_flush_period_in_ms (CASSANDRA-4237)
+ * replace supercolumns internally by composites (CASSANDRA-3237)
+
+
1.2.1
+ * disallow bloom filter false positive chance of 0 (CASSANDRA-5013)
* add threadpool size adjustment methods to JMXEnabledThreadPoolExecutor and
CompactionManagerMBean (CASSANDRA-5044)
* Improve handling a changing target throttle rate mid-compaction
(CASSANDRA-5087)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/af404f21/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --cc src/java/org/apache/cassandra/config/CFMetaData.java
index 359bbb3,5f6c1fe..c1fd8e9
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@@ -555,9 -529,15 +555,10 @@@ public final class CFMetaDat
return Collections.unmodifiableMap(column_metadata);
}
-public AbstractType? getComparatorFor(ByteBuffer superColumnName)
-{
-return superColumnName == null ? comparator : subcolumnComparator;
-}
-
public double getBloomFilterFpChance()
{
- return bloomFilterFpChance == null
+ // we disallow bFFPC==null starting in 1.2.1 but tolerated it before
that
+ return (bloomFilterFpChance == null || bloomFilterFpChance == 0)
? compactionStrategyClass == LeveledCompactionStrategy.class ?
0.1 : 0.01
: bloomFilterFpChance;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/af404f21/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
--
diff --cc src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
index 10af96d,f578064..279599e
--- a/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
@@@ -426,16 -441,8 +426,8 @@@ public class SSTableWriter extends SSTa
indexFile = SequentialWriter.open(new
File(descriptor.filenameFor(SSTable.COMPONENT_INDEX)),
!DatabaseDescriptor.populateIOCacheOnFlush());
builder =
SegmentedFile.getBuilder(DatabaseDescriptor.getIndexAccessMode());
-summary = new IndexSummary(keyCount);
+summary = new IndexSummary(keyCount, metadata.getIndexInterval());
-
- double fpChance = metadata.getBloomFilterFpChance();
- if (fpChance == 0)
- {
- // paranoia -- we've had bugs in the thrift - avro -
CfDef dance before, let's not let that break things
- logger.error(Bloom filter FP chance of zero isn't supposed
to happen);
- fpChance = 0.01;
- }
- bf = FilterFactory.getFilter(keyCount, fpChance, true);
+ bf = FilterFactory.getFilter(keyCount,
metadata.getBloomFilterFpChance(), true);
}
public void append(DecoratedKey key, RowIndexEntry indexEntry)
[jira] [Commented] (CASSANDRA-5122) Select on composite partition keys are not validated correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13545968#comment-13545968
]
Jonathan Ellis commented on CASSANDRA-5122:
---
+1
Select on composite partition keys are not validated correctly
--
Key: CASSANDRA-5122
URL: https://issues.apache.org/jira/browse/CASSANDRA-5122
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.1
Attachments: 5122.txt
From Kais Ahmed on the mailing list:
{noformat}
--
[cqlsh 2.3.0 | Cassandra 1.2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.35.0]
cqlsh:test CREATE TABLE foo ( a int, b text, c uuid, PRIMARY KEY
((a, b)) );
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'aze',
'4d481800-4c5f-11e1-82e0-3f484de45426');
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'ert',
'693f5800-8acb-11e3-82e0-3f484de45426');
cqlsh:test INSERT INTO foo (a, b , c ) VALUES ( 1 , 'opl',
'd4815800-2d8d-11e0-82e0-3f484de45426');
-
cqlsh:test SELECT * FROM foo;
a | b | c
---+-+--
1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426
1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426
1 | aze | 4d481800-4c5f-11e1-82e0-3f484de45426
-
cqlsh:test SELECT * FROM foo where a=1;
a | b | c
---+-+--
1 | ert | 693f5800-8acb-11e3-82e0-3f484de45426
1 | opl | d4815800-2d8d-11e0-82e0-3f484de45426
{noformat}
The last request should be invalid (since we don't have a good way to do it,
at least not with a random partitioner).
--
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: Validat correctly selects on composite partition key
Updated Branches:
refs/heads/cassandra-1.2 dac6048c5 - 0d6131c40
Validat correctly selects on composite partition key
patch by slebresne; reviewed by jbellis for CASSANDRA-5122
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0d6131c4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0d6131c4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0d6131c4
Branch: refs/heads/cassandra-1.2
Commit: 0d6131c400cc296796f132f802f4156408e84ace
Parents: dac6048
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon Jan 7 17:22:49 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon Jan 7 17:22:49 2013 +0100
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/SelectStatement.java | 18 ++-
2 files changed, 13 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d6131c4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 78643d5..e038599 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -22,6 +22,7 @@
* cqlsh: fix DESCRIBE for 1.1 cfs in CQL3 (CASSANDRA-5101)
* Correctly gossip with nodes = 1.1.7 (CASSANDRA-5102)
* Ensure CL guarantees on digest mismatch (CASSANDRA-5113)
+ * Validate correctly selects on composite partition key (CASSANDRA-5122)
Merged from 1.1:
* Pig: correctly decode row keys in widerow mode (CASSANDRA-5098)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d6131c4/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 b41659c..e88784c 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -271,10 +271,10 @@ public class SelectStatement implements CQLStatement
RowPosition finishKey = RowPosition.forKey(finishKeyBytes, p);
if (startKey.compareTo(finishKey) 0 !finishKey.isMinimum(p))
{
-if (p instanceof RandomPartitioner)
-throw new InvalidRequestException(Start key sorts after
end key. This is not allowed; you probably should not specify end key at all,
under RandomPartitioner);
-else
+if (p.preservesOrder())
throw new InvalidRequestException(Start key must sort
before (or equal to) finish key in your partitioner!);
+else
+throw new InvalidRequestException(Start key sorts after
end key. This is not allowed; you probably should not specify end key at all
under random partitioner);
}
if (includeKeyBound(Bound.START))
{
@@ -991,6 +991,7 @@ public class SelectStatement implements CQLStatement
CFDefinition cfDef = cfm.getCfDef();
SelectStatement stmt = new SelectStatement(cfDef,
getBoundsTerms(), parameters);
CFDefinition.Name[] names = new
CFDefinition.Name[getBoundsTerms()];
+IPartitioner partitioner = StorageService.getPartitioner();
// Select clause
if (parameters.isCount)
@@ -1044,8 +1045,6 @@ public class SelectStatement implements CQLStatement
switch (name.kind)
{
case KEY_ALIAS:
-if (rel.operator() != Relation.Type.EQ
rel.operator() != Relation.Type.IN !rel.onToken
!StorageService.getPartitioner().preservesOrder())
-throw new InvalidRequestException(Only EQ and IN
relation are supported on the partition key for RandomPartitioner (unless you
use the token() function));
stmt.keyRestrictions[name.position] =
updateRestriction(name, stmt.keyRestrictions[name.position], rel);
break;
case COLUMN_ALIAS:
@@ -,7 +1110,11 @@ public class SelectStatement implements CQLStatement
if (restriction == null)
{
if (stmt.onToken)
-throw new InvalidRequestException(String.format(The
token() function must be applied to all partition key components or none of
them));
+throw new InvalidRequestException(The token()
function must be applied to all partition key components or none of them);
+
+// Under a non order perserving partitioner, the only time
not restricting a key part is allowed is if none are restricted
+if
[jira] [Created] (CASSANDRA-5123) Multiget Supercolumns Sometimes Missing Results
Tyler Hobbs created CASSANDRA-5123:
--
Summary: Multiget Supercolumns Sometimes Missing Results
Key: CASSANDRA-5123
URL: https://issues.apache.org/jira/browse/CASSANDRA-5123
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Priority: Minor
Starting approximately with commit c2812f3 (the January 3rd nightly build by
DataStax Jenkins, #669), a few of the pycassa unit tests related to
multigetting a particular supercolumn started failing periodically. The
nightly build is against Cassandra trunk.
You can reproduce with the pycassa unit tests fairly easily:
{noformat}
nosetests
tests/test_columnfamily.py:TestSuperColumnFamily.test_multiget_supercolumn
{noformat}
It should fail within a few runs.
It looks like one of the requested keys isn't being returned at all.
--
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-5099) Since 1.1, get_count sometimes returns value smaller than actual column count
[
https://issues.apache.org/jira/browse/CASSANDRA-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5099:
--
Reviewer: thobbs
Priority: Major (was: Minor)
Fix Version/s: 1.1.9
Assignee: Yuki Morishita
Since 1.1, get_count sometimes returns value smaller than actual column count
-
Key: CASSANDRA-5099
URL: https://issues.apache.org/jira/browse/CASSANDRA-5099
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.7
Reporter: Jason Harvey
Assignee: Yuki Morishita
Fix For: 1.1.9
We have a CF where rows have thousands of TTLd columns. The columns are
continually added at a regular rate, and TTL out after 15 minutes. We
continually run a 'get_count' on these keys to get a count of the number of
live columns.
Since we upgrade from 1.0 to 1.1.7, get_count regularly returns much
smaller values than are possible. For example, with roughly 15,000 columns
that have well-distributed TTLs, running a get_count 10 times will result in
1 or 2 results that are up to half the actual column count. Using a normal
'get' to count those columns always results in proper values.
For example:
(all of these counts were ran within a second or less of eachother)
{code}
[default@reddit] count AccountsActiveBySR['2qh0u'];
13665 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13665 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13666 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
3069 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13660 columns
[default@reddit] count AccountsActiveBySR['2qh0u'];
13661 columns
{code}
I should note that this issue happens much more frequently with larger (10k
columns) rows than smaller rows. It never seems to happen with rows having
fewer than 1k columns.
There are no supercolumns in use. The key names and column names are very
short, and there are no column values. The CF is LCS, and due to the TTL only
hovers around a few MB in size. GC grace is normally at zero, but the problem
is consistent with non-zero gc grace times.
It appears that there was an issue (CASSANDRA-4833) fixed in 1.1.7 regarding
get_count. Some logic was added to prevent an infinite loop case. Could that
change have resulted in this problem somehow? I can't find any other relevant
1.1 changes that might explain this issue.
--
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-5088) Major compaction IOException in 1.1.8
[ https://issues.apache.org/jira/browse/CASSANDRA-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5088: -- Reviewer: yukim (was: carlyeks) Major compaction IOException in 1.1.8 - Key: CASSANDRA-5088 URL: https://issues.apache.org/jira/browse/CASSANDRA-5088 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.8 Reporter: Karl Mueller Assignee: Jonathan Ellis Labels: compression Fix For: 1.1.9 Attachments: 5088.txt, 5088-v2.txt, 5088-v3.txt Upgraded 1.1.6 to 1.1.8. Now I'm trying to do a major compaction, and seeing this: ERROR [CompactionExecutor:129] 2012-12-22 10:33:44,217 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[CompactionExecutor:129,1,RMI Runtime] java.io.IOError: java.io.IOException: Bad file descriptor at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:65) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:195) at org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:298) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Bad file descriptor at sun.nio.ch.FileDispatcher.preClose0(Native Method) at sun.nio.ch.FileDispatcher.preClose(FileDispatcher.java:59) at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:96) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97) at java.io.FileInputStream.close(FileInputStream.java:258) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.close(CompressedRandomAccessReader.java:131) at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:121) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97) at java.io.RandomAccessFile.close(RandomAccessFile.java:541) at org.apache.cassandra.io.util.RandomAccessReader.close(RandomAccessReader.java:224) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.close(CompressedRandomAccessReader.java:130) at org.apache.cassandra.io.sstable.SSTableScanner.close(SSTableScanner.java:89) at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:61) ... 9 more -- 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-5088) Major compaction IOException in 1.1.8
[ https://issues.apache.org/jira/browse/CASSANDRA-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5088: -- Reviewer: iamaleksey (was: yukim) Major compaction IOException in 1.1.8 - Key: CASSANDRA-5088 URL: https://issues.apache.org/jira/browse/CASSANDRA-5088 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.8 Reporter: Karl Mueller Assignee: Jonathan Ellis Labels: compression Fix For: 1.1.9 Attachments: 5088.txt, 5088-v2.txt, 5088-v3.txt Upgraded 1.1.6 to 1.1.8. Now I'm trying to do a major compaction, and seeing this: ERROR [CompactionExecutor:129] 2012-12-22 10:33:44,217 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[CompactionExecutor:129,1,RMI Runtime] java.io.IOError: java.io.IOException: Bad file descriptor at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:65) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:195) at org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:298) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Bad file descriptor at sun.nio.ch.FileDispatcher.preClose0(Native Method) at sun.nio.ch.FileDispatcher.preClose(FileDispatcher.java:59) at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:96) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97) at java.io.FileInputStream.close(FileInputStream.java:258) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.close(CompressedRandomAccessReader.java:131) at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:121) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97) at java.io.RandomAccessFile.close(RandomAccessFile.java:541) at org.apache.cassandra.io.util.RandomAccessReader.close(RandomAccessReader.java:224) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.close(CompressedRandomAccessReader.java:130) at org.apache.cassandra.io.sstable.SSTableScanner.close(SSTableScanner.java:89) at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:61) ... 9 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of RosieMulli by RosieMulli
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The RosieMulli page has been changed by RosieMulli: http://wiki.apache.org/cassandra/RosieMulli New page: There is nothing to tell about myself really.BRBRFinally a member of apache.org.BRI just hope Im useful in some way here.BRBRAlso visit my blog: [[http://haribhakt.com|lord krishna history, krishna blessings for all, lord krishna historical proof, become hindu]]
[jira] [Updated] (CASSANDRA-5089) get_range_slices is broken
[ https://issues.apache.org/jira/browse/CASSANDRA-5089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Pesternikov updated CASSANDRA-5089: --- Attachment: 5089unittest.diff test attached. Please note that you need -ea JVM command line flag to reveal the problem, without -ea it works fine. I think the problem is in Bounds.java:45 assert statement: assert left.compareTo(right) = 0 || right.isMinimum(partitioner) : [ + left + , + right + ]; Why left is even compared to right? Why bounds may not wrap as it stated in the comment? Logically, less and more are irrelevant to iterator position as we are talking about RING. get_range_slices is broken -- Key: CASSANDRA-5089 URL: https://issues.apache.org/jira/browse/CASSANDRA-5089 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.7 Reporter: Aleksey Pesternikov Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.2.1 Attachments: 5089.txt, 5089unittest.diff, 5089-v2.txt get_range_slices times out, java log has the following exception: ERROR [Thrift:1] 2012-12-22 08:14:30,120 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[Thrift:1,5,main] java.lang.AssertionError: [DecoratedKey(28555413689034504124051437792156504, 643431386665303564363166396232363532393734333765336265616162),max(0)] at org.apache.cassandra.dht.Bounds.init(Bounds.java:45) at org.apache.cassandra.dht.Bounds.init(Bounds.java:38) at org.apache.cassandra.thrift.CassandraServer.get_range_slices(CassandraServer.java:698) at org.apache.cassandra.thrift.Cassandra$Processor$get_range_slices.getResult(Cassandra.java:3083) at org.apache.cassandra.thrift.Cassandra$Processor$get_range_slices.getResult(Cassandra.java:3071) 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:186) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) We see it every time on the SECOND get_range_slices call when we clear start_token and set start_key in the key range. We noticed this in 1.1.7 first, 1.1.8 still affected. 1.1.6 is fine. Please contact me if you need more information. -- 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-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546035#comment-13546035 ] Srdjan Mitrovic commented on CASSANDRA-4775: Don't atomic batched have potential for a retry mechanism? Now that CASSANDRA-4285 has been resolved can't you use Atomic batches to have idempotent counters? If we put in the same batch both incr and adding a wide row cell we could later see if we have a cell and not execute that batch again. I apologize if there is something fundamentally wrong in my understanding of how cassandra batches work so in that case please delete my message so that it doesn't derail the issue. Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Labels: counters Fix For: 2.0 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- 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-5120) Add support for SSL sockets to use client certificate authentication.
[ https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-5120: Reviewer: vijay2...@yahoo.com Add support for SSL sockets to use client certificate authentication. - Key: CASSANDRA-5120 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.0 Reporter: Steven Franklin Priority: Minor Fix For: 1.2.0 Attachments: trunk-5120.txt Add an option to EncryptionOptions to require client certication authentication. -- 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-5120) Add support for SSL sockets to use client certificate authentication.
[ https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546064#comment-13546064 ] Aleksey Yeschenko commented on CASSANDRA-5120: -- Not all thfit ssl socket implementations support this. Python's TSSLSocket, for example. Add support for SSL sockets to use client certificate authentication. - Key: CASSANDRA-5120 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.0 Reporter: Steven Franklin Priority: Minor Fix For: 1.2.0 Attachments: trunk-5120.txt Add an option to EncryptionOptions to require client certication authentication. -- 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-5120) Add support for SSL sockets to use client certificate authentication.
[ https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546064#comment-13546064 ] Aleksey Yeschenko edited comment on CASSANDRA-5120 at 1/7/13 5:31 PM: -- Not all Thrift ssl socket implementations support this. Python's TSSLSocket doesn't, for example. was (Author: iamaleksey): Not all thfit ssl socket implementations support this. Python's TSSLSocket, for example. Add support for SSL sockets to use client certificate authentication. - Key: CASSANDRA-5120 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.0 Reporter: Steven Franklin Priority: Minor Fix For: 1.2.0 Attachments: trunk-5120.txt Add an option to EncryptionOptions to require client certication authentication. -- 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-5088) Major compaction IOException in 1.1.8
[ https://issues.apache.org/jira/browse/CASSANDRA-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546075#comment-13546075 ] Aleksey Yeschenko commented on CASSANDRA-5088: -- +1 Major compaction IOException in 1.1.8 - Key: CASSANDRA-5088 URL: https://issues.apache.org/jira/browse/CASSANDRA-5088 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.8 Reporter: Karl Mueller Assignee: Jonathan Ellis Labels: compression Fix For: 1.1.9 Attachments: 5088.txt, 5088-v2.txt, 5088-v3.txt Upgraded 1.1.6 to 1.1.8. Now I'm trying to do a major compaction, and seeing this: ERROR [CompactionExecutor:129] 2012-12-22 10:33:44,217 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[CompactionExecutor:129,1,RMI Runtime] java.io.IOError: java.io.IOException: Bad file descriptor at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:65) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:195) at org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:298) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Bad file descriptor at sun.nio.ch.FileDispatcher.preClose0(Native Method) at sun.nio.ch.FileDispatcher.preClose(FileDispatcher.java:59) at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:96) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97) at java.io.FileInputStream.close(FileInputStream.java:258) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.close(CompressedRandomAccessReader.java:131) at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:121) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97) at java.io.RandomAccessFile.close(RandomAccessFile.java:541) at org.apache.cassandra.io.util.RandomAccessReader.close(RandomAccessReader.java:224) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.close(CompressedRandomAccessReader.java:130) at org.apache.cassandra.io.sstable.SSTableScanner.close(SSTableScanner.java:89) at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:61) ... 9 more -- 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-4914) Aggregate functions in CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4914: -- Fix Version/s: (was: 1.2.1) 2.0 Aggregate functions in CQL -- Key: CASSANDRA-4914 URL: https://issues.apache.org/jira/browse/CASSANDRA-4914 Project: Cassandra Issue Type: Bug Reporter: Vijay Assignee: Vijay Fix For: 2.0 The requirement is to do aggregation of data in Cassandra (Wide row of column values of int, double, float etc). With some basic agree gate functions like AVG, SUM, Mean, Min, Max, etc (for the columns within a row). Example: SELECT * FROM emp WHERE empID IN (130) ORDER BY deptID DESC; empid | deptid | first_name | last_name | salary ---+++---+ 130 | 3 | joe| doe | 10.1 130 | 2 | joe| doe |100 130 | 1 | joe| doe | 1e+03 SELECT sum(salary), empid FROM emp WHERE empID IN (130); sum(salary) | empid -+ 1110.1| 130 -- 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-4795) replication, compaction, compression? options are not validated
[ https://issues.apache.org/jira/browse/CASSANDRA-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4795: -- Reviewer: slebresne replication, compaction, compression? options are not validated --- Key: CASSANDRA-4795 URL: https://issues.apache.org/jira/browse/CASSANDRA-4795 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: Brandon Williams Assignee: Dave Brosius Priority: Minor Fix For: 1.2.1 Attachments: 4795.replication_strategy.txt When creating a keyspace and specifying strategy options, you can pass any k/v pair you like. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4445) balance utility for vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4445: -- Priority: Minor (was: Major) balance utility for vnodes -- Key: CASSANDRA-4445 URL: https://issues.apache.org/jira/browse/CASSANDRA-4445 Project: Cassandra Issue Type: Sub-task Components: Core Affects Versions: 1.2.0 beta 1 Reporter: Brandon Williams Priority: Minor Fix For: 1.2.1 We need a 'balance' utility similar to move without a token, in the cases where entropy is not your friend and gives you an unbalanced cluster (I've seen up to a 7% discrepancy myself) -- 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-5112) Setting up authentication tables with custom authentication plugin
[ https://issues.apache.org/jira/browse/CASSANDRA-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546094#comment-13546094 ] Aleksey Yeschenko commented on CASSANDRA-5112: -- bq. Having that onJoined / onReady and onBootstrapped would be great. Would be really nice if those could be used to properly setup these tables for authentication. One callback, onBootstrapComplete. As for the second issue, I think we could change the way that keyspace/table are created and allow altering the system_auth keyspace. So it would still be SimpleStrategy with RF=1 by default - so support single-node clusters, but you'd be able to change strategy and RF. Not sure if it's a good idea yet, just an idea. Setting up authentication tables with custom authentication plugin -- Key: CASSANDRA-5112 URL: https://issues.apache.org/jira/browse/CASSANDRA-5112 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.2.0 Reporter: Dirkjan Bussink Priority: Minor I'm working on updating https://github.com/nedap/cassandra-auth with the new authentication API's in Cassandra 1.2.0. I have stumbled on an issue and I'm not really sure how to handle it. For the authentication I want to setup additional column families for the passwords and permissions. As recommended in the documentation of IAuthorizer, I'm trying to create these tables during setup(): Setup is called once upon system startup to initialize the IAuthorizer. For example, use this method to create any required keyspaces/column families.. The problem is that doing this seems to be a lot harder than I would think, or I'm perhaps missing something obvious. I've tried various attempts, but all have failed: - CQL and QueryProcessor.processInternal to setup additional column families. This fails, since processInternal will throw a UnsupportedOperationException due to it being a SchemaAlteringStatement. - CQL and QueryProcessor.process. This works after the system has successfully started, but due to the moment setup() is called in the Cassandra boot process, it will fail. It will throw an AssertionError in MigrationManager.java:320, because the gossiper hasn't been started yet. - Internal API's. Mimicking how other column families are set up, using CFMetadata and Schema.load. This seems to get the system in some inconsistent state where some parts do see the additional column family, but others don't. Does anyone have a recommendation for the path to follow here? What would be the recommended approach for actually setting up those column families during starting for authentication? From working on this, I also have another question. I see the default system_auth keyspace is created with a SimpleStrategy and a replication factor of 1. Is this a deliberate choice? I can imagine that if a node in a cluster dies, losing the authentication information that happens to be available on that code could be very problematic. If I'm missing any reasoning here, please let me know, but it struck me as something that could cause potential problems. I also don't see a way I could reconfigure this at the moment, and API's such as CREATE USER do seem to depend on this keyspace. -- 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-4265) Limit total open connections (HSHA server)
[ https://issues.apache.org/jira/browse/CASSANDRA-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4265: -- Fix Version/s: (was: 1.2.1) Limit total open connections (HSHA server) -- Key: CASSANDRA-4265 URL: https://issues.apache.org/jira/browse/CASSANDRA-4265 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 0.8.3 Environment: Ubuntu 10.04, 64bit, Oracle 1.6.0_32 and OpenJDK 1.6.0_20 Connecting with Hector 1.1-0 Reporter: James Kearney Assignee: Pavel Yaskevich Priority: Minor Labels: thrift Attachments: 0001-Limit-HSHA-open-connections.patch When using the rpc_server_type: hsha there seems to be no limit on the number of open connections that cassandra accepts / on the total memory consumed by them. This can lead to OOM errors since the HSHA server assigns a FrameBuffer per connection which is only cleaned up when the connection is closed. Setup: I wrote a simple test App using Hector which iterated through my rows retrieving data. If my Hector connection pool size was set high (in this case 100) then after a while cassandra would crash with OOM. The program was sequential so only 1 connection was actually in use at any one time but from what I can tell (and from MAT analysis) all the open connections were consuming memory as well (the FrameBuffers). At the moment all the solutions to this OOM problem seem to rest with the client. The memory consumed (on a node) is equal to [open connections]*[max request/response size] (it is max because of https://issues.apache.org/jira/browse/THRIFT-1457). This means the client needs to know how much memory each node has spare for it to use up with its connection pool. If you have a distributed set of clients then they would have to co-ordinate on how many open connections they have per node. I was just testing on a dev machine with small heap sizes (512mb-2GB) but the memory consumed as stated is based off connections and buffer size so this problem would scale for larger heap sizes. Solutions: The simplest would be a limit on the number of connections the HSHA server accepts. I only started looking into cassandra a few days ago but I tried a very simple connection limit mechanism (I will attach the patch) which seemed to work. I'm sure it can be done much cleaner than my version. This means the client or clients only have to have a hard limit on their max request size (lets say 2mb). Then for each node you know that allowing 100 connections to this node would potentially use up 200mb of memory. You can then tune this number per node. (This isn't perfect since clients can't always tell exactly how big a serialised response will be so you can go above the 200mb) A more complex solution might be able to remove the burden from the client completely. Thrift doesn't have streaming support but I assume when cassandra reads data from disk / memtables streaming can be done at that point. If this is the case then you can monitor how much memory client connections are consuming in total. If a request comes in and buffering the request / buffering the response would push cassandra over the limit then you can send an error back instead of servicing the request. -- 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-5116) upgradesstables does not upgrade all sstables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kjellman resolved CASSANDRA-5116. - Resolution: Not A Problem Assignee: Michael Kjellman (was: Yuki Morishita) appears randomly -Summary.db files for random sstables across all the nodes in the cluster got a umask of 600 instead of 644. all sstables are owned by cassandra:cassandra so i'm not sure why 600 on the -Summary.db files would lead to an issue where files are not compacted. After talking to [~yukim] for a while on this he said that the *-Summary.db files are created during the upgrade to 1.2.0 I'm also wondering if this is a manifestation of #5102 upgradesstables does not upgrade all sstables on a node --- Key: CASSANDRA-5116 URL: https://issues.apache.org/jira/browse/CASSANDRA-5116 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Ubuntu 12.04 Reporter: Michael Kjellman Assignee: Michael Kjellman upgradesstables appears to be skipping sstables randomly. finding a sstable with an mtime the upgrade time and grepping through the logs for a corresponding compaction log line, i find nothing. I have reproduced this on all of my nodes across the cluster. is performAllSSTableOperation somehow skipping sstables? -- 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-4680) Show time drift between nodes when using nodetool ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546099#comment-13546099 ] Jonathan Ellis commented on CASSANDRA-4680: --- Can we do this w/ the existing gossip information, or do we need to add a here's what time it is locally state? Show time drift between nodes when using nodetool ring -- Key: CASSANDRA-4680 URL: https://issues.apache.org/jira/browse/CASSANDRA-4680 Project: Cassandra Issue Type: New Feature Components: Core, Tools Reporter: Patrick McFadin Priority: Minor Fix For: 1.2.1 From the docs: Server clock synchronization is more important in 1.2; replicas will use a coordinator-provided timestamp to determine when a request has timed out and is thus not worth proceeding with. Using a service like NTP is strongly recommended. Since this is now more important than ever, my proposed enhancement would be to the nodetool command. When displaying the ring information, add the time drift as relative to the current host. This would be a valuable tool to aid in diagnostics. -- 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-4680) Show time drift between nodes when using nodetool ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4680: -- Component/s: Tools Show time drift between nodes when using nodetool ring -- Key: CASSANDRA-4680 URL: https://issues.apache.org/jira/browse/CASSANDRA-4680 Project: Cassandra Issue Type: New Feature Components: Core, Tools Reporter: Patrick McFadin Priority: Minor Fix For: 1.2.1 From the docs: Server clock synchronization is more important in 1.2; replicas will use a coordinator-provided timestamp to determine when a request has timed out and is thus not worth proceeding with. Using a service like NTP is strongly recommended. Since this is now more important than ever, my proposed enhancement would be to the nodetool command. When displaying the ring information, add the time drift as relative to the current host. This would be a valuable tool to aid in diagnostics. -- 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-4680) Show time drift between nodes when using nodetool ring
[ https://issues.apache.org/jira/browse/CASSANDRA-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4680: -- Issue Type: New Feature (was: Improvement) Show time drift between nodes when using nodetool ring -- Key: CASSANDRA-4680 URL: https://issues.apache.org/jira/browse/CASSANDRA-4680 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Patrick McFadin Priority: Minor Fix For: 1.2.1 From the docs: Server clock synchronization is more important in 1.2; replicas will use a coordinator-provided timestamp to determine when a request has timed out and is thus not worth proceeding with. Using a service like NTP is strongly recommended. Since this is now more important than ever, my proposed enhancement would be to the nodetool command. When displaying the ring information, add the time drift as relative to the current host. This would be a valuable tool to aid in diagnostics. -- 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-4801) inet datatype does not work with cqlsh on windows
[
https://issues.apache.org/jira/browse/CASSANDRA-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4801:
--
Reviewer: brandon.williams (was: jbellis)
Priority: Minor (was: Major)
Assignee: Aleksey Yeschenko (was: Jonathan Ellis)
inet datatype does not work with cqlsh on windows
-
Key: CASSANDRA-4801
URL: https://issues.apache.org/jira/browse/CASSANDRA-4801
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Environment: Windows 7, Python 2.7.2
Reporter: Jonathan Ellis
Assignee: Aleksey Yeschenko
Priority: Minor
Labels: cqlsh, windows
Fix For: 1.2.1
{noformat}
create keyspace foo with replication = {'class': 'SimpleStrategy',
'replication_factor': '1'};
use foo;
create table one (id int primary key, c int);
TRACING ON;
insert into one (id, c) values (1, 2);
value '\x7f\x00\x00\x01' (in col 'source') can't be deserialized as inet:
'module' object has no attribute 'inet_ntop'
{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-1337) parallelize fetching rows for low-cardinality indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1337: -- Fix Version/s: (was: 1.2.1) 2.0 parallelize fetching rows for low-cardinality indexes - Key: CASSANDRA-1337 URL: https://issues.apache.org/jira/browse/CASSANDRA-1337 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: David Alves Priority: Minor Fix For: 2.0 Attachments: 1137-bugfix.patch, 1337.patch, 1337-v4.patch, ASF.LICENSE.NOT.GRANTED--0001-CASSANDRA-1337-scan-concurrently-depending-on-num-rows.txt, CASSANDRA-1337.patch Original Estimate: 8h Remaining Estimate: 8h currently, we read the indexed rows from the first node (in partitioner order); if that does not have enough matching rows, we read the rows from the next, and so forth. we should use the statistics fom CASSANDRA-1155 to query multiple nodes in parallel, such that we have a high chance of getting enough rows w/o having to do another round of queries (but, if our estimate is incorrect, we do need to loop and do more rounds until we have enough data or we have fetched from each node). -- 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-4316) Compaction Throttle too bursty with large rows
[ https://issues.apache.org/jira/browse/CASSANDRA-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4316: -- Reviewer: jbellis Compaction Throttle too bursty with large rows -- Key: CASSANDRA-4316 URL: https://issues.apache.org/jira/browse/CASSANDRA-4316 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.0 Reporter: Wayne Lewis Assignee: Yuki Morishita Fix For: 1.2.1 Attachments: 4316-1.2.txt In org.apache.cassandra.db.compaction.CompactionIterable the check for compaction throttling occurs once every 1000 rows. In our workload this is much too large as we have many large rows (16 - 100 MB). With a 100 MB row, about 100 GB is read (and possibly written) before the compaction throttle sleeps. This causes bursts of essentially unthrottled compaction IO followed by a long sleep which yields inconsistence performance and high error rates during the bursts. We applied a workaround to check throttle every row which solved our performance and error issues: line 116 in org.apache.cassandra.db.compaction.CompactionIterable: if ((row++ % 1000) == 0) replaced with if ((row++ % 1) == 0) I think the better solution is to calculate how often throttle should be checked based on the throttle rate to apply sleeps more consistently. E.g. if 16MB/sec is the limit then check for sleep after every 16MB is read so sleeps are spaced out about every second. -- 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-4897) Allow tiered compaction define max sstable size
[ https://issues.apache.org/jira/browse/CASSANDRA-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4897: -- Priority: Minor (was: Major) Fix Version/s: (was: 1.2.1) Allow tiered compaction define max sstable size --- Key: CASSANDRA-4897 URL: https://issues.apache.org/jira/browse/CASSANDRA-4897 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Attachments: cass-maxsize1.txt, cass-maxsize2.txt Lucene is doing same thing. Correctly configured max segment size will recycle old data faster with less diskspace. -- 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-4927) E notation is not implemented for floating point numbers.
[ https://issues.apache.org/jira/browse/CASSANDRA-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4927: -- Reviewer: slebresne Assignee: Michał Michalski E notation is not implemented for floating point numbers. - Key: CASSANDRA-4927 URL: https://issues.apache.org/jira/browse/CASSANDRA-4927 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.0 beta 1 Reporter: Krzysztof Cieslinski Cognitum Assignee: Michał Michalski Priority: Minor Fix For: 1.2.1 Attachments: cassandra-4927.txt 'E' notation is not implemented for floating point numbers. Inserting some float value like -2.6034345E+38 results in: ??Bad Request: line 1:123 mismatched input 'E' expecting ')'?? -- 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-4467) insufficient space for compaction when upgrade compaction strategy from SizeTiered to Leveled
[ https://issues.apache.org/jira/browse/CASSANDRA-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4467: -- Fix Version/s: (was: 1.2.1) insufficient space for compaction when upgrade compaction strategy from SizeTiered to Leveled - Key: CASSANDRA-4467 URL: https://issues.apache.org/jira/browse/CASSANDRA-4467 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Environment: Ubuntu,Oracle Java 1.7,Cassandra 1.0.10 Reporter: Cheng Zhang Assignee: Jason Brown Priority: Minor Cassandra has two data directories as follow: cassandra-disk0 use about 500G, about 250G free space cassandra-disk1 use about 500G, about 250G free space The max data file is about 400G. When I upgrade from SizeTieredCompactionStrategy to LeveledCompactionStrategy, there is no space to do this, for the free space of every data directory is small than the largest data file. But the total free space is enough for compaction. -- 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-4750) Add jmx/nodetool methods to enable/disable hinted handoff
[ https://issues.apache.org/jira/browse/CASSANDRA-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546108#comment-13546108 ] Jonathan Ellis commented on CASSANDRA-4750: --- Alexey, can you review v3? Add jmx/nodetool methods to enable/disable hinted handoff - Key: CASSANDRA-4750 URL: https://issues.apache.org/jira/browse/CASSANDRA-4750 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Labels: hintedhandoff, nodetool Fix For: 1.2.1 Attachments: 4750-v3.txt, cassandra-1.1-4750-enable_disable_hh.txt, cassandra-1.2-4750-enable_disable_hh.txt, cassandra-1.2-enable_disable_hh-v2.txt Title says it all. -- 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-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3706: -- Fix Version/s: (was: 1.2.1) 2.0 Back up configuration files on startup -- Key: CASSANDRA-3706 URL: https://issues.apache.org/jira/browse/CASSANDRA-3706 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: lhf Fix For: 2.0 Attachments: save_configuration_2.diff, save_configuration_3.diff, save_configuration_4.diff, save_configuration_6.diff, save_configuration_7.diff, save_configuration_8.diff, save_configuration_9.diff, save_configuration.diff Snapshot can backup user data, but it's also nice to be able to have known-good configurations saved as well in case of accidental snafus or even catastrophic loss of a cluster. If we check for changes to cassandra.yaml, cassandra-env.sh, and maybe log4j-server.properties on startup, we can back them up to a columnfamily that can then be handled by normal snapshot/backup procedures. -- 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-5013) disallow bloom filter false positive chance of 0
[
https://issues.apache.org/jira/browse/CASSANDRA-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546110#comment-13546110
]
Jonathan Ellis commented on CASSANDRA-5013:
---
fixed + committed
disallow bloom filter false positive chance of 0
Key: CASSANDRA-5013
URL: https://issues.apache.org/jira/browse/CASSANDRA-5013
Project: Cassandra
Issue Type: Bug
Components: Config
Reporter: Matthew F. Dennis
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 1.2.1
Attachments: 5013.txt, 5013-v2.txt
{pre}
ERROR [CompactionExecutor:16] 2012-11-30 08:44:32,546 SSTableWriter.java
(line 414) Bloom filter FP chance of zero isn't supposed to happen
{pre}
when attempting to set it to zero, C* should either disallow the change or
should just interpret 0 as make it the default and not continually log the
above error message
--
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-5123) Multiget Supercolumns Sometimes Missing Results
[
https://issues.apache.org/jira/browse/CASSANDRA-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne reassigned CASSANDRA-5123:
---
Assignee: Sylvain Lebresne
Multiget Supercolumns Sometimes Missing Results
---
Key: CASSANDRA-5123
URL: https://issues.apache.org/jira/browse/CASSANDRA-5123
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
Priority: Minor
Starting approximately with commit c2812f3 (the January 3rd nightly build by
DataStax Jenkins, #669), a few of the pycassa unit tests related to
multigetting a particular supercolumn started failing periodically. The
nightly build is against Cassandra trunk.
You can reproduce with the pycassa unit tests fairly easily:
{noformat}
nosetests
tests/test_columnfamily.py:TestSuperColumnFamily.test_multiget_supercolumn
{noformat}
It should fail within a few runs.
It looks like one of the requested keys isn't being returned at all.
--
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-5124) cqlsh needs to run with --no-color on Windows
Jonathan Ellis created CASSANDRA-5124: - Summary: cqlsh needs to run with --no-color on Windows Key: CASSANDRA-5124 URL: https://issues.apache.org/jira/browse/CASSANDRA-5124 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Priority: Trivial Fix For: 1.2.1 The control codes used on Unix just clutter the terminal with garbage on Windows. -- 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-5125) Support indexes on composite column components
Jonathan Ellis created CASSANDRA-5125:
-
Summary: Support indexes on composite column components
Key: CASSANDRA-5125
URL: https://issues.apache.org/jira/browse/CASSANDRA-5125
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Fix For: 1.2.1
Given
{code}
CREATE TABLE foo (
a int,
b int,
c int,
PRIMARY KEY (a, b)
);
{code}
We should support {{CREATE INDEX ON foo(b)}}.
--
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-5123) Multiget Supercolumns Sometimes Missing Results
[
https://issues.apache.org/jira/browse/CASSANDRA-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5123:
--
Affects Version/s: 2.0
Fix Version/s: 2.0
Multiget Supercolumns Sometimes Missing Results
---
Key: CASSANDRA-5123
URL: https://issues.apache.org/jira/browse/CASSANDRA-5123
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 2.0
Reporter: Tyler Hobbs
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 2.0
Starting approximately with commit c2812f3 (the January 3rd nightly build by
DataStax Jenkins, #669), a few of the pycassa unit tests related to
multigetting a particular supercolumn started failing periodically. The
nightly build is against Cassandra trunk.
You can reproduce with the pycassa unit tests fairly easily:
{noformat}
nosetests
tests/test_columnfamily.py:TestSuperColumnFamily.test_multiget_supercolumn
{noformat}
It should fail within a few runs.
It looks like one of the requested keys isn't being returned at all.
--
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-5126) Upgrade version of Jackson to avoid concurrency issues with M/R tasks
Nate McCall created CASSANDRA-5126: -- Summary: Upgrade version of Jackson to avoid concurrency issues with M/R tasks Key: CASSANDRA-5126 URL: https://issues.apache.org/jira/browse/CASSANDRA-5126 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.0, 1.1.8 Reporter: Nate McCall Priority: Minor Older version of Jackson ASL has a concurrency issue. See http://jira.codehaus.org/browse/JACKSON-237 This can be triggered in some environments when running M/R tasks and the wrong version of jackson gets picked up. -- 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-5126) Upgrade version of Jackson to avoid concurrency issues with M/R tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-5126: --- Attachment: 5126.txt Updates Jackson core and asl to latest 1.9.x Upgrade version of Jackson to avoid concurrency issues with M/R tasks - Key: CASSANDRA-5126 URL: https://issues.apache.org/jira/browse/CASSANDRA-5126 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.8, 1.2.0 Reporter: Nate McCall Priority: Minor Attachments: 5126.txt Older version of Jackson ASL has a concurrency issue. See http://jira.codehaus.org/browse/JACKSON-237 This can be triggered in some environments when running M/R tasks and the wrong version of jackson gets picked up. -- 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-5116) upgradesstables does not upgrade all sstables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546228#comment-13546228 ] Michael Kjellman commented on CASSANDRA-5116: - one other note: if the Summary.db file has incorrect permissions, a restart of the node to re-read in the sstable is required before the sstable will get compacted. upgradesstables does not upgrade all sstables on a node --- Key: CASSANDRA-5116 URL: https://issues.apache.org/jira/browse/CASSANDRA-5116 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Ubuntu 12.04 Reporter: Michael Kjellman Assignee: Michael Kjellman upgradesstables appears to be skipping sstables randomly. finding a sstable with an mtime the upgrade time and grepping through the logs for a corresponding compaction log line, i find nothing. I have reproduced this on all of my nodes across the cluster. is performAllSSTableOperation somehow skipping sstables? -- 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-4767) Need some indication of node repair success or failure
[ https://issues.apache.org/jira/browse/CASSANDRA-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-4767: -- Attachment: 4767-1.2-v3.txt 4767-1.1-v3.txt Attaching v3 with the fix to only output the log it invoked. I also attached 1.2 version of the patch separately, since it includes some refactoring around repair code in StorageService. bq. Do you mean what is logged? yes. Need some indication of node repair success or failure -- Key: CASSANDRA-4767 URL: https://issues.apache.org/jira/browse/CASSANDRA-4767 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Ahmed Bashir Assignee: Yuki Morishita Priority: Minor Labels: jmx Fix For: 1.1.9 Attachments: 4767-1.1.txt, 4767-1.1-v2.txt, 4767-1.1-v3.txt, 4767-1.2-v3.txt We are currently verifying node repair status via basic log analysis. In order to automatically track the status of periodic node repair jobs, it would be better to have an indicator (through JMX perhaps). -- 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-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546035#comment-13546035 ] Srdjan Mitrovic edited comment on CASSANDRA-4775 at 1/7/13 9:27 PM: Don't atomic batches have potential for a retry mechanism? Now that CASSANDRA-4285 has been resolved can't you use Atomic batches to have idempotent counters? If we put in the same batch both incr and adding a wide row cell we could later see if we have a cell and not execute that batch again. I apologize if there is something fundamentally wrong in my understanding of how cassandra batches work so in that case please delete my message so that it doesn't derail the issue. was (Author: stecak): Don't atomic batched have potential for a retry mechanism? Now that CASSANDRA-4285 has been resolved can't you use Atomic batches to have idempotent counters? If we put in the same batch both incr and adding a wide row cell we could later see if we have a cell and not execute that batch again. I apologize if there is something fundamentally wrong in my understanding of how cassandra batches work so in that case please delete my message so that it doesn't derail the issue. Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Labels: counters Fix For: 2.0 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- 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-5126) Upgrade version of Jackson to avoid concurrency issues with M/R tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] amorton updated CASSANDRA-5126: --- Reviewer: amorton Upgrade version of Jackson to avoid concurrency issues with M/R tasks - Key: CASSANDRA-5126 URL: https://issues.apache.org/jira/browse/CASSANDRA-5126 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.8, 1.2.0 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 1.2.2 Attachments: 5126.txt Older version of Jackson ASL has a concurrency issue. See http://jira.codehaus.org/browse/JACKSON-237 This can be triggered in some environments when running M/R tasks and the wrong version of jackson gets picked up. -- 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] [Reopened] (CASSANDRA-5116) upgradesstables does not upgrade all sstables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kjellman reopened CASSANDRA-5116: - appears that once again i was wrong. this doesn't seem to be affected by permissions after all with org.apache.cassandra.db.DataTracker set to DEBUG, it looks like somehow the sstables are not getting added to the list of active sstables by DataTracker for that column family upgradesstables does not upgrade all sstables on a node --- Key: CASSANDRA-5116 URL: https://issues.apache.org/jira/browse/CASSANDRA-5116 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Ubuntu 12.04 Reporter: Michael Kjellman Assignee: Michael Kjellman upgradesstables appears to be skipping sstables randomly. finding a sstable with an mtime the upgrade time and grepping through the logs for a corresponding compaction log line, i find nothing. I have reproduced this on all of my nodes across the cluster. is performAllSSTableOperation somehow skipping sstables? -- 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-5088) Major compaction IOException in 1.1.8
[ https://issues.apache.org/jira/browse/CASSANDRA-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546379#comment-13546379 ] Jonathan Ellis commented on CASSANDRA-5088: --- committed Major compaction IOException in 1.1.8 - Key: CASSANDRA-5088 URL: https://issues.apache.org/jira/browse/CASSANDRA-5088 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.8 Reporter: Karl Mueller Assignee: Jonathan Ellis Labels: compression Fix For: 1.1.9, 1.2.1 Attachments: 5088.txt, 5088-v2.txt, 5088-v3.txt Upgraded 1.1.6 to 1.1.8. Now I'm trying to do a major compaction, and seeing this: ERROR [CompactionExecutor:129] 2012-12-22 10:33:44,217 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[CompactionExecutor:129,1,RMI Runtime] java.io.IOError: java.io.IOException: Bad file descriptor at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:65) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:195) at org.apache.cassandra.db.compaction.CompactionManager$7.runMayThrow(CompactionManager.java:298) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Bad file descriptor at sun.nio.ch.FileDispatcher.preClose0(Native Method) at sun.nio.ch.FileDispatcher.preClose(FileDispatcher.java:59) at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:96) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97) at java.io.FileInputStream.close(FileInputStream.java:258) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.close(CompressedRandomAccessReader.java:131) at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:121) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97) at java.io.RandomAccessFile.close(RandomAccessFile.java:541) at org.apache.cassandra.io.util.RandomAccessReader.close(RandomAccessReader.java:224) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.close(CompressedRandomAccessReader.java:130) at org.apache.cassandra.io.sstable.SSTableScanner.close(SSTableScanner.java:89) at org.apache.cassandra.utils.MergeIterator.close(MergeIterator.java:61) ... 9 more -- 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] [Reopened] (CASSANDRA-5106) Stock example for using pig throws InvalidRequestException(why:Start token sorts after end token)
[ https://issues.apache.org/jira/browse/CASSANDRA-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] janwar dinata reopened CASSANDRA-5106: -- Hi, Still having the same exception thrown even with PIG_PARTITIONER=org.apache.cassandra.dht.Murmur3Partitioner Stock example for using pig throws InvalidRequestException(why:Start token sorts after end token) - Key: CASSANDRA-5106 URL: https://issues.apache.org/jira/browse/CASSANDRA-5106 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.0 Environment: 1 node cluster with default cassandra.yaml Reporter: janwar dinata Assignee: Brandon Williams Priority: Minor Fix For: 1.2.1 The setup: This is from printenv HADOOP_HOME=/home/Downloads/hadoop-1.1.1 PIG_HOME=/home/Downloads/pig-0.10.0 PIG_INITIAL_ADDRESS=localhost PIG_RPC_PORT=9160 PIG_PARTITIONER=org.apache.cassandra.dht.Murmur3Partitioner This is from cassandra-cli [default@PigTest] describe cluster; Cluster Information: Snitch: org.apache.cassandra.locator.SimpleSnitch Partitioner: org.apache.cassandra.dht.Murmur3Partitioner Schema versions: b5fc9a82-fbdd-3cf5-af16-9c498c9f9a5c: [127.0.0.1] Running test_storage.pig as bin/pig_cassandra -x local test/test_storage.pig after populating the cf as cassandra-cli --host localhost --port 9160 populate-cli.txt throws 2013-01-03 02:20:47,626 [Thread-4] INFO org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigRecordReader - Current spli t being processed ColumnFamilySplit((-1, '-1728690256123413808] @[localhost.localdomain]) 2013-01-03 02:20:47,758 [Thread-4] WARN org.apache.hadoop.mapred.FileOutputCommitter - Output path is null in cleanup 2013-01-03 02:20:47,760 [Thread-4] WARN org.apache.hadoop.mapred.LocalJobRunner - job_local_0001 java.lang.RuntimeException: InvalidRequestException(why:Start token sorts after end token) at org.apache.cassandra.hadoop.ColumnFamilyRecordReader$StaticRowIterator.maybeInit(ColumnFamilyRecordReader.java:384) at org.apache.cassandra.hadoop.ColumnFamilyRecordReader$StaticRowIterator.computeNext(ColumnFamilyRecordReader.java:390) at org.apache.cassandra.hadoop.ColumnFamilyRecordReader$StaticRowIterator.computeNext(ColumnFamilyRecordReader.java:313) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.hadoop.ColumnFamilyRecordReader.nextKeyValue(ColumnFamilyRecordReader.java:184) at org.apache.cassandra.hadoop.pig.CassandraStorage.getNext(CassandraStorage.java:226) at org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigRecordReader.nextKeyValue(PigRecordReader.java:194) at org.apache.hadoop.mapred.MapTask$NewTrackingRecordReader.nextKeyValue(MapTask.java:532) at org.apache.hadoop.mapreduce.MapContext.nextKeyValue(MapContext.java:67) at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:143) at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:764) at org.apache.hadoop.mapred.MapTask.run(MapTask.java:370) at org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:212) Caused by: InvalidRequestException(why:Start token sorts after end token) at org.apache.cassandra.thrift.Cassandra$get_range_slices_result.read(Cassandra.java:12916) at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78) at org.apache.cassandra.thrift.Cassandra$Client.recv_get_range_slices(Cassandra.java:734) at org.apache.cassandra.thrift.Cassandra$Client.get_range_slices(Cassandra.java:718) at org.apache.cassandra.hadoop.ColumnFamilyRecordReader$StaticRowIterator.maybeInit(ColumnFamilyRecordReader.java:346) ... 13 more -- 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: Simplify CompressedRandomAccessReader to work around JDK FD bug patch by jbellis; reviewed by Aleksey Yeschenko and tested by Cathy Daw for CASSANDRA-5088
Updated Branches:
refs/heads/cassandra-1.1 bf1ed4089 - 55f936f1d
Simplify CompressedRandomAccessReader to work around JDK FD bug
patch by jbellis; reviewed by Aleksey Yeschenko and tested by Cathy Daw for
CASSANDRA-5088
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/55f936f1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/55f936f1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/55f936f1
Branch: refs/heads/cassandra-1.1
Commit: 55f936f1da13dc732da52735f1d1becc18546b0b
Parents: bf1ed40
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Jan 7 16:46:06 2013 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Jan 7 16:46:06 2013 -0600
--
CHANGES.txt|1 +
.../io/compress/CompressedRandomAccessReader.java | 55 ++-
2 files changed, 24 insertions(+), 32 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/55f936f1/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c1c0930..c5c3863 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.1.9
+ * Simplify CompressedRandomAccessReader to work around JDK FD bug
(CASSANDRA-5088)
* Improve handling a changing target throttle rate mid-compaction
(CASSANDRA-5087)
* fix multithreaded compaction deadlock (CASSANDRA-4492)
* fix specifying and altering crc_check_chance (CASSANDRA-5053)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/55f936f1/src/java/org/apache/cassandra/io/compress/CompressedRandomAccessReader.java
--
diff --git
a/src/java/org/apache/cassandra/io/compress/CompressedRandomAccessReader.java
b/src/java/org/apache/cassandra/io/compress/CompressedRandomAccessReader.java
index 3d3b95b..a5faff1 100644
---
a/src/java/org/apache/cassandra/io/compress/CompressedRandomAccessReader.java
+++
b/src/java/org/apache/cassandra/io/compress/CompressedRandomAccessReader.java
@@ -19,19 +19,20 @@
package org.apache.cassandra.io.compress;
import java.io.*;
-import java.nio.channels.FileChannel;
+import java.nio.ByteBuffer;
import java.util.zip.CRC32;
import java.util.zip.Checksum;
-import com.google.common.primitives.Ints;
-
import org.apache.cassandra.io.util.RandomAccessReader;
import org.apache.cassandra.utils.FBUtilities;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-// TODO refactor this to separate concept of buffer to avoid lots of read()
syscalls and compression buffer
+/**
+ * CRAR extends RAR to transparently uncompress blocks from the file into
RAR.buffer. Most of the RAR
+ * read bytes from the buffer, rebuffering when necessary machinery works
unchanged after that.
+ */
public class CompressedRandomAccessReader extends RandomAccessReader
{
private static final Logger logger =
LoggerFactory.getLogger(CompressedRandomAccessReader.class);
@@ -47,28 +48,21 @@ public class CompressedRandomAccessReader extends
RandomAccessReader
}
private final CompressionMetadata metadata;
-// used by reBuffer() to escape creating lots of temporary buffers
-private byte[] compressed;
+
+// we read the raw compressed bytes into this buffer, then move the
uncompressed ones into super.buffer.
+private ByteBuffer compressed;
// re-use single crc object
private final Checksum checksum = new CRC32();
// raw checksum bytes
-private final byte[] checksumBytes = new byte[4];
-
-private final FileInputStream source;
-private final FileChannel channel;
+private final ByteBuffer checksumBytes = ByteBuffer.wrap(new byte[4]);
public CompressedRandomAccessReader(String dataFilePath,
CompressionMetadata metadata, boolean skipIOCache) throws IOException
{
super(new File(dataFilePath), metadata.chunkLength(), skipIOCache);
this.metadata = metadata;
-compressed = new
byte[metadata.compressor().initialCompressedBufferLength(metadata.chunkLength())];
-// can't use super.read(...) methods
-// that is why we are allocating special InputStream to read data from
disk
-// from already open file descriptor
-source = new FileInputStream(getFD());
-channel = source.getChannel(); // for position manipulation
+compressed = ByteBuffer.wrap(new
byte[metadata.compressor().initialCompressedBufferLength(metadata.chunkLength())]);
}
@Override
@@ -82,13 +76,18 @@ public class CompressedRandomAccessReader extends
RandomAccessReader
if (channel.position() != chunk.offset)
channel.position(chunk.offset);
-if (compressed.length chunk.length)
-compressed = new
[jira] [Commented] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.
[ https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546417#comment-13546417 ] Vijay commented on CASSANDRA-5120: -- +1 Just for the sake of documentation: We are modifying the internode communication ssl socket and thrift server ssl socket with this patch Nit: need_client can be renamed to require_client_auth, We need to document this in yaml so that users will know what to change if they want to enable it (similar to other settings). Add support for SSL sockets to use client certificate authentication. - Key: CASSANDRA-5120 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.0 Reporter: Steven Franklin Priority: Minor Fix For: 1.2.0 Attachments: trunk-5120.txt Add an option to EncryptionOptions to require client certication authentication. -- 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-5116) upgradesstables does not upgrade all sstables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546360#comment-13546360 ] Michael Kjellman edited comment on CASSANDRA-5116 at 1/7/13 11:50 PM: -- appears that once again i was wrong. this doesn't seem to be affected by permissions after all with org.apache.cassandra.db.DataTracker set to DEBUG, it looks like somehow the sstables are not getting added to the list of active sstables by DataTracker for that column family also, i run C* with two datanodes, one for each spindle. It appears that the non-upgraded sstables are always all in one data directory while the other data directory has no non-upgraded sstables. going to resolve this again, i'm pretty sure there is a bug here somewhere. Maybe these are all sstables that should be deleted but we fail to remove for some reason? maybe someone else (hopefully not) will run into this and can reopen and debug again. was (Author: mkjellman): appears that once again i was wrong. this doesn't seem to be affected by permissions after all with org.apache.cassandra.db.DataTracker set to DEBUG, it looks like somehow the sstables are not getting added to the list of active sstables by DataTracker for that column family upgradesstables does not upgrade all sstables on a node --- Key: CASSANDRA-5116 URL: https://issues.apache.org/jira/browse/CASSANDRA-5116 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Ubuntu 12.04 Reporter: Michael Kjellman Assignee: Michael Kjellman upgradesstables appears to be skipping sstables randomly. finding a sstable with an mtime the upgrade time and grepping through the logs for a corresponding compaction log line, i find nothing. I have reproduced this on all of my nodes across the cluster. is performAllSSTableOperation somehow skipping sstables? -- 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-5116) upgradesstables does not upgrade all sstables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kjellman resolved CASSANDRA-5116. - Resolution: Not A Problem upgradesstables does not upgrade all sstables on a node --- Key: CASSANDRA-5116 URL: https://issues.apache.org/jira/browse/CASSANDRA-5116 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Ubuntu 12.04 Reporter: Michael Kjellman Assignee: Michael Kjellman upgradesstables appears to be skipping sstables randomly. finding a sstable with an mtime the upgrade time and grepping through the logs for a corresponding compaction log line, i find nothing. I have reproduced this on all of my nodes across the cluster. is performAllSSTableOperation somehow skipping sstables? -- 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-5116) upgradesstables does not upgrade all sstables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546360#comment-13546360 ] Michael Kjellman edited comment on CASSANDRA-5116 at 1/7/13 11:52 PM: -- appears that once again i was wrong. this doesn't seem to be affected by permissions after all with org.apache.cassandra.db.DataTracker set to DEBUG, it looks like somehow the sstables are not getting added to the list of active sstables by DataTracker for that column family also, i run C* with two data directories - one for each spindle. It appears that the non-upgraded sstables are always all in one data directory while the other data directory has no non-upgraded sstables. going to resolve this again, i'm pretty sure there is a bug here somewhere. Maybe these are all sstables that should have been deleted but we fail to remove them for some reason? maybe someone else (hopefully not) will run into this and can reopen and debug again. was (Author: mkjellman): appears that once again i was wrong. this doesn't seem to be affected by permissions after all with org.apache.cassandra.db.DataTracker set to DEBUG, it looks like somehow the sstables are not getting added to the list of active sstables by DataTracker for that column family also, i run C* with two datanodes, one for each spindle. It appears that the non-upgraded sstables are always all in one data directory while the other data directory has no non-upgraded sstables. going to resolve this again, i'm pretty sure there is a bug here somewhere. Maybe these are all sstables that should be deleted but we fail to remove for some reason? maybe someone else (hopefully not) will run into this and can reopen and debug again. upgradesstables does not upgrade all sstables on a node --- Key: CASSANDRA-5116 URL: https://issues.apache.org/jira/browse/CASSANDRA-5116 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Ubuntu 12.04 Reporter: Michael Kjellman Assignee: Michael Kjellman upgradesstables appears to be skipping sstables randomly. finding a sstable with an mtime the upgrade time and grepping through the logs for a corresponding compaction log line, i find nothing. I have reproduced this on all of my nodes across the cluster. is performAllSSTableOperation somehow skipping sstables? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Add support for SSL sockets to use client certificate authentication. patch by Steven Franklin and Vijay for CASSANDRA-5120
Updated Branches:
refs/heads/cassandra-1.2 0d6131c40 - 4460e2865
Add support for SSL sockets to use client certificate authentication.
patch by Steven Franklin and Vijay for CASSANDRA-5120
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4460e286
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4460e286
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4460e286
Branch: refs/heads/cassandra-1.2
Commit: 4460e2865dabb1d11950c04b5a4c9b79a12301e1
Parents: 0d6131c
Author: Vijay Parthasarathy vijay2...@gmail.com
Authored: Mon Jan 7 15:58:31 2013 -0800
Committer: Vijay Parthasarathy vijay2...@gmail.com
Committed: Mon Jan 7 15:58:31 2013 -0800
--
conf/cassandra.yaml|2 ++
.../apache/cassandra/config/EncryptionOptions.java |1 +
.../org/apache/cassandra/security/SSLFactory.java |1 +
.../cassandra/thrift/CustomTThreadPoolServer.java |1 +
.../org/apache/cassandra/transport/Server.java |3 ++-
5 files changed, 7 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4460e286/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index f2be64a..364bdd7 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -623,6 +623,7 @@ server_encryption_options:
# algorithm: SunX509
# store_type: JKS
# cipher_suites:
[TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
+# require_client_auth: false
# enable or disable client/server encryption.
client_encryption_options:
@@ -634,6 +635,7 @@ client_encryption_options:
# algorithm: SunX509
# store_type: JKS
# cipher_suites:
[TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
+# require_client_auth: false
# internode_compression controls whether traffic between nodes is
# compressed.
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4460e286/src/java/org/apache/cassandra/config/EncryptionOptions.java
--
diff --git a/src/java/org/apache/cassandra/config/EncryptionOptions.java
b/src/java/org/apache/cassandra/config/EncryptionOptions.java
index b8a5a91..fe07f68 100644
--- a/src/java/org/apache/cassandra/config/EncryptionOptions.java
+++ b/src/java/org/apache/cassandra/config/EncryptionOptions.java
@@ -27,6 +27,7 @@ public abstract class EncryptionOptions
public String protocol = TLS;
public String algorithm = SunX509;
public String store_type = JKS;
+public Boolean require_client_auth = false;
public static class ClientEncryptionOptions extends EncryptionOptions
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4460e286/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index 5e64c43..da8a3f4 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -55,6 +55,7 @@ public final class SSLFactory
serverSocket.setReuseAddress(true);
String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
+serverSocket.setNeedClientAuth(options.require_client_auth);
serverSocket.bind(new InetSocketAddress(address, port), 100);
return serverSocket;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4460e286/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index f6ab1f7..0a456b9 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -249,6 +249,7 @@ public class CustomTThreadPoolServer extends TServer
logger.info(enabling encrypted thrift connections between
client and server);
TSSLTransportParameters params = new
TSSLTransportParameters(clientEnc.protocol, clientEnc.cipher_suites);
params.setKeyStore(clientEnc.keystore,
clientEnc.keystore_password);
+params.requireClientAuth(clientEnc.require_client_auth);
TServerSocket sslServer =
TSSLTransportFactory.getServerSocket(addr.getPort(), 0, addr.getAddress(),
params);
serverTransport = new
[2/3] git commit: Add support for SSL sockets to use client certificate authentication. patch by Steven Franklin and Vijay for CASSANDRA-5120
Add support for SSL sockets to use client certificate authentication.
patch by Steven Franklin and Vijay for CASSANDRA-5120
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4460e286
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4460e286
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4460e286
Branch: refs/heads/trunk
Commit: 4460e2865dabb1d11950c04b5a4c9b79a12301e1
Parents: 0d6131c
Author: Vijay Parthasarathy vijay2...@gmail.com
Authored: Mon Jan 7 15:58:31 2013 -0800
Committer: Vijay Parthasarathy vijay2...@gmail.com
Committed: Mon Jan 7 15:58:31 2013 -0800
--
conf/cassandra.yaml|2 ++
.../apache/cassandra/config/EncryptionOptions.java |1 +
.../org/apache/cassandra/security/SSLFactory.java |1 +
.../cassandra/thrift/CustomTThreadPoolServer.java |1 +
.../org/apache/cassandra/transport/Server.java |3 ++-
5 files changed, 7 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4460e286/conf/cassandra.yaml
--
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index f2be64a..364bdd7 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -623,6 +623,7 @@ server_encryption_options:
# algorithm: SunX509
# store_type: JKS
# cipher_suites:
[TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
+# require_client_auth: false
# enable or disable client/server encryption.
client_encryption_options:
@@ -634,6 +635,7 @@ client_encryption_options:
# algorithm: SunX509
# store_type: JKS
# cipher_suites:
[TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]
+# require_client_auth: false
# internode_compression controls whether traffic between nodes is
# compressed.
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4460e286/src/java/org/apache/cassandra/config/EncryptionOptions.java
--
diff --git a/src/java/org/apache/cassandra/config/EncryptionOptions.java
b/src/java/org/apache/cassandra/config/EncryptionOptions.java
index b8a5a91..fe07f68 100644
--- a/src/java/org/apache/cassandra/config/EncryptionOptions.java
+++ b/src/java/org/apache/cassandra/config/EncryptionOptions.java
@@ -27,6 +27,7 @@ public abstract class EncryptionOptions
public String protocol = TLS;
public String algorithm = SunX509;
public String store_type = JKS;
+public Boolean require_client_auth = false;
public static class ClientEncryptionOptions extends EncryptionOptions
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4460e286/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index 5e64c43..da8a3f4 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -55,6 +55,7 @@ public final class SSLFactory
serverSocket.setReuseAddress(true);
String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
+serverSocket.setNeedClientAuth(options.require_client_auth);
serverSocket.bind(new InetSocketAddress(address, port), 100);
return serverSocket;
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4460e286/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
index f6ab1f7..0a456b9 100644
--- a/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
+++ b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
@@ -249,6 +249,7 @@ public class CustomTThreadPoolServer extends TServer
logger.info(enabling encrypted thrift connections between
client and server);
TSSLTransportParameters params = new
TSSLTransportParameters(clientEnc.protocol, clientEnc.cipher_suites);
params.setKeyStore(clientEnc.keystore,
clientEnc.keystore_password);
+params.requireClientAuth(clientEnc.require_client_auth);
TServerSocket sslServer =
TSSLTransportFactory.getServerSocket(addr.getPort(), 0, addr.getAddress(),
params);
serverTransport = new
TCustomServerSocket(sslServer.getServerSocket(), args.keepAlive,
[3/3] git commit: Merge branch 'cassandra-1.2' into trunk
Updated Branches: refs/heads/trunk af404f211 - 95c1ed468 Merge branch 'cassandra-1.2' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/95c1ed46 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/95c1ed46 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/95c1ed46 Branch: refs/heads/trunk Commit: 95c1ed468d2efa772e26b7cf3d56011284f24c72 Parents: af404f2 4460e28 Author: Vijay Parthasarathy vijay2...@gmail.com Authored: Mon Jan 7 16:01:56 2013 -0800 Committer: Vijay Parthasarathy vijay2...@gmail.com Committed: Mon Jan 7 16:01:56 2013 -0800 -- CHANGES.txt|1 + conf/cassandra.yaml|2 + .../apache/cassandra/config/EncryptionOptions.java |1 + .../cassandra/cql3/statements/SelectStatement.java | 18 ++- .../org/apache/cassandra/security/SSLFactory.java |1 + .../cassandra/thrift/CustomTThreadPoolServer.java |1 + .../org/apache/cassandra/transport/Server.java |3 +- 7 files changed, 20 insertions(+), 7 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/95c1ed46/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/95c1ed46/conf/cassandra.yaml -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/95c1ed46/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java --
[1/3] git commit: Validat correctly selects on composite partition key
Validat correctly selects on composite partition key
patch by slebresne; reviewed by jbellis for CASSANDRA-5122
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0d6131c4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0d6131c4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0d6131c4
Branch: refs/heads/trunk
Commit: 0d6131c400cc296796f132f802f4156408e84ace
Parents: dac6048
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon Jan 7 17:22:49 2013 +0100
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon Jan 7 17:22:49 2013 +0100
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/SelectStatement.java | 18 ++-
2 files changed, 13 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d6131c4/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 78643d5..e038599 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -22,6 +22,7 @@
* cqlsh: fix DESCRIBE for 1.1 cfs in CQL3 (CASSANDRA-5101)
* Correctly gossip with nodes = 1.1.7 (CASSANDRA-5102)
* Ensure CL guarantees on digest mismatch (CASSANDRA-5113)
+ * Validate correctly selects on composite partition key (CASSANDRA-5122)
Merged from 1.1:
* Pig: correctly decode row keys in widerow mode (CASSANDRA-5098)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0d6131c4/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 b41659c..e88784c 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -271,10 +271,10 @@ public class SelectStatement implements CQLStatement
RowPosition finishKey = RowPosition.forKey(finishKeyBytes, p);
if (startKey.compareTo(finishKey) 0 !finishKey.isMinimum(p))
{
-if (p instanceof RandomPartitioner)
-throw new InvalidRequestException(Start key sorts after
end key. This is not allowed; you probably should not specify end key at all,
under RandomPartitioner);
-else
+if (p.preservesOrder())
throw new InvalidRequestException(Start key must sort
before (or equal to) finish key in your partitioner!);
+else
+throw new InvalidRequestException(Start key sorts after
end key. This is not allowed; you probably should not specify end key at all
under random partitioner);
}
if (includeKeyBound(Bound.START))
{
@@ -991,6 +991,7 @@ public class SelectStatement implements CQLStatement
CFDefinition cfDef = cfm.getCfDef();
SelectStatement stmt = new SelectStatement(cfDef,
getBoundsTerms(), parameters);
CFDefinition.Name[] names = new
CFDefinition.Name[getBoundsTerms()];
+IPartitioner partitioner = StorageService.getPartitioner();
// Select clause
if (parameters.isCount)
@@ -1044,8 +1045,6 @@ public class SelectStatement implements CQLStatement
switch (name.kind)
{
case KEY_ALIAS:
-if (rel.operator() != Relation.Type.EQ
rel.operator() != Relation.Type.IN !rel.onToken
!StorageService.getPartitioner().preservesOrder())
-throw new InvalidRequestException(Only EQ and IN
relation are supported on the partition key for RandomPartitioner (unless you
use the token() function));
stmt.keyRestrictions[name.position] =
updateRestriction(name, stmt.keyRestrictions[name.position], rel);
break;
case COLUMN_ALIAS:
@@ -,7 +1110,11 @@ public class SelectStatement implements CQLStatement
if (restriction == null)
{
if (stmt.onToken)
-throw new InvalidRequestException(String.format(The
token() function must be applied to all partition key components or none of
them));
+throw new InvalidRequestException(The token()
function must be applied to all partition key components or none of them);
+
+// Under a non order perserving partitioner, the only time
not restricting a key part is allowed is if none are restricted
+if (!partitioner.preservesOrder() i 0
stmt.keyRestrictions[i-1] != null)
+
[jira] [Updated] (CASSANDRA-5120) Add support for SSL sockets to use client certificate authentication.
[ https://issues.apache.org/jira/browse/CASSANDRA-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-5120: Fix Version/s: (was: 1.2.0) 1.2.1 Assignee: Steven Franklin Add support for SSL sockets to use client certificate authentication. - Key: CASSANDRA-5120 URL: https://issues.apache.org/jira/browse/CASSANDRA-5120 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.0 Reporter: Steven Franklin Assignee: Steven Franklin Priority: Minor Fix For: 1.2.1 Attachments: trunk-5120.txt Add an option to EncryptionOptions to require client certication authentication. -- 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] [Reopened] (CASSANDRA-5116) upgradesstables does not upgrade all sstables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kjellman reopened CASSANDRA-5116: - Assignee: Yuki Morishita (was: Michael Kjellman) reopening after a conversation...However, i can't personally figure out a consistent way to reproduce this. if someone else runs into this it would be great to have your feedback. upgradesstables does not upgrade all sstables on a node --- Key: CASSANDRA-5116 URL: https://issues.apache.org/jira/browse/CASSANDRA-5116 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Ubuntu 12.04 Reporter: Michael Kjellman Assignee: Yuki Morishita upgradesstables appears to be skipping sstables randomly. finding a sstable with an mtime the upgrade time and grepping through the logs for a corresponding compaction log line, i find nothing. I have reproduced this on all of my nodes across the cluster. is performAllSSTableOperation somehow skipping sstables? -- 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-5127) unsafe
Michael Kjellman created CASSANDRA-5127:
---
Summary: unsafe
Key: CASSANDRA-5127
URL: https://issues.apache.org/jira/browse/CASSANDRA-5127
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
Priority: Minor
unsafeAssassinateEndpoint() throws NullPointerException and the node still
seems to be in gossip.
gossip info for node in question:
{code}
/10.8.30.15
HOST_ID:d84a5632-d6d5-4b06-8e1b-ae39ab185ca1
RPC_ADDRESS:0.0.0.0
RACK:RAC1
DC:DC1
REMOVAL_COORDINATOR:REMOVER,b63fe173-5d13-4905-a59f-a78790f4f980
RELEASE_VERSION:1.2.0
NET_VERSION:6
LOAD:2.64185473948E11
STATUS:removed,d84a5632-d6d5-4b06-8e1b-ae39ab185ca1,1357874470406
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
{code}
{code}
ERROR 19:26:20,078 Exception in thread Thread[GossipStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1192)
at
org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1200)
at
org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1452)
at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1163)
at
org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895)
at
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805)
at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:856)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:57)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{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-5127) unsafeAssassinateEndpoint throws NullPointerException and fails to remove node
[
https://issues.apache.org/jira/browse/CASSANDRA-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-5127:
Summary: unsafeAssassinateEndpoint throws NullPointerException and fails to
remove node (was: unsafe)
unsafeAssassinateEndpoint throws NullPointerException and fails to remove node
--
Key: CASSANDRA-5127
URL: https://issues.apache.org/jira/browse/CASSANDRA-5127
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
Priority: Minor
unsafeAssassinateEndpoint() throws NullPointerException and the node still
seems to be in gossip.
gossip info for node in question:
{code}
/10.8.30.15
HOST_ID:d84a5632-d6d5-4b06-8e1b-ae39ab185ca1
RPC_ADDRESS:0.0.0.0
RACK:RAC1
DC:DC1
REMOVAL_COORDINATOR:REMOVER,b63fe173-5d13-4905-a59f-a78790f4f980
RELEASE_VERSION:1.2.0
NET_VERSION:6
LOAD:2.64185473948E11
STATUS:removed,d84a5632-d6d5-4b06-8e1b-ae39ab185ca1,1357874470406
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
{code}
{code}
ERROR 19:26:20,078 Exception in thread Thread[GossipStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1192)
at
org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1200)
at
org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1452)
at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1163)
at
org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895)
at
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805)
at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:856)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:57)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{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-5127) unsafeAssassinateEndpoint throws NullPointerException and fails to remove node from gossip
[
https://issues.apache.org/jira/browse/CASSANDRA-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-5127:
Summary: unsafeAssassinateEndpoint throws NullPointerException and fails to
remove node from gossip (was: unsafeAssassinateEndpoint throws
NullPointerException and fails to remove node)
unsafeAssassinateEndpoint throws NullPointerException and fails to remove
node from gossip
--
Key: CASSANDRA-5127
URL: https://issues.apache.org/jira/browse/CASSANDRA-5127
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
Priority: Minor
unsafeAssassinateEndpoint() throws NullPointerException and the node still
seems to be in gossip.
gossip info for node in question:
{code}
/10.8.30.15
HOST_ID:d84a5632-d6d5-4b06-8e1b-ae39ab185ca1
RPC_ADDRESS:0.0.0.0
RACK:RAC1
DC:DC1
REMOVAL_COORDINATOR:REMOVER,b63fe173-5d13-4905-a59f-a78790f4f980
RELEASE_VERSION:1.2.0
NET_VERSION:6
LOAD:2.64185473948E11
STATUS:removed,d84a5632-d6d5-4b06-8e1b-ae39ab185ca1,1357874470406
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
{code}
{code}
ERROR 19:26:20,078 Exception in thread Thread[GossipStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1192)
at
org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1200)
at
org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1452)
at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1163)
at
org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895)
at
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805)
at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:856)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:57)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{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] [Commented] (CASSANDRA-5116) upgradesstables does not upgrade all sstables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546565#comment-13546565 ] Yuki Morishita commented on CASSANDRA-5116: --- Couple of things I noticed during investigation: * As Michael commented above, there are some sstables that are not referenced by CF. That happens when those sstables are ancestors of other sstables(see https://github.com/apache/cassandra/blob/cassandra-1.2.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L267). Those sstables are supposed to be deleted through SSTableReader#releaseReference() from the comment below that line. But sstables would not be deleted since releaseReferece() checks isCompacted flag which, as the name suggests, only becomes true when compacted. There is no log about this behavior, so when that happens after upgradesstables, I think it is confusing. So I propose fix for actually deleting file + logging when that happens. * Maybe we can raise priority of updatesstables task among other compaction tasks to be processed as first as possible. * nodetool upgradesstables just submits task for upgrade but never knows when it finishes. It may be useful if we track the progress of upgrade like CASSANDRA-4767. (same can be said to cleanup, scrub, etc). upgradesstables does not upgrade all sstables on a node --- Key: CASSANDRA-5116 URL: https://issues.apache.org/jira/browse/CASSANDRA-5116 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Ubuntu 12.04 Reporter: Michael Kjellman Assignee: Yuki Morishita upgradesstables appears to be skipping sstables randomly. finding a sstable with an mtime the upgrade time and grepping through the logs for a corresponding compaction log line, i find nothing. I have reproduced this on all of my nodes across the cluster. is performAllSSTableOperation somehow skipping sstables? -- 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: don't report harmless cache read problem as debug, don't rely on FileInputStream.available to always return 0 patch by dbrosius reviewed by mkjellman for CASSANDRA-4916
Updated Branches:
refs/heads/trunk 95c1ed468 - 1d641f511
don't report harmless cache read problem as debug, don't rely on
FileInputStream.available to always return 0
patch by dbrosius reviewed by mkjellman for CASSANDRA-4916
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1d641f51
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1d641f51
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1d641f51
Branch: refs/heads/trunk
Commit: 1d641f5111613a5a049042a8723d0dd9ffc29c02
Parents: 95c1ed4
Author: Dave Brosius dbros...@apache.org
Authored: Tue Jan 8 00:16:44 2013 -0500
Committer: Dave Brosius dbros...@apache.org
Committed: Tue Jan 8 00:16:44 2013 -0500
--
.../apache/cassandra/cache/AutoSavingCache.java|9 +-
.../io/util/LengthAvailableInputStream.java| 98 +++
2 files changed, 103 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1d641f51/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--
diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
index 4e35d34..7e4bb77 100644
--- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
+++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
@@ -37,6 +37,7 @@ import org.apache.cassandra.db.compaction.OperationType;
import org.apache.cassandra.db.ColumnFamilyStore;
import org.apache.cassandra.io.FSWriteError;
import org.apache.cassandra.io.util.FileUtils;
+import org.apache.cassandra.io.util.LengthAvailableInputStream;
import org.apache.cassandra.io.util.SequentialWriter;
import org.apache.cassandra.service.CacheService;
import org.apache.cassandra.service.StorageService;
@@ -109,7 +110,7 @@ public class AutoSavingCacheK extends CacheKey, V extends
InstrumentingCacheK
try
{
logger.info(String.format(reading saved cache %s, path));
-in = new DataInputStream(new BufferedInputStream(new
FileInputStream(path)));
+in = new DataInputStream(new LengthAvailableInputStream(new
BufferedInputStream(new FileInputStream(path)), path.length()));
SetByteBuffer keys = new HashSetByteBuffer();
while (in.available() 0)
{
@@ -120,7 +121,7 @@ public class AutoSavingCacheK extends CacheKey, V extends
InstrumentingCacheK
}
catch (Exception e)
{
-logger.warn(String.format(error reading saved cache %s, keys
loaded so far: %d, path.getAbsolutePath(), count), e);
+logger.debug(String.format(harmless error reading saved cache
%s fully, keys loaded so far: %d, path.getAbsolutePath(), count), e);
return count;
}
finally
@@ -137,7 +138,7 @@ public class AutoSavingCacheK extends CacheKey, V extends
InstrumentingCacheK
try
{
logger.info(String.format(reading saved cache %s, path));
-in = new DataInputStream(new BufferedInputStream(new
FileInputStream(path)));
+in = new DataInputStream(new LengthAvailableInputStream(new
BufferedInputStream(new FileInputStream(path)), path.length()));
ListFuturePairK, V futures = new
ArrayListFuturePairK, V();
while (in.available() 0)
{
@@ -157,7 +158,7 @@ public class AutoSavingCacheK extends CacheKey, V extends
InstrumentingCacheK
}
catch (Exception e)
{
-logger.warn(String.format(error reading saved cache %s,
path.getAbsolutePath()), e);
+logger.debug(String.format(harmless error reading saved cache
%s, path.getAbsolutePath()), e);
}
finally
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1d641f51/src/java/org/apache/cassandra/io/util/LengthAvailableInputStream.java
--
diff --git
a/src/java/org/apache/cassandra/io/util/LengthAvailableInputStream.java
b/src/java/org/apache/cassandra/io/util/LengthAvailableInputStream.java
new file mode 100644
index 000..a467ce2
--- /dev/null
+++ b/src/java/org/apache/cassandra/io/util/LengthAvailableInputStream.java
@@ -0,0 +1,98 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
[jira] [Commented] (CASSANDRA-4916) Starting Cassandra throws EOF while reading saved cache
[ https://issues.apache.org/jira/browse/CASSANDRA-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546615#comment-13546615 ] Dave Brosius commented on CASSANDRA-4916: - committed to trunk as 1d641f5111613a5a049042a8723d0dd9ffc29c02 Starting Cassandra throws EOF while reading saved cache --- Key: CASSANDRA-4916 URL: https://issues.apache.org/jira/browse/CASSANDRA-4916 Project: Cassandra Issue Type: Bug Components: Core Reporter: Michael Kjellman Assignee: Dave Brosius Priority: Minor Fix For: 1.2.1 Attachments: 4916.txt Currently seeing nodes throw an EOF while reading a saved cache on the system schema when starting cassandra WARN 14:25:54,896 error reading saved cache /ssd/saved_caches/system-schema_columns-KeyCache-b.db java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:392) at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:349) at org.apache.cassandra.service.CacheService$KeyCacheSerializer.deserialize(CacheService.java:378) at org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:144) at org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:278) at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:393) at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:365) at org.apache.cassandra.db.Table.initCf(Table.java:334) at org.apache.cassandra.db.Table.init(Table.java:272) at org.apache.cassandra.db.Table.open(Table.java:102) at org.apache.cassandra.db.Table.open(Table.java:80) at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:320) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:203) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:395) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:438) to reproduce delete all data files, start a cluster, leave cluster up long enough to build a cache. nodetool drain, kill cassandra process. start cassandra process in foreground and note EOF thrown (see above for stack trace) -- 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-5117) CQL 3 ALTER TABLE ... ADD causes OOB
[
https://issues.apache.org/jira/browse/CASSANDRA-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546628#comment-13546628
]
Dave Brosius commented on CASSANDRA-5117:
-
+1
CQL 3 ALTER TABLE ... ADD causes OOB
Key: CASSANDRA-5117
URL: https://issues.apache.org/jira/browse/CASSANDRA-5117
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Mac OSX, DS Java Driver, apache-cassandra-1.2.0-src
downloaded from project Jan 2, 2013
Reporter: Kristine Hahn
Assignee: Dave Brosius
Fix For: 1.2.1
Attachments: 5117.txt, 5117-v2.txt, OOB.txt
To reproduce:
./cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 2.3.0 | Cassandra 1.2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.35.0]
Use HELP for help.
cqlsh create keyspace music with replication = {'CLASS' :
... 'SimpleStrategy', 'replication_factor' : 3};
cqlsh use music
... ;
cqlsh:music CREATE TABLE songs (
... id uuid PRIMARY KEY,
... title text,
... album text,
... artist text,
... data blob
... );
cqlsh:music insert into songs (id, title, artist, album) values
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', 'La Grange', 'ZZ Top', 'Tres
Hombres');
cqlsh:music insert into songs (id, title, artist, album) values
('8a172618-b121-4136-bb10-f665cfc469eb', 'Moving in Stereo', 'Fu Manchu', 'We
Must Obey');
cqlsh:music insert into songs (id, title, artist, album) values
('62c36092-82a1-3a00-93d1-46196ee77204', 'Outside Woman Blues', 'Back Door
Slam', 'Roll Away');
cqlsh:music CREATE TABLE song_tags (
... id uuid,
... tag_name text,
... PRIMARY KEY (id, tag_name)
... );
cqlsh:music select * from song_tags;
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', 'blues');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('8a172618-b121-4136-bb10-f665cfc469eb', 'covers');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', '1973');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('8a172618-b121-4136-bb10-f665cfc469eb', '2007');
cqlsh:music select * from song_tags;
id | tag_name
--+--
a3e64f8f-bd44-4f28-b8d9-6938726e34d4 | 1973
a3e64f8f-bd44-4f28-b8d9-6938726e34d4 |blues
8a172618-b121-4136-bb10-f665cfc469eb | 2007
8a172618-b121-4136-bb10-f665cfc469eb | covers
cqlsh:music drop table song_tags;
cqlsh:music ALTER TABLE songs ADD tags settext;
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] [Updated] (CASSANDRA-5117) CQL 3 ALTER TABLE ... ADD causes OOB
[
https://issues.apache.org/jira/browse/CASSANDRA-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated CASSANDRA-5117:
Reviewer: dbrosius (was: slebresne)
Assignee: Sylvain Lebresne (was: Dave Brosius)
CQL 3 ALTER TABLE ... ADD causes OOB
Key: CASSANDRA-5117
URL: https://issues.apache.org/jira/browse/CASSANDRA-5117
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Mac OSX, DS Java Driver, apache-cassandra-1.2.0-src
downloaded from project Jan 2, 2013
Reporter: Kristine Hahn
Assignee: Sylvain Lebresne
Fix For: 1.2.1
Attachments: 5117.txt, 5117-v2.txt, OOB.txt
To reproduce:
./cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 2.3.0 | Cassandra 1.2.0-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol
19.35.0]
Use HELP for help.
cqlsh create keyspace music with replication = {'CLASS' :
... 'SimpleStrategy', 'replication_factor' : 3};
cqlsh use music
... ;
cqlsh:music CREATE TABLE songs (
... id uuid PRIMARY KEY,
... title text,
... album text,
... artist text,
... data blob
... );
cqlsh:music insert into songs (id, title, artist, album) values
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', 'La Grange', 'ZZ Top', 'Tres
Hombres');
cqlsh:music insert into songs (id, title, artist, album) values
('8a172618-b121-4136-bb10-f665cfc469eb', 'Moving in Stereo', 'Fu Manchu', 'We
Must Obey');
cqlsh:music insert into songs (id, title, artist, album) values
('62c36092-82a1-3a00-93d1-46196ee77204', 'Outside Woman Blues', 'Back Door
Slam', 'Roll Away');
cqlsh:music CREATE TABLE song_tags (
... id uuid,
... tag_name text,
... PRIMARY KEY (id, tag_name)
... );
cqlsh:music select * from song_tags;
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', 'blues');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('8a172618-b121-4136-bb10-f665cfc469eb', 'covers');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('a3e64f8f-bd44-4f28-b8d9-6938726e34d4', '1973');
cqlsh:music INSERT INTO song_tags (id, tag_name) VALUES
('8a172618-b121-4136-bb10-f665cfc469eb', '2007');
cqlsh:music select * from song_tags;
id | tag_name
--+--
a3e64f8f-bd44-4f28-b8d9-6938726e34d4 | 1973
a3e64f8f-bd44-4f28-b8d9-6938726e34d4 |blues
8a172618-b121-4136-bb10-f665cfc469eb | 2007
8a172618-b121-4136-bb10-f665cfc469eb | covers
cqlsh:music drop table song_tags;
cqlsh:music ALTER TABLE songs ADD tags settext;
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] [Assigned] (CASSANDRA-5127) unsafeAssassinateEndpoint throws NullPointerException and fails to remove node from gossip
[
https://issues.apache.org/jira/browse/CASSANDRA-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-5127:
---
Assignee: Brandon Williams
unsafeAssassinateEndpoint throws NullPointerException and fails to remove
node from gossip
--
Key: CASSANDRA-5127
URL: https://issues.apache.org/jira/browse/CASSANDRA-5127
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
Assignee: Brandon Williams
Priority: Minor
unsafeAssassinateEndpoint() throws NullPointerException and the node still
seems to be in gossip.
gossip info for node in question:
{code}
/10.8.30.15
HOST_ID:d84a5632-d6d5-4b06-8e1b-ae39ab185ca1
RPC_ADDRESS:0.0.0.0
RACK:RAC1
DC:DC1
REMOVAL_COORDINATOR:REMOVER,b63fe173-5d13-4905-a59f-a78790f4f980
RELEASE_VERSION:1.2.0
NET_VERSION:6
LOAD:2.64185473948E11
STATUS:removed,d84a5632-d6d5-4b06-8e1b-ae39ab185ca1,1357874470406
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
{code}
{code}
ERROR 19:26:20,078 Exception in thread Thread[GossipStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1192)
at
org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1200)
at
org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1452)
at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1163)
at
org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895)
at
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805)
at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:856)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:57)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{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-5128) Stream hints on decommission
Jason Brown created CASSANDRA-5128: -- Summary: Stream hints on decommission Key: CASSANDRA-5128 URL: https://issues.apache.org/jira/browse/CASSANDRA-5128 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.1 Reporter: Jason Brown Assignee: Jason Brown Looks like decommissioning a node (nodetool decommission) will stream all the non-system table data out to it's appropriate peers (StorageService.unbootstrap()), but hints will disappear with the node. Let's send those hints to another peer (preferably in the same rack, and hopefully at least the same datacenter) them to be replayed. The use case here is auto-scaling vnode clusters in ec2. When auto-scaling down, I'd want to call decommission on the node to leave the ring (and be terminated), and still have all of it's artifacts (data and hints) survive. -- 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-5127) unsafeAssassinateEndpoint throws NullPointerException and fails to remove node from gossip
[
https://issues.apache.org/jira/browse/CASSANDRA-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-5127:
Fix Version/s: 1.2.1
unsafeAssassinateEndpoint throws NullPointerException and fails to remove
node from gossip
--
Key: CASSANDRA-5127
URL: https://issues.apache.org/jira/browse/CASSANDRA-5127
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
Assignee: Brandon Williams
Priority: Minor
Fix For: 1.2.1
unsafeAssassinateEndpoint() throws NullPointerException and the node still
seems to be in gossip.
gossip info for node in question:
{code}
/10.8.30.15
HOST_ID:d84a5632-d6d5-4b06-8e1b-ae39ab185ca1
RPC_ADDRESS:0.0.0.0
RACK:RAC1
DC:DC1
REMOVAL_COORDINATOR:REMOVER,b63fe173-5d13-4905-a59f-a78790f4f980
RELEASE_VERSION:1.2.0
NET_VERSION:6
LOAD:2.64185473948E11
STATUS:removed,d84a5632-d6d5-4b06-8e1b-ae39ab185ca1,1357874470406
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
{code}
{code}
ERROR 19:26:20,078 Exception in thread Thread[GossipStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1192)
at
org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1200)
at
org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1452)
at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1163)
at
org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895)
at
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805)
at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:856)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:57)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{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] [Commented] (CASSANDRA-5127) unsafeAssassinateEndpoint throws NullPointerException and fails to remove node from gossip
[
https://issues.apache.org/jira/browse/CASSANDRA-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546644#comment-13546644
]
Brandon Williams commented on CASSANDRA-5127:
-
This is because there is no TOKENS state for a non-vnode host in 1.2. Mostly
saying this for myself so I don't forget what to do tomorrow.
unsafeAssassinateEndpoint throws NullPointerException and fails to remove
node from gossip
--
Key: CASSANDRA-5127
URL: https://issues.apache.org/jira/browse/CASSANDRA-5127
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
Assignee: Brandon Williams
Priority: Minor
unsafeAssassinateEndpoint() throws NullPointerException and the node still
seems to be in gossip.
gossip info for node in question:
{code}
/10.8.30.15
HOST_ID:d84a5632-d6d5-4b06-8e1b-ae39ab185ca1
RPC_ADDRESS:0.0.0.0
RACK:RAC1
DC:DC1
REMOVAL_COORDINATOR:REMOVER,b63fe173-5d13-4905-a59f-a78790f4f980
RELEASE_VERSION:1.2.0
NET_VERSION:6
LOAD:2.64185473948E11
STATUS:removed,d84a5632-d6d5-4b06-8e1b-ae39ab185ca1,1357874470406
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
{code}
{code}
ERROR 19:26:20,078 Exception in thread Thread[GossipStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1192)
at
org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1200)
at
org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1452)
at
org.apache.cassandra.service.StorageService.onChange(StorageService.java:1163)
at
org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895)
at
org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805)
at
org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:856)
at
org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:57)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{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-5129) newly bootstrapping nodes hang indefinitely in status STATUS:BOOT while JOINING cluster
Michael Kjellman created CASSANDRA-5129:
---
Summary: newly bootstrapping nodes hang indefinitely in status
STATUS:BOOT while JOINING cluster
Key: CASSANDRA-5129
URL: https://issues.apache.org/jira/browse/CASSANDRA-5129
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
bootstrapping a new node causes it to hang indefinitely in STATUS:BOOT
Nodes streaming to the new node report
{code}
Mode: NORMAL
Nothing streaming to /10.8.30.16
Not receiving any streams.
Pool NameActive Pending Completed
Commandsn/a 01843990
Responses n/a 2 661750
{code}
the node being streamed to stuck in the JOINING state reports:
{code}
Mode: JOINING
Not sending any streams.
Nothing streaming from /10.8.30.103
Nothing streaming from /10.8.30.102
Pool NameActive Pending Completed
Commandsn/a 0 10
Responses n/a 0 613577
{code}
it appears that the nodes in the nothing streaming state never sends a
finished streaming to the joining node.
no exceptions are thrown during the streaming on either node while the node is
in this state.
--
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-5129) newly bootstrapping nodes hang indefinitely in status STATUS:BOOT while JOINING cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-5129:
Description:
bootstrapping a new node causes it to hang indefinitely in STATUS:BOOT
Nodes streaming to the new node report
{code}
Mode: NORMAL
Nothing streaming to /10.8.30.16
Not receiving any streams.
Pool NameActive Pending Completed
Commandsn/a 01843990
Responses n/a 2 661750
{code}
the node being streamed to stuck in the JOINING state reports:
{code}
Mode: JOINING
Not sending any streams.
Nothing streaming from /10.8.30.103
Nothing streaming from /10.8.30.102
Pool NameActive Pending Completed
Commandsn/a 0 10
Responses n/a 0 613577
{code}
it appears that the nodes in the nothing streaming state never sends a
finished streaming to the joining node.
no exceptions are thrown during the streaming on either node while the node is
in this state.
{code:name=full gossip state of bootstrapping node}
/10.8.30.16
NET_VERSION:6
RELEASE_VERSION:1.2.0
STATUS:BOOT,127605887595351923798765477786913079289
RACK:RAC1
RPC_ADDRESS:0.0.0.0
DC:DC1
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
HOST_ID:e20817ce-7454-4dc4-a1c6-b1dec35c4491
LOAD:1.11824041581E11
{code}
was:
bootstrapping a new node causes it to hang indefinitely in STATUS:BOOT
Nodes streaming to the new node report
{code}
Mode: NORMAL
Nothing streaming to /10.8.30.16
Not receiving any streams.
Pool NameActive Pending Completed
Commandsn/a 01843990
Responses n/a 2 661750
{code}
the node being streamed to stuck in the JOINING state reports:
{code}
Mode: JOINING
Not sending any streams.
Nothing streaming from /10.8.30.103
Nothing streaming from /10.8.30.102
Pool NameActive Pending Completed
Commandsn/a 0 10
Responses n/a 0 613577
{code}
it appears that the nodes in the nothing streaming state never sends a
finished streaming to the joining node.
no exceptions are thrown during the streaming on either node while the node is
in this state.
newly bootstrapping nodes hang indefinitely in status STATUS:BOOT while
JOINING cluster
-
Key: CASSANDRA-5129
URL: https://issues.apache.org/jira/browse/CASSANDRA-5129
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
bootstrapping a new node causes it to hang indefinitely in STATUS:BOOT
Nodes streaming to the new node report
{code}
Mode: NORMAL
Nothing streaming to /10.8.30.16
Not receiving any streams.
Pool NameActive Pending Completed
Commandsn/a 01843990
Responses n/a 2 661750
{code}
the node being streamed to stuck in the JOINING state reports:
{code}
Mode: JOINING
Not sending any streams.
Nothing streaming from /10.8.30.103
Nothing streaming from /10.8.30.102
Pool NameActive Pending Completed
Commandsn/a 0 10
Responses n/a 0 613577
{code}
it appears that the nodes in the nothing streaming state never sends a
finished streaming to the joining node.
no exceptions are thrown during the streaming on either node while the node
is in this state.
{code:name=full gossip state of bootstrapping node}
/10.8.30.16
NET_VERSION:6
RELEASE_VERSION:1.2.0
STATUS:BOOT,127605887595351923798765477786913079289
RACK:RAC1
RPC_ADDRESS:0.0.0.0
DC:DC1
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
HOST_ID:e20817ce-7454-4dc4-a1c6-b1dec35c4491
LOAD:1.11824041581E11
{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-5129) newly bootstrapping nodes hang indefinitely in STATUS:BOOT while JOINING cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-5129:
Summary: newly bootstrapping nodes hang indefinitely in STATUS:BOOT while
JOINING cluster(was: newly bootstrapping nodes hang indefinitely in status
STATUS:BOOT while JOINING cluster )
newly bootstrapping nodes hang indefinitely in STATUS:BOOT while JOINING
cluster
--
Key: CASSANDRA-5129
URL: https://issues.apache.org/jira/browse/CASSANDRA-5129
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
bootstrapping a new node causes it to hang indefinitely in STATUS:BOOT
Nodes streaming to the new node report
{code}
Mode: NORMAL
Nothing streaming to /10.8.30.16
Not receiving any streams.
Pool NameActive Pending Completed
Commandsn/a 01843990
Responses n/a 2 661750
{code}
the node being streamed to stuck in the JOINING state reports:
{code}
Mode: JOINING
Not sending any streams.
Nothing streaming from /10.8.30.103
Nothing streaming from /10.8.30.102
Pool NameActive Pending Completed
Commandsn/a 0 10
Responses n/a 0 613577
{code}
it appears that the nodes in the nothing streaming state never sends a
finished streaming to the joining node.
no exceptions are thrown during the streaming on either node while the node
is in this state.
{code:name=full gossip state of bootstrapping node}
/10.8.30.16
NET_VERSION:6
RELEASE_VERSION:1.2.0
STATUS:BOOT,127605887595351923798765477786913079289
RACK:RAC1
RPC_ADDRESS:0.0.0.0
DC:DC1
SCHEMA:5cd8420d-ce3c-3625-8293-67558a24816b
HOST_ID:e20817ce-7454-4dc4-a1c6-b1dec35c4491
LOAD:1.11824041581E11
{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-5130) streaming from another node results in a bogus % streamed on that sstable
Michael Kjellman created CASSANDRA-5130:
---
Summary: streaming from another node results in a bogus % streamed
on that sstable
Key: CASSANDRA-5130
URL: https://issues.apache.org/jira/browse/CASSANDRA-5130
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
5689557% from node 10.8.25.132 ??
{code}
root@scl-cas06:~# nodetool netstats
Mode: NORMAL
Streaming to: /10.8.25.132
/data2/cassandra/evidence/messages/evidence-messages-ia-2378-Data.db
sections=1504 progress=10877426741/11376970910 - 95%
/data/cassandra/evidence/messages/evidence-messages-ia-2396-Data.db
sections=1326 progress=0/747963031 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2412-Data.db
sections=342 progress=0/29791995 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2413-Data.db
sections=307 progress=0/42375841 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2375-Data.db
sections=702 progress=0/5138101708 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2416-Data.db
sections=220 progress=0/21729661 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2382-Data.db
sections=1498 progress=0/7731727694 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2388-Data.db
sections=698 progress=0/2097813910 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2401-Data.db
sections=889 progress=0/154218729 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2411-Data.db
sections=290 progress=0/45457960 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2414-Data.db
sections=22 progress=0/1809989 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2407-Data.db
sections=423 progress=0/55302683 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2409-Data.db
sections=73 progress=0/6366250 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2377-Data.db
sections=1298 progress=0/815617310 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2389-Data.db
sections=167 progress=0/7307457 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2415-Data.db
sections=126 progress=0/9260301 - 0%
Nothing streaming to /10.8.30.16
Streaming from: /10.8.25.132
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-1091-Data.db
sections=328 progress=0/52507334 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-1084-Data.db
sections=1029 progress=0/198699737 - 0%
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-1097-Data.db
sections=35 progress=0/731705 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-1079-Data.db
sections=1504 progress=1126955908333568/19807443126 - 5689557%
Pool NameActive Pending Completed
Commandsn/a 0 459801
Responses n/a 01061826
{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] [Commented] (CASSANDRA-5130) streaming from another node results in a bogus % streamed on that sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546655#comment-13546655
]
Michael Kjellman commented on CASSANDRA-5130:
-
1141023% on this node?
{code}
root@scl-cas10:~# nodetool netstats
Mode: NORMAL
Streaming to: /10.8.30.103
/data/cassandra/evidence/messages/evidence-messages-ia-1079-Data.db
sections=1504 progress=12737080525/19807443126 - 64%
/data2/cassandra/evidence/messages/evidence-messages-ia-1097-Data.db
sections=35 progress=0/731705 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-1084-Data.db
sections=1029 progress=0/198699737 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-1091-Data.db
sections=328 progress=0/52507334 - 0%
Streaming from: /10.8.30.103
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-2375-Data.db
sections=702 progress=58626960326656/5138101708 - 1141023%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-2389-Data.db
sections=167 progress=0/7307457 - 0%
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-2388-Data.db
sections=698 progress=0/2097813910 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-2416-Data.db
sections=220 progress=0/21729661 - 0%
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-2377-Data.db
sections=1298 progress=0/815617310 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-2409-Data.db sections=73
progress=0/6366250 - 0%
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-2414-Data.db
sections=22 progress=0/1809989 - 0%
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-2382-Data.db
sections=1498 progress=0/7731727694 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-2407-Data.db
sections=423 progress=0/55302683 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-2411-Data.db
sections=290 progress=0/45457960 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-2415-Data.db
sections=126 progress=0/9260301 - 0%
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-2401-Data.db
sections=889 progress=0/154218729 - 0%
Pool NameActive Pending Completed
Commandsn/a 0 252046
Responses n/a 3 746069
{code}
streaming from another node results in a bogus % streamed on that sstable
-
Key: CASSANDRA-5130
URL: https://issues.apache.org/jira/browse/CASSANDRA-5130
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
5689557% from node 10.8.25.132 ??
{code}
root@scl-cas06:~# nodetool netstats
Mode: NORMAL
Streaming to: /10.8.25.132
/data2/cassandra/evidence/messages/evidence-messages-ia-2378-Data.db
sections=1504 progress=10877426741/11376970910 - 95%
/data/cassandra/evidence/messages/evidence-messages-ia-2396-Data.db
sections=1326 progress=0/747963031 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2412-Data.db
sections=342 progress=0/29791995 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2413-Data.db
sections=307 progress=0/42375841 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2375-Data.db
sections=702 progress=0/5138101708 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2416-Data.db
sections=220 progress=0/21729661 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2382-Data.db
sections=1498 progress=0/7731727694 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2388-Data.db
sections=698 progress=0/2097813910 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2401-Data.db
sections=889 progress=0/154218729 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2411-Data.db
sections=290 progress=0/45457960 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2414-Data.db
sections=22 progress=0/1809989 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2407-Data.db
sections=423 progress=0/55302683 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2409-Data.db
sections=73 progress=0/6366250 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2377-Data.db
sections=1298 progress=0/815617310 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2389-Data.db
sections=167 progress=0/7307457 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2415-Data.db
sections=126 progress=0/9260301 - 0%
Nothing streaming to /10.8.30.16
Streaming from: /10.8.25.132
evidence:
[jira] [Commented] (CASSANDRA-5130) streaming from another node results in a bogus % streamed on that sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546656#comment-13546656
]
Michael Kjellman commented on CASSANDRA-5130:
-
related to https://issues.apache.org/jira/browse/CASSANDRA-4687 ? streaming
wrong part of file?
streaming from another node results in a bogus % streamed on that sstable
-
Key: CASSANDRA-5130
URL: https://issues.apache.org/jira/browse/CASSANDRA-5130
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Ubuntu 12.04
Reporter: Michael Kjellman
5689557% from node 10.8.25.132 ??
{code}
root@scl-cas06:~# nodetool netstats
Mode: NORMAL
Streaming to: /10.8.25.132
/data2/cassandra/evidence/messages/evidence-messages-ia-2378-Data.db
sections=1504 progress=10877426741/11376970910 - 95%
/data/cassandra/evidence/messages/evidence-messages-ia-2396-Data.db
sections=1326 progress=0/747963031 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2412-Data.db
sections=342 progress=0/29791995 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2413-Data.db
sections=307 progress=0/42375841 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2375-Data.db
sections=702 progress=0/5138101708 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2416-Data.db
sections=220 progress=0/21729661 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2382-Data.db
sections=1498 progress=0/7731727694 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2388-Data.db
sections=698 progress=0/2097813910 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2401-Data.db
sections=889 progress=0/154218729 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2411-Data.db
sections=290 progress=0/45457960 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2414-Data.db
sections=22 progress=0/1809989 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2407-Data.db
sections=423 progress=0/55302683 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2409-Data.db
sections=73 progress=0/6366250 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2377-Data.db
sections=1298 progress=0/815617310 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2389-Data.db
sections=167 progress=0/7307457 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2415-Data.db
sections=126 progress=0/9260301 - 0%
Nothing streaming to /10.8.30.16
Streaming from: /10.8.25.132
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-1091-Data.db
sections=328 progress=0/52507334 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-1084-Data.db
sections=1029 progress=0/198699737 - 0%
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-1097-Data.db
sections=35 progress=0/731705 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-1079-Data.db
sections=1504 progress=1126955908333568/19807443126 - 5689557%
Pool NameActive Pending Completed
Commandsn/a 0 459801
Responses n/a 01061826
{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-5130) streaming from another node results in a bogus % streamed on that sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-5130:
Description:
reproducible thru a repair -pr
5689557% from node 10.8.25.132 ??
{code}
root@scl-cas06:~# nodetool netstats
Mode: NORMAL
Streaming to: /10.8.25.132
/data2/cassandra/evidence/messages/evidence-messages-ia-2378-Data.db
sections=1504 progress=10877426741/11376970910 - 95%
/data/cassandra/evidence/messages/evidence-messages-ia-2396-Data.db
sections=1326 progress=0/747963031 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2412-Data.db
sections=342 progress=0/29791995 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2413-Data.db
sections=307 progress=0/42375841 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2375-Data.db
sections=702 progress=0/5138101708 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2416-Data.db
sections=220 progress=0/21729661 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2382-Data.db
sections=1498 progress=0/7731727694 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2388-Data.db
sections=698 progress=0/2097813910 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2401-Data.db
sections=889 progress=0/154218729 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2411-Data.db
sections=290 progress=0/45457960 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2414-Data.db
sections=22 progress=0/1809989 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2407-Data.db
sections=423 progress=0/55302683 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2409-Data.db
sections=73 progress=0/6366250 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2377-Data.db
sections=1298 progress=0/815617310 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2389-Data.db
sections=167 progress=0/7307457 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2415-Data.db
sections=126 progress=0/9260301 - 0%
Nothing streaming to /10.8.30.16
Streaming from: /10.8.25.132
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-1091-Data.db
sections=328 progress=0/52507334 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-1084-Data.db
sections=1029 progress=0/198699737 - 0%
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-1097-Data.db
sections=35 progress=0/731705 - 0%
evidence:
/data/cassandra/evidence/messages/evidence-messages-ia-1079-Data.db
sections=1504 progress=1126955908333568/19807443126 - 5689557%
Pool NameActive Pending Completed
Commandsn/a 0 459801
Responses n/a 01061826
{code}
was:
5689557% from node 10.8.25.132 ??
{code}
root@scl-cas06:~# nodetool netstats
Mode: NORMAL
Streaming to: /10.8.25.132
/data2/cassandra/evidence/messages/evidence-messages-ia-2378-Data.db
sections=1504 progress=10877426741/11376970910 - 95%
/data/cassandra/evidence/messages/evidence-messages-ia-2396-Data.db
sections=1326 progress=0/747963031 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2412-Data.db
sections=342 progress=0/29791995 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2413-Data.db
sections=307 progress=0/42375841 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2375-Data.db
sections=702 progress=0/5138101708 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2416-Data.db
sections=220 progress=0/21729661 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2382-Data.db
sections=1498 progress=0/7731727694 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2388-Data.db
sections=698 progress=0/2097813910 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2401-Data.db
sections=889 progress=0/154218729 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2411-Data.db
sections=290 progress=0/45457960 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2414-Data.db
sections=22 progress=0/1809989 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2407-Data.db
sections=423 progress=0/55302683 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2409-Data.db
sections=73 progress=0/6366250 - 0%
/data2/cassandra/evidence/messages/evidence-messages-ia-2377-Data.db
sections=1298 progress=0/815617310 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2389-Data.db
sections=167 progress=0/7307457 - 0%
/data/cassandra/evidence/messages/evidence-messages-ia-2415-Data.db
sections=126 progress=0/9260301 - 0%
Nothing streaming to /10.8.30.16
Streaming from: /10.8.25.132
evidence:
/data2/cassandra/evidence/messages/evidence-messages-ia-1091-Data.db
