[jira] [Assigned] (CASSANDRA-4164) Bug with 'describe columnfamily' in cql(sh?)
[
https://issues.apache.org/jira/browse/CASSANDRA-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4164:
-
Assignee: paul cannon
Bug with 'describe columnfamily' in cql(sh?)
Key: CASSANDRA-4164
URL: https://issues.apache.org/jira/browse/CASSANDRA-4164
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Nick Bailey
Assignee: paul cannon
Fix For: 1.1.0
There is a discrepancy between create column family commands and then the
output of the describe command:
{noformat}
cqlsh:test CREATE TABLE timeline (
... user_id varchar,
... tweet_id uuid,
... author varchar,
... body varchar,
... PRIMARY KEY (user_id, tweet_id)
... );
cqlsh:test describe columnfamily timeline;
CREATE COLUMNFAMILY timeline (
user_id text PRIMARY KEY
) WITH
comment='' AND
comparator='CompositeType(org.apache.cassandra.db.marshal.UUIDType,org.apache.cassandra.db.marshal.UTF8Type)'
AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
default_validation=text AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write=True AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='org.apache.cassandra.io.compress.SnappyCompressor';
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4169) Locale settings on windows can break schema
[
https://issues.apache.org/jira/browse/CASSANDRA-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4169:
-
Assignee: Pavel Yaskevich
wtf does avro.parse use locale for?
we might just need to say upgrade to 1.1 when we don't use avro anymore
Locale settings on windows can break schema
---
Key: CASSANDRA-4169
URL: https://issues.apache.org/jira/browse/CASSANDRA-4169
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Windows
Reporter: Nick Bailey
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 1.2
The locale settings on windows can somehow affect how schema information is
either saved or loaded. When setting locale/language settings to Turkish, and
then starting cassandra, schema changes can be made successfully. When
restarting cassandra though, the following error is seen:
{noformat}
INFO [main] 2012-04-18 19:18:59,142 DatabaseDescriptor.java (line 501)
Loading schema version 4404f2e0-898b-11e1--242d50cf1fbf
ERROR [main] 2012-04-18 19:18:59,391 AbstractCassandraDaemon.java (line 373)
Exception encountered during startup
org.apache.avro.SchemaParseException: strıng is not a defined name. The
type of the name field must be a defined name or a {type: ...} expression.
at org.apache.avro.Schema.parse(Schema.java:986)
at org.apache.avro.Schema.parse(Schema.java:893)
at org.apache.cassandra.db.DefsTable.loadFromStorage(DefsTable.java:90)
at
org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:502)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:180)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:356)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)
{noformat}
This was reported on the DataStax forums, as well as reproduced by myself.
http://www.datastax.com/support-forums/topic/cassandra-service-doesnt-start
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4018) Add column metadata to system columnfamilies
[ https://issues.apache.org/jira/browse/CASSANDRA-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4018: - Assignee: Jonathan Ellis Add column metadata to system columnfamilies Key: CASSANDRA-4018 URL: https://issues.apache.org/jira/browse/CASSANDRA-4018 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.1.1 CASSANDRA-3792 adds this to the schema CFs; we should modernize the other system CFs as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4163) ALTER TABLE command breaks the pipe
[ https://issues.apache.org/jira/browse/CASSANDRA-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4163: - Assignee: paul cannon ALTER TABLE command breaks the pipe --- Key: CASSANDRA-4163 URL: https://issues.apache.org/jira/browse/CASSANDRA-4163 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: INFO 16:07:11,757 Cassandra version: 1.1.0-rc1-SNAPSHOT INFO 16:07:11,757 Thrift API version: 19.30.0 INFO 16:07:11,758 CQL supported versions: 2.0.0,3.0.0-beta1 (default: 2.0.0) Reporter: Kristine Hahn Assignee: paul cannon Labels: cql Fix For: 1.1.0 To reproduce the problem: ./cqlsh --cql3 Connected to Test Cluster at localhost:9160. [cqlsh 2.2.0 | Cassandra 1.1.0-rc1-SNAPSHOT | CQL spec 3.0.0 | Thrift protocol 19.30.0] Use HELP for help. cqlsh CREATE KEYSPACE test34 WITH strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' AND strategy_options:replication_factor='1'; cqlsh USE test34; cqlsh:test34 CREATE TABLE users ( ... password varchar, ... gender varchar, ... session_token varchar, ... state varchar, ... birth_year bigint, ... pk varchar, ... PRIMARY KEY (pk) ... ); cqlsh:test34 ALTER TABLE users ADD coupon_code varchar; TSocket read 0 bytes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-556) nodeprobe snapshot to support specific column families
[ https://issues.apache.org/jira/browse/CASSANDRA-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-556: Assignee: Yuki Morishita nodeprobe snapshot to support specific column families -- Key: CASSANDRA-556 URL: https://issues.apache.org/jira/browse/CASSANDRA-556 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Chris Were Assignee: Yuki Morishita Priority: Minor Labels: lhf Fix For: 1.1.1 It would be good to support dumping specific column families via nodeprobe for backup purposes. In my particular case the majority of cassandra data doesn't need to be backed up except for a couple of column families containing user settings / profiles etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-556) nodeprobe snapshot to support specific column families
[ https://issues.apache.org/jira/browse/CASSANDRA-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-556: Assignee: Dave Brosius (was: Yuki Morishita) Could you have a look at this, Dave? nodeprobe snapshot to support specific column families -- Key: CASSANDRA-556 URL: https://issues.apache.org/jira/browse/CASSANDRA-556 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Chris Were Assignee: Dave Brosius Priority: Minor Labels: lhf Fix For: 1.1.1 It would be good to support dumping specific column families via nodeprobe for backup purposes. In my particular case the majority of cassandra data doesn't need to be backed up except for a couple of column families containing user settings / profiles etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3946) BulkRecordWriter shouldn't stream any empty data/index files that might be created at end of flush
[ https://issues.apache.org/jira/browse/CASSANDRA-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3946: - Assignee: Yuki Morishita (was: Brandon Williams) Yuki, does anything look suspicious in BulkRecordWriter for zero-length file creation? BulkRecordWriter shouldn't stream any empty data/index files that might be created at end of flush -- Key: CASSANDRA-3946 URL: https://issues.apache.org/jira/browse/CASSANDRA-3946 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Yuki Morishita Priority: Minor Fix For: 1.1.1 Attachments: 0001-CASSANDRA-3946-BulkRecordWriter-shouldn-t-stream-any.patch If by chance, we flush sstables during BulkRecordWriter (we have seen it happen), I want to make sure we don't try to stream them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4140) Build stress classes in a location that allows tools/stress/bin/stress to find them
[ https://issues.apache.org/jira/browse/CASSANDRA-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4140: - Assignee: Vijay Build stress classes in a location that allows tools/stress/bin/stress to find them --- Key: CASSANDRA-4140 URL: https://issues.apache.org/jira/browse/CASSANDRA-4140 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Nick Bailey Assignee: Vijay Priority: Trivial Fix For: 1.2 Right now its hard to run stress from a checkout of trunk. You need to do 'ant artifacts' and then run the stress tool in the generated artifacts. A discussion on irc came up with the proposal to just move stress to the main jar, but the stress/stressd bash scripts in bin/, and drop the tools directory altogether. It will be easier for users to find that way and will make running stress from a checkout much easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3710) Add a configuration option to disable snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3710: - Assignee: Dave Brosius Dave, can you add an option that allows disabling automatic snapshots for drop/truncate? (but that does not block explicitly requested snapshots) Add a configuration option to disable snapshots --- Key: CASSANDRA-3710 URL: https://issues.apache.org/jira/browse/CASSANDRA-3710 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams Assignee: Dave Brosius Priority: Minor Attachments: Cassandra107Patch_TestModeV1.txt Let me first say, I hate this idea. It gives cassandra the ability to permanently delete data at a large scale without any means of recovery. However, I've seen this requested multiple times, and it is in fact useful in some scenarios, such as when your application is using an embedded cassandra instance for testing and need to truncate, which without JNA will timeout more often than not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4118) ConcurrentModificationException in ColumnFamily.updateDigest(ColumnFamily.java:294) (cassandra 1.0.8)
[ https://issues.apache.org/jira/browse/CASSANDRA-4118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4118: - Assignee: Vijay Hmm, ReadResponse uses ArrayBackedSortedColumns for its ColumnFamily objects, so I see why a CME could happen in that respect. What I don't see is where we modify the CF columns post-construction. ConcurrentModificationException in ColumnFamily.updateDigest(ColumnFamily.java:294) (cassandra 1.0.8) -- Key: CASSANDRA-4118 URL: https://issues.apache.org/jira/browse/CASSANDRA-4118 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.8 Environment: two nodes, replication factor=2 Reporter: Zklanu Ryś Assignee: Vijay Fix For: 1.0.10, 1.1.0 Sometimes when reading data I receive them without any exception but I can see in Cassandra logs, that there is an error: ERROR [ReadRepairStage:58] 2012-04-05 12:04:35,732 AbstractCassandraDaemon.java (line 139) Fatal exception in thread Thread[ReadRepairStage:58,5,main] java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.apache.cassandra.db.ColumnFamily.updateDigest(ColumnFamily.java:294) at org.apache.cassandra.db.ColumnFamily.digest(ColumnFamily.java:288) at org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:102) at org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:30) at org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.runMayThrow(ReadCallback.java:227) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4115) UNREACHABLE schema after decommissioning a non-seed node
[
https://issues.apache.org/jira/browse/CASSANDRA-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4115:
-
Assignee: Brandon Williams
Tyler, what version(s) did you observer this against?
UNREACHABLE schema after decommissioning a non-seed node
Key: CASSANDRA-4115
URL: https://issues.apache.org/jira/browse/CASSANDRA-4115
Project: Cassandra
Issue Type: Bug
Environment: ccm using the following unavailable_schema_test.py dtest.
Reporter: Tyler Patterson
Assignee: Brandon Williams
Priority: Minor
decommission a non-seed node, sleep 30 seconds, then use thrift to check the
schema. UNREACHABLE is listed:
{'75dc4c07-3c1a-3013-ad7d-11fb34208465': ['127.0.0.1'],
'UNREACHABLE': ['127.0.0.2']}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3946) BulkRecordWriter shouldn't stream any empty data/index files that might be created at end of flush
[ https://issues.apache.org/jira/browse/CASSANDRA-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3946: - Assignee: Brandon Williams (was: Chris Goffinet) Sounds like the right fix here is to make BRW not output zero-length sstables. BulkRecordWriter shouldn't stream any empty data/index files that might be created at end of flush -- Key: CASSANDRA-3946 URL: https://issues.apache.org/jira/browse/CASSANDRA-3946 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Brandon Williams Priority: Minor Fix For: 1.1.0 Attachments: 0001-CASSANDRA-3946-BulkRecordWriter-shouldn-t-stream-any.patch If by chance, we flush sstables during BulkRecordWriter (we have seen it happen), I want to make sure we don't try to stream them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3617) Clean up and optimize Message
[ https://issues.apache.org/jira/browse/CASSANDRA-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3617: - Assignee: Yuki Morishita (was: Jonathan Ellis) Rebased and updated at https://github.com/jbellis/cassandra/branches/3617-6. I've added serializedSize for the streaming, gms, and dht classes. The gossip part is tested to work under ccm. The db package still needs serializedSize support as described above. Clean up and optimize Message - Key: CASSANDRA-3617 URL: https://issues.apache.org/jira/browse/CASSANDRA-3617 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Yuki Morishita Fix For: 1.2 The Message class has grown largely by accretion and it shows. There are several problems: - Outbound and inbound messages aren't really the same thing and should not be conflated - We pre-serialize message bodies to byte[], then copy those bytes onto the Socket buffer, instead of just keeping a reference to the object being serialized and then writing it out directly to the socket - MessagingService versioning is poorly encapsulating, scattering version variables and references to things like CachingMessageProducer across the codebase -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4103) Add stress tool to binaries
[ https://issues.apache.org/jira/browse/CASSANDRA-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4103: - Assignee: Vijay Vijay, is this something you could punch out? Add stress tool to binaries --- Key: CASSANDRA-4103 URL: https://issues.apache.org/jira/browse/CASSANDRA-4103 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Rick Branson Assignee: Vijay Priority: Minor It would be great to also get the stress tool packaged along with the binaries. Many people don't even know it exists because it's not distributed with them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4093) cli - show keyspaces throws exception (and swallows) on column family schema_columnfamilies
[ https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4093: - Assignee: Pavel Yaskevich cli - show keyspaces throws exception (and swallows) on column family schema_columnfamilies Key: CASSANDRA-4093 URL: https://issues.apache.org/jira/browse/CASSANDRA-4093 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Dave Brosius Assignee: Pavel Yaskevich Priority: Trivial the CompositeType validator throws exception on first column String columnName = columnNameValidator.getString(columnDef.name); Because it appears the composite type length header is wrong (25455) AbstractCompositeType.getWithShortLength java.lang.IllegalArgumentException at java.nio.Buffer.limit(Buffer.java:247) at org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50) at org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59) at org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139) at org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046) at org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969) at org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574) (seen in trunk) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4083) cqlsh fails to list counter CF
[
https://issues.apache.org/jira/browse/CASSANDRA-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4083:
-
Assignee: paul cannon
cqlsh fails to list counter CF
--
Key: CASSANDRA-4083
URL: https://issues.apache.org/jira/browse/CASSANDRA-4083
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.0.8
Reporter: Radim Kolar
Assignee: paul cannon
1.
These rows displayed are tombstones, they should not be displayed at all
2.
It fails on first counter
cqlsh select * from whois.ipbans;
KEY,80.65.56.165
KEY,ACA35681.ipt.aol.com
KEY,204.229.100.77
KEY,31.223.184.51
KEY,75.144.148.1
KEY,189.27.59.210
KEY,111.191.88.7
KEY,152.26.21.2
KEY,81.43.98.238
KEY,64.71.194.172
KEY,189.83.117.145
KEY,159.0.53.197
KEY,190.236.203.195
KEY,130.255.163.20
Traceback (most recent call last):
File /usr/local/bin/cqlsh, line 580, in onecmd
self.handle_statement(st)
File /usr/local/bin/cqlsh, line 605, in handle_statement
return custom_handler(parsed)
File /usr/local/bin/cqlsh, line 662, in do_select
self.perform_statement_as_tokens(parsed.matched, decoder=decoder)
File /usr/local/bin/cqlsh, line 665, in perform_statement_as_tokens
return self.perform_statement(cqlhandling.cql_detokenize(tokens),
decoder=decoder)
File /usr/local/bin/cqlsh, line 692, in perform_statement
self.print_result(self.cursor)
File /usr/local/bin/cqlsh, line 729, in print_result
self.print_dynamic_result(cursor)
File /usr/local/bin/cqlsh, line 764, in print_dynamic_result
colvals = [self.myformat_value(val, casstype) for (val, casstype) in
zip(row, coltypes)]
File /usr/local/bin/cqlsh, line 402, in myformat_value
float_precision=self.display_float_precision)
File /usr/local/bin/cqlsh, line 346, in format_value
escapedval = val.replace('\\', '')
AttributeError: 'int' object has no attribute 'replace'
[default@whois] list ipbans;
Using default limit of 100
---
RowKey: 80.65.56.165
---
RowKey: ACA35681.ipt.aol.com
---
RowKey: 204.229.100.77
---
RowKey: 31.223.184.51
---
RowKey: 75.144.148.1
---
RowKey: 189.27.59.210
---
RowKey: 111.191.88.7
---
RowKey: 152.26.21.2
---
RowKey: 81.43.98.238
---
RowKey: 64.71.194.172
---
RowKey: 189.83.117.145
---
RowKey: 159.0.53.197
---
RowKey: 190.236.203.195
---
RowKey: 130.255.163.20
---
RowKey: 80.248.237.157
= (counter=hits, value=4)
---
create column family ipbans
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'CounterColumnType'
and key_validation_class = 'AsciiType'
and rows_cached = 500.0
and row_cache_save_period = 0
and row_cache_keys_to_save = 2147483647
and keys_cached = 5.0
and key_cache_save_period = 14400
and read_repair_chance = 0.2
and gc_grace = 86400
and min_compaction_threshold = 2
and max_compaction_threshold = 32
and replicate_on_write = true
and row_cache_provider = 'ConcurrentLinkedHashCacheProvider'
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and comment = 'number of queries per IP address'
and column_metadata = [
{column_name : 'hits',
validation_class : CounterColumnType}];
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4075) Dropped keyspaces and cfs do not get deleted
[ https://issues.apache.org/jira/browse/CASSANDRA-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4075: - Assignee: (was: Yuki Morishita) Dropped keyspaces and cfs do not get deleted Key: CASSANDRA-4075 URL: https://issues.apache.org/jira/browse/CASSANDRA-4075 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: Joaquin Casares Labels: datastax_qa Tested in 0.8.10, reported in 0.8.1. Dropped keyspaces and column families have their sstables marked as Compacted, but will not disappear, even on restart. Worked correctly in 1.0.8 where the sstables get deleted almost immediately following the column family drop. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4078) StackOverflowError when upgrading to 1.0.8 from 0.8.10
[ https://issues.apache.org/jira/browse/CASSANDRA-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4078: - Assignee: paul cannon Looks like a problem w/ the intervaltree creation. StackOverflowError when upgrading to 1.0.8 from 0.8.10 -- Key: CASSANDRA-4078 URL: https://issues.apache.org/jira/browse/CASSANDRA-4078 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.10 Environment: OS: Linux xps.openfin 2.6.35.13-91.fc14.i686 #1 SMP Tue May 3 13:36:36 UTC 2011 i686 i686 i386 GNU/Linux Java: JVM vendor/version: Java HotSpot(TM) Server VM/1.6.0_31 Reporter: Wenjun Assignee: paul cannon Fix For: 0.8.10 Attachments: system.log Hello I am trying to upgrade our 1-node setup from 0.8.10 to 1.0.8 and seeing the following exception when starting up 1.0.8. We have been running 0.8.10 without any issues. Attached is the entire log file during startup of 1.0.8. There are 2 exceptions: 1. StackOverflowError (line 2599) 2. InstanceAlreadyExistsException (line 3632) I tried run scrub under 0.8.10 first, it did not help. Also, I tried dropping the column family which caused the exception, it just got the same exceptions from another column family. Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4075) Dropped keyspaces and cfs do not get deleted
[ https://issues.apache.org/jira/browse/CASSANDRA-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4075: - Assignee: Yuki Morishita Dropped keyspaces and cfs do not get deleted Key: CASSANDRA-4075 URL: https://issues.apache.org/jira/browse/CASSANDRA-4075 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: Joaquin Casares Assignee: Yuki Morishita Labels: datastax_qa Tested in 0.8.10, reported in 0.8.1. Dropped keyspaces and column families have their sstables marked as Compacted, but will not disappear, even on restart. Worked correctly in 1.0.8 where the sstables get deleted almost immediately following the column family drop. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3794) Change ColumnFamily identifiers to be UUIDs instead of sequential Integers.
[ https://issues.apache.org/jira/browse/CASSANDRA-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3794: - Assignee: (was: Pavel Yaskevich) I believe Pavel is working on other things now (he can correct me if I am wrong) so I am clearing the assignment in case someone else can tackle it. Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. --- Key: CASSANDRA-3794 URL: https://issues.apache.org/jira/browse/CASSANDRA-3794 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Pavel Yaskevich Priority: Minor Fix For: 1.2 Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. Would be useful in the situation when nodes simultaneously trying to create ColumnFamilies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4063) Expose nodetool cfhistograms for secondary index CFs
[
https://issues.apache.org/jira/browse/CASSANDRA-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4063:
-
Assignee: Brandon Williams
At worst we should be able to use our schema knowledge to know if we should
query with ICF or CF type.
Expose nodetool cfhistograms for secondary index CFs
Key: CASSANDRA-4063
URL: https://issues.apache.org/jira/browse/CASSANDRA-4063
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Tyler Hobbs
Assignee: Brandon Williams
Priority: Minor
Labels: jmx
With the ObjectName that NodeProbe uses, the JMX query can only match mbeans
with type ColumnFamilies. Secondary index CFs have a type of
IndexColumnFamilies, so the query won't match them.
The [ObjectName
documentation|http://docs.oracle.com/javase/6/docs/api/javax/management/ObjectName.html]
indicates that you can use wildcards, which would be the perfect solution if
it actually worked. I'm not sure if it's some quoted vs non-quoted pattern
issue, or if it's particular to the {{newMBeanProxy()}} method, but I could
not get wildcards to match the secondary index CFs. Explicitly setting the
type field to IndexColumnFamilies did work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3954:
-
Assignee: Pavel Yaskevich
Been thinking about this for a while, and I now have a hypothesis: I bet it's
some kind of confusion w/ the new unified key cache. Can you have a look, Pavel?
Exceptions during start up after schema disagreement
Key: CASSANDRA-3954
URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
Project: Cassandra
Issue Type: Bug
Reporter: Mariusz
Assignee: Pavel Yaskevich
Hi,
i`ve got schema disaggreement after dropping down keyspace,
i`ve switched off one nodes in cluster, after starting i`ve got bunch of
these exceptions:
{code}
ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
AbstractCassandraDaemon.java (line 134) Fatal exception in thread
Thread[SSTableBatchOpen:1,5,main]
java.lang.ClassCastException: java.math.BigInteger cannot be cast to
java.nio.ByteBuffer
at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
at
org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
at
org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
at java.util.TreeMap.getEntry(TreeMap.java:328)
at java.util.TreeMap.containsKey(TreeMap.java:209)
at java.util.TreeSet.contains(TreeSet.java:217)
at
org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
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:662)
{code}
and this one on the end of start up:
{code}
ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
(line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
at
org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
at
org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
at
org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
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:662)
{code}
Any ideas why they`ve appeared?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4031) Exceptions during inserting emtpy string as column value on indexed column
[
https://issues.apache.org/jira/browse/CASSANDRA-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-4031:
-
Assignee: Yuki Morishita
Exceptions during inserting emtpy string as column value on indexed column
--
Key: CASSANDRA-4031
URL: https://issues.apache.org/jira/browse/CASSANDRA-4031
Project: Cassandra
Issue Type: Bug
Reporter: Mariusz
Assignee: Yuki Morishita
Hi,
I`m running one node cluster(issue occurs also on other cluster(which has 2
nodes)) on snapshot from cassandra-1.1 branch(i used
449e037195c3c504d7aca5088e8bc7bd5a50e7d0 commit).
i have simple CF, definition of TestCF:
{noformat}
[default@test_keyspace] describe Test_CF;
ColumnFamily: Test_CF
Key Validation Class: org.apache.cassandra.db.marshal.UTF8Type
Default column value validator: org.apache.cassandra.db.marshal.UTF8Type
Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 1.0
DC Local Read repair chance: 0.0
Replicate on write: true
Caching: KEYS_ONLY
Bloom Filter FP chance: default
Built indexes: [Test_CF.Test_CF_test_index_idx]
Column Metadata:
Column Name: test_index
Validation Class: org.apache.cassandra.db.marshal.UTF8Type
Index Name: Test_CF_test_index_idx
Index Type: KEYS
Compaction Strategy:
org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
Compression Options:
sstable_compression: org.apache.cassandra.io.compress.SnappyCompressor
{noformat}
I`m trying to add new row(log from cassandra-cli, note that there is index on
test_index):
{noformat}
[default@test_keyspace] list Test_CF;
Using default limit of 100
0 Row Returned.
Elapsed time: 31 msec(s).
[default@test_keyspace] set Test_CF[absdsad3][test_index]='';
null
TimedOutException()
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15906)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:788)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:772)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:894)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:211)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:219)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:346)
[default@test_keyspace] list Test_CF;
Using default limit of 100
---
RowKey: absdsad3
= (column=test_index, value=, timestamp=1331298173009000)
1 Row Returned.
Elapsed time: 7 msec(s).
{noformat}
Exception from system.log:
{noformat}
INFO [FlushWriter:56] 2012-03-09 13:42:02,500 Memtable.java (line 291)
Completed flushing
/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-hc-3251-Data.db
(2077 bytes)
ERROR [MutationStage:2291] 2012-03-09 13:42:22,232
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[MutationStage:2291,5,main]
java.lang.AssertionError
at org.apache.cassandra.db.DecoratedKey.init(DecoratedKey.java:55)
at
org.apache.cassandra.db.index.SecondaryIndexManager.getIndexKeyFor(SecondaryIndexManager.java:294)
at
org.apache.cassandra.db.index.SecondaryIndexManager.applyIndexUpdates(SecondaryIndexManager.java:490)
at org.apache.cassandra.db.Table.apply(Table.java:441)
at org.apache.cassandra.db.Table.apply(Table.java:366)
at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:275)
at
org.apache.cassandra.service.StorageProxy$6.runMayThrow(StorageProxy.java:446)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1228)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4023) Improve BloomFilter deserialization performance
[ https://issues.apache.org/jira/browse/CASSANDRA-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-4023: - Assignee: Yuki Morishita (was: Jonathan Ellis) Improve BloomFilter deserialization performance --- Key: CASSANDRA-4023 URL: https://issues.apache.org/jira/browse/CASSANDRA-4023 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.1 Reporter: Joaquin Casares Assignee: Yuki Morishita Priority: Minor Labels: datastax_qa Fix For: 1.0.9, 1.1.0 Attachments: 4023.txt The difference of startup times between a 0.8.7 cluster and 1.0.7 cluster with the same amount of data is 4x greater in 1.0.7. It seems as though 1.0.7 loads the BloomFilter through a series of reading longs out in a multithreaded process while 0.8.7 reads the entire object. Perhaps we should update the new BloomFilter to do reading in batch as well? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3885) Support multiple ranges in SliceQueryFilter
[ https://issues.apache.org/jira/browse/CASSANDRA-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3885: - Assignee: (was: Todd Nine) Support multiple ranges in SliceQueryFilter --- Key: CASSANDRA-3885 URL: https://issues.apache.org/jira/browse/CASSANDRA-3885 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Fix For: 1.2 This is logically a subtask of CASSANDRA-2710, but Jira doesn't allow sub-sub-tasks. We need to support multiple ranges in a SliceQueryFilter, and we want querying them to be efficient, i.e., one pass through the row to get all of the ranges, rather than one pass per range. Supercolumns are irrelevant since the goal is to replace them anyway. Ignore supercolumn-related code or rip it out, whichever is easier. This is ONLY dealing with the storage engine part, not the StorageProxy and Command intra-node messages or the Thrift or CQL client APIs. Thus, a unit test should be added to ColumnFamilyStoreTest to demonstrate that it works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3963) Exception durint start up after updating cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3963:
-
Assignee: Pavel Yaskevich
Exception durint start up after updating cassandra
--
Key: CASSANDRA-3963
URL: https://issues.apache.org/jira/browse/CASSANDRA-3963
Project: Cassandra
Issue Type: Bug
Reporter: Mariusz
Assignee: Pavel Yaskevich
Hi,
i`ve updated cassandra on two-nodes cluster and i`ve got this exception
during start up:
{code}
INFO 09:06:06,520 Opening
/cassandra/system/HintsColumnFamily/system-HintsColumnFamily-hc-1 (178828054
bytes)
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:160)
Caused by: java.lang.NullPointerException
at
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:384)
at
org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:332)
at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:156)
at
org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:514)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182)
at
org.apache.cassandra.service.AbstractCassandraDaemon.init(AbstractCassandraDaemon.java:254)
... 5 more
Cannot load daemon
Service exit with a return value of 3
{code}
we`re running 2 node cluster on snapshots from cassandra-1.1 branch:
* old snapshot: 5f5e00bc9a83bfd701723cbc7bf2307ea53da342 + patches from
CASSANDRA-3740
* new snapshot: d65590ac8a5a3cfbe1529ef77346e84d6961db7d
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3970) JVM crash in streamingTransferTest on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3970:
-
Assignee: Sylvain Lebresne
JVM crash in streamingTransferTest on Windows
-
Key: CASSANDRA-3970
URL: https://issues.apache.org/jira/browse/CASSANDRA-3970
Project: Cassandra
Issue Type: Bug
Components: Tests
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Fix For: 1.1.0
Attachments: hs_err_pid95744.log
{noformat}
$ ant test -Dtest.name=StreamingTransferTest
...
[junit] Testsuite: org.apache.cassandra.streaming.StreamingTransferTest
[junit] #
[junit] # A fatal error has been detected by the Java Runtime Environment:
[junit] #
[junit] # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6da5ccca,
pid=95744, tid=94924
[junit] #
[junit] # JRE version: 6.0_27-b07
[junit] # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.2-b06 mixed mode
windows-amd64 compressed oops)
[junit] # Problematic frame:
[junit] # V [jvm.dll+0x1a]
[junit] #
[junit] # An error report file with more information is saved as:
[junit] # c:\Users\Jonathan\projects\cassandra\git\hs_err_pid95744.log
[junit] #
[junit] # If you would like to submit a bug report, please visit:
[junit] # http://java.sun.com/webapps/bugreport/crash.jsp
[junit] #
[junit] Testsuite: org.apache.cassandra.streaming.StreamingTransferTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase:
org.apache.cassandra.streaming.StreamingTransferTest:testTransferTable:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the report
does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time
until the VM exit.
[junit]
[junit]
[junit] Test org.apache.cassandra.streaming.StreamingTransferTest FAILED
(crashed)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3423) Log useful information about CF configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3423: - Assignee: (was: Jonathan Ellis) Log useful information about CF configuration - Key: CASSANDRA-3423 URL: https://issues.apache.org/jira/browse/CASSANDRA-3423 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Priority: Minor Labels: lhf Fix For: 1.0.9 It would help troubleshooting if we logged pertinent details about CF configuration (particularly cache size) on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3885) Support multiple ranges in SliceQueryFilter
[ https://issues.apache.org/jira/browse/CASSANDRA-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3885: - Assignee: Todd Nine Support multiple ranges in SliceQueryFilter --- Key: CASSANDRA-3885 URL: https://issues.apache.org/jira/browse/CASSANDRA-3885 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Todd Nine Fix For: 1.2 This is logically a subtask of CASSANDRA-2710, but Jira doesn't allow sub-sub-tasks. We need to support multiple ranges in a SQF, and we want querying them to be efficient, i.e., one pass through the row to get all of the ranges, rather than one pass per range. Supercolumns are irrelevant since the goal is to replace them anyway. Ignore supercolumn-related code or rip it out, whichever is easier. This is ONLY dealing with the storage engine part, not the StorageProxy and Command intra-node messages or the Thrift or CQL client APIs. Thus, a unit test should be added to ColumnFamilyStoreTest to demonstrate that it works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3871) Turn compression on by default
[ https://issues.apache.org/jira/browse/CASSANDRA-3871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3871: - Assignee: Pavel Yaskevich (was: Jonathan Ellis) Turn compression on by default -- Key: CASSANDRA-3871 URL: https://issues.apache.org/jira/browse/CASSANDRA-3871 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 1.1 Compression has been available but off by default since 1.0.0. It's enabled in a lot of production environments now, with no major problems found. (Some problems with customizing the block size were found and fixed in the 1.0 releases.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3849) Saved CF row cache breaks when upgrading to 1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3849:
-
Assignee: Sylvain Lebresne
Saved CF row cache breaks when upgrading to 1.1
---
Key: CASSANDRA-3849
URL: https://issues.apache.org/jira/browse/CASSANDRA-3849
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1
Environment: 1 node cluster running on branch cassandra-1.0. Ubuntu.
both key and row caching were enabled.
Reporter: Tyler Patterson
Assignee: Sylvain Lebresne
Enabled row and key caching. Used stress to insert some data. ran nodetool
flush, then nodetool compact. Then read the data back to populate the cache.
Turned row_cache_save_period and key_cache_save_period really low to force
saving the cache data. I verified that the row and key cache files existed in
/var/lib/cassandra/saved_caches/.
I then killed cassandra, checked out branch cassandra-1.1, compiled and tried
to start the node. The node failed to start, and I got this error:
{code}
INFO 01:33:30,893 reading saved cache
/var/lib/cassandra/saved_caches/Keyspace1-Standard1-RowCache
ERROR 01:33:31,009 Exception encountered during startup
java.lang.AssertionError: Row cache is not enabled on column family
[Standard1]
at
org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1050)
at
org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:383)
at org.apache.cassandra.db.Table.open(Table.java:122)
at org.apache.cassandra.db.Table.open(Table.java:100)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)
java.lang.AssertionError: Row cache is not enabled on column family
[Standard1]
at
org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1050)
at
org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:383)
at org.apache.cassandra.db.Table.open(Table.java:122)
at org.apache.cassandra.db.Table.open(Table.java:100)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)
Exception encountered during startup: Row cache is not enabled on column
family [Standard1]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3740) While using BulkOutputFormat unneccessarily look for the cassandra.yaml file.
[
https://issues.apache.org/jira/browse/CASSANDRA-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3740:
-
Assignee: Brandon Williams
While using BulkOutputFormat unneccessarily look for the cassandra.yaml file.
--
Key: CASSANDRA-3740
URL: https://issues.apache.org/jira/browse/CASSANDRA-3740
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 1.1
Reporter: Samarth Gahire
Assignee: Brandon Williams
Labels: cassandra, configuration, hadoop, mapreduce, test
Fix For: 1.1
Original Estimate: 72h
Remaining Estimate: 72h
I am trying to use BulkOutputFormat to stream the data from map of Hadoop
job. I have set the cassandra related configuration using ConfigHelper ,Also
have looked into Cassandra code seems Cassandra has taken care that it should
not look for the cassandra.yaml file.
But still when I run the job i get the following error:
{
12/01/13 11:30:04 WARN mapred.JobClient: Use GenericOptionsParser for parsing
the arguments. Applications should implement Tool for the same.
12/01/13 11:30:04 INFO input.FileInputFormat: Total input paths to process : 1
12/01/13 11:30:04 INFO mapred.JobClient: Running job: job_201201130910_0015
12/01/13 11:30:05 INFO mapred.JobClient: map 0% reduce 0%
12/01/13 11:30:23 INFO mapred.JobClient: Task Id :
attempt_201201130910_0015_m_00_0, Status : FAILED
java.lang.Throwable: Child Error
at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:271)
Caused by: java.io.IOException: Task process exit with nonzero status of 1.
at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:258)
attempt_201201130910_0015_m_00_0: Cannot locate cassandra.yaml
attempt_201201130910_0015_m_00_0: Fatal configuration error; unable to
start server.
}
Also let me know how can i make this cassandra.yaml file available to Hadoop
mapreduce job?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2940) Make rpc_timeout_in_ms into a jmx mbean property
[ https://issues.apache.org/jira/browse/CASSANDRA-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2940: - Assignee: Ruben Terrazas Make rpc_timeout_in_ms into a jmx mbean property Key: CASSANDRA-2940 URL: https://issues.apache.org/jira/browse/CASSANDRA-2940 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jeremy Hanna Assignee: Ruben Terrazas Labels: jmx, lhf Fix For: 1.0.7 Attachments: trunk-CASSANDRA-2940.txt, trunk-CASSANDRA-2940.txt When using the hadoop integration especially, experimenting with rpc_timeout_in_ms is a pain if you have to restart every server in the cluster for it to take effect. This would be an improvement to make it into a jmx mbean property to set it at runtime. The yaml file could be updated separately so it would be persistent still. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3714) Show Schema; inserts an extra comma in column_metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3714:
-
Assignee: Yuki Morishita
Show Schema; inserts an extra comma in column_metadata
--
Key: CASSANDRA-3714
URL: https://issues.apache.org/jira/browse/CASSANDRA-3714
Project: Cassandra
Issue Type: Bug
Reporter: Joaquin Casares
Assignee: Yuki Morishita
Fix For: 1.0.5
create column family inode
with column_type = 'Standard'
and comparator =
'DynamicCompositeType(t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,b=org.apache.cassandra.db.marshal.BytesType)'
and default_validation_class = 'BytesType'
and key_validation_class = 'BytesType'
and rows_cached = 0.0
and row_cache_save_period = 0
and row_cache_keys_to_save = 2147483647
and keys_cached = 100.0
and key_cache_save_period = 14400
and read_repair_chance = 1.0
and gc_grace = 60
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = true
and row_cache_provider = 'ConcurrentLinkedHashCacheProvider'
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and comment = 'Stores file meta data'
and column_metadata = [
{column_name : 'b@70617468',
validation_class : BytesType,
index_name : 'path',
index_type : 0,
},
{column_name : 'b@73656e74696e656c',
validation_class : BytesType,
index_name : 'sentinel',
index_type : 0,
},
{column_name : 'b@706172656e745f70617468',
validation_class : BytesType,
index_name : 'parent_path',
index_type : 0,
}];
That's that was outputted when I ran show schema. When I tried it on a new
cluster, it failed since the commas after 'index_type: 0' were present.
Proposed fixes:
1. Allow trailing commas
2. Do not output trailing commas
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2878) Filter out ColumnFamily rows that aren't part of the query (using a IndexClause)
[ https://issues.apache.org/jira/browse/CASSANDRA-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2878: - Assignee: Jonathan Ellis (was: Mck SembWever) Filter out ColumnFamily rows that aren't part of the query (using a IndexClause) Key: CASSANDRA-2878 URL: https://issues.apache.org/jira/browse/CASSANDRA-2878 Project: Cassandra Issue Type: New Feature Components: Hadoop Reporter: Mck SembWever Assignee: Jonathan Ellis Priority: Minor Fix For: 1.1 Currently, when running a MapReduce job against data in a Cassandra data store, it reads through all the data for a particular ColumnFamily. This could be optimized to only read through those rows that have to do with the query. It's a small change but wanted to put it in Jira so that it didn't fall through the cracks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3668) Performance of sstableloader is affected in 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3668: - Assignee: Yuki Morishita Can you tell us how to reproduce? What kind of degradation are you seeing? Performance of sstableloader is affected in 1.0.x - Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.0.7 Reporter: Manish Zope Assignee: Yuki Morishita Fix For: 1.0.7 Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3604) Bad code in org.apache.cassandra.cql.QueryProcessor
[ https://issues.apache.org/jira/browse/CASSANDRA-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3604: - Assignee: Sylvain Lebresne Bad code in org.apache.cassandra.cql.QueryProcessor --- Key: CASSANDRA-3604 URL: https://issues.apache.org/jira/browse/CASSANDRA-3604 Project: Cassandra Issue Type: Bug Affects Versions: 1.1 Environment: all Reporter: Zoltan Farkas Assignee: Sylvain Lebresne Original Estimate: 5m Remaining Estimate: 5m line 206: if (rows.get(0).key.key.equals(startKey)) rows.remove(0); the equals will always return false because object of different types are compared -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3589) Degraded performance of sstable-generator api and sstable-loader utility in cassandra 1.0.x
[ https://issues.apache.org/jira/browse/CASSANDRA-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3589: - Assignee: Sylvain Lebresne Degraded performance of sstable-generator api and sstable-loader utility in cassandra 1.0.x --- Key: CASSANDRA-3589 URL: https://issues.apache.org/jira/browse/CASSANDRA-3589 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.0 Reporter: Samarth Gahire Assignee: Sylvain Lebresne Priority: Minor we are using Sstable-Generation API and Sstable-Loader utility.As soon as newer version of cassandra releases I test them for sstable generation and loading for time taken by both the processes.Till cassandra 0.8.7 there is no significant change in time taken.But in all cassandra-1.0.x i have seen 3-4 times degraded performance in generation and 2 times degraded performance in loading.Because of this we are not upgrading the cassandra to latest version as we are processing some TeraBytes of data everyday time taken is very important. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3587) DESC alias for DESCRIBE keyword in CQL shell
[ https://issues.apache.org/jira/browse/CASSANDRA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3587: - Assignee: paul cannon DESC alias for DESCRIBE keyword in CQL shell Key: CASSANDRA-3587 URL: https://issues.apache.org/jira/browse/CASSANDRA-3587 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Robin Schumacher Assignee: paul cannon Priority: Minor Allow DESC to be used instead of full DESCRIBE keyword. MySQL and Oracle users are used to DESC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3521) sstableloader throwing exceptions when loading snapshot data from compressed CFs
[
https://issues.apache.org/jira/browse/CASSANDRA-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3521:
-
Assignee: Yuki Morishita
sstableloader throwing exceptions when loading snapshot data from compressed
CFs
Key: CASSANDRA-3521
URL: https://issues.apache.org/jira/browse/CASSANDRA-3521
Project: Cassandra
Issue Type: Bug
Environment: One node cluster (same problem with 4 nodes ) and
dedicated machine for sstable loader.
node and loader running jdk1.6.0_29 and cassandra-1.0.3
Reporter: Peter Velas
Assignee: Yuki Morishita
Loaded data from snapshot then enabled `sstable_compression:
org.apache.cassandra.io.compress.SnappyCompressor`
Then flush, scrub and compact. I can see actual CompressionRatio in JMX
Console and access my data without problems..
Now I snapshot compressed keyspace and when trying to load snapshot to
another single node or different Keyspace (the same super CF structure with
compression options enabled, even try to truncate snapshoted CFs.) I cant
load any data.
sstableloader command with debug mode dont throw any errors and shows its
streaming
{quote}
sstableloader-cassandra_2/bin/sstableloader --debug Impressions_compressed/
{quote}
Node logs contains repeating the errors bellow.
{quote}
ERROR [Thread-319] 2011-11-22 09:56:01,931 AbstractCassandraDaemon.java (line
133) Fatal exception in thread Thread[Thread-319,5,main]
java.lang.AssertionError: attempted to delete non-existing file
HidSaid-tmp-hb-260-Data.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:49)
at
org.apache.cassandra.streaming.IncomingStreamReader.retry(IncomingStreamReader.java:170)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:92)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:184)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:81)
INFO [Thread-320] 2011-11-22 09:56:02,492 StreamInSession.java (line 120)
Streaming of file Impressions_compressed/HidSaid-hb-9-Data.db sections=1
progress=0/5616749 - 0% from
org.apache.cassandra.streaming.StreamInSession@3cc62c07 failed: requesting a
retry.
ERROR [Thread-320] 2011-11-22 09:56:02,493 AbstractCassandraDaemon.java (line
133) Fatal exception in thread Thread[Thread-320,5,main]
java.lang.AssertionError: attempted to delete non-existing file
HidSaid-tmp-hb-261-Data.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:49)
at
org.apache.cassandra.streaming.IncomingStreamReader.retry(IncomingStreamReader.java:170)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:92)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:184)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:81)
{quote}
Hope its enough if you need more info just tell me what you need to reproduce
this bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3505) tombstone appears after truncate
[
https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3505:
-
Assignee: Jonathan Ellis (was: Yuki Morishita)
tombstone appears after truncate
Key: CASSANDRA-3505
URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.3
Reporter: Cathy Daw
Assignee: Jonathan Ellis
Fix For: 1.0.4
This bug is regarding the select after the 'truncate'. In 1.0.1 no rows
would ever be returned, but now we are seeing a tombstone when querying for
user1. Jake mentioned this may be related to CASSANDRA-2855.
{code}
cqlsh CREATE KEYSPACE ks1 with
... strategy_class =
... 'org.apache.cassandra.locator.SimpleStrategy'
... and strategy_options:replication_factor=1;
cqlsh use ks1;
cqlsh:ks1
cqlsh:ks1 CREATE COLUMNFAMILY users (
... KEY varchar PRIMARY KEY, password varchar, gender varchar,
... session_token varchar, state varchar, birth_year bigint);
cqlsh:ks1 INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
cqlsh:ks1 UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY =
'user1';
cqlsh:ks1 SELECT * FROM users WHERE key='user1';
KEY | birth_year | gender | password |
user1 | 1980 | m | ch@ngem3a |
cqlsh:ks1 TRUNCATE users;
// Expected, no rows returned
cqlsh:ks1 SELECT * FROM users WHERE key='user1';
KEY |
user1 |
// Expected, no rows returned
cqlsh:ks1 SELECT * FROM users;
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3512) Getting Started instructions don't work in README.txt - wrong version of jamm, wrong path
[
https://issues.apache.org/jira/browse/CASSANDRA-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3512:
-
Assignee: Eric Evans
Right. That's by design. Here's the relevant part of bin/cassandra:
{noformat}
# If an include wasn't specified in the environment, then search for one...
if [ x$CASSANDRA_INCLUDE = x ]; then
# Locations (in order) to use when searching for an include file.
for include in /usr/share/cassandra/cassandra.in.sh \
/usr/local/share/cassandra/cassandra.in.sh \
/opt/cassandra/cassandra.in.sh \
$HOME/.cassandra.in.sh \
`dirname $0`/cassandra.in.sh; do
if [ -r $include ]; then
. $include
break
fi
done
# ...otherwise, source the specified include.
elif [ -r $CASSANDRA_INCLUDE ]; then
. $CASSANDRA_INCLUDE
fi
{noformat}
However, my experience matches yours, that virtually everyone when running
bin/cassandra manually expects it to use the files in bin/ and conf/ rather
than global package-installed ones. (Assigning to Eric for comment since he
wrote this.)
Getting Started instructions don't work in README.txt - wrong version of
jamm, wrong path
-
Key: CASSANDRA-3512
URL: https://issues.apache.org/jira/browse/CASSANDRA-3512
Project: Cassandra
Issue Type: Bug
Components: Packaging
Affects Versions: 1.0.3
Environment: Ubuntu 11.04
Reporter: David Allsopp
Assignee: Eric Evans
Priority: Minor
Download latest release from
http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.0.3/apache-cassandra-1.0.3-bin.tar.gz
Unpack the tarball.
Follow instructions in README.txt, concluding with:
{noformat}
dna@master:~/code/apache-cassandra-1.0.3$ bin/cassandra -f
Error opening zip file or JAR manifest missing : /lib/jamm-0.2.1.jar
Error occurred during initialization of VM
agent library failed to init: instrument
{noformat}
Firstly, the version of jamm packaged with Cassandra 1.0.3 is jamm-0.2.5, not
jamm-0.2.1.
Both bin/cassandra.bat and conf/cassandra-env.sh reference jamm-0.2.5 so not
sure where jamm-0.2.1 is being referenced from - nothing obvious using grep.
Secondly, /lib/jamm-0.2.1.jar is the wrong path - should be set relative to
working directory, not filesystem root
(Incidentally, Cassandra v1.0.3 is still listed as unreleased on JIRA.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3465) Wrong cunters values when RF 1
[
https://issues.apache.org/jira/browse/CASSANDRA-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3465:
-
Assignee: Sylvain Lebresne
Wrong cunters values when RF 1
Key: CASSANDRA-3465
URL: https://issues.apache.org/jira/browse/CASSANDRA-3465
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Environment: Amazon EC2 (cluster of 5 t1.micro), phpCassa 0.8.a.2
Reporter: Alain RODRIGUEZ
Assignee: Sylvain Lebresne
Priority: Critical
I have got a CF that contains many counters of some events. When I'm at RF =
1 and simulate 10 events, they are well counted.
However, when I switch to a RF = 3, my counter show a wrong value that
sometimes change when requested twice (it can return 7, then 5 instead of 10
all the time).
I first thought that it was a problem of CL because I seem to remember that I
read once that I had to use CL.One for reads and writes with counters. So I
tried with CL.One, without success...
/*-- CODE
---*/
$servers = array(ec2-xxx-xxx-xxx-xxx.eu-west-1.compute.amazonaws.com,
ec2-yyy-yyy-yyy-yyy.eu-west-1.compute.amazonaws.com,
ec2-zzz-zzz-zzz-zzz.eu-west-1.compute.amazonaws.com,
ec2-aaa-aaa-aaa-aaa.eu-west-1.compute.amazonaws.com,
ec2-bbb-bbb-bbb-bbb.eu-west-1.compute.amazonaws.com);
$pool = new ConnectionPool(mykeyspace, $servers);
$stats_test = new ColumnFamily($pool, 'stats_test',
$read_consistency_level=cassandra_ConsistencyLevel::ONE,
$write_consistency_level=cassandra_ConsistencyLevel::ONE);
$time = date( 'YmdH', time());
for($i=0; $i10; $i++){
for($c=1; $c=3; $c++){
$stats_test-add($c, $time.':test');
}
$counts = $stats_test-multiget(array(1,2,3));
echo('Counter1: '.$counts[1][$time.':test'].\n);
echo('Counter2: '.$counts[2][$time.':test'].\n);
echo('Counter3: '.$counts[3][$time.':test'].\n\n);
}
/* END OF CODE
-*/
/*-- OUTPUT
*/
Counter1: 1
Counter2: 1
Counter3: 1
Counter1: 2
Counter2: 2
Counter3: 2
Counter1: 3
Counter2: 3
Counter3: 3
Counter1: 3
Counter2: 4
Counter3: 4
Counter1: 4
Counter2: 5
Counter3: 3
Counter1: 5
Counter2: 6
Counter3: 3
Counter1: 6
Counter2: 7
Counter3: 4
Counter1: 4
Counter2: 8
Counter3: 7
Counter1: 5
Counter2: 9
Counter3: 8
Counter1: 8
Counter2: 4
Counter3: 9
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3461) Server-side fatal exception when mixing column types in DynamicCompositeType
[
https://issues.apache.org/jira/browse/CASSANDRA-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3461:
-
Assignee: Sylvain Lebresne
Server-side fatal exception when mixing column types in DynamicCompositeType
Key: CASSANDRA-3461
URL: https://issues.apache.org/jira/browse/CASSANDRA-3461
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Environment: JDK 1.6.0_26
Reporter: Carlos Carrasco
Assignee: Sylvain Lebresne
Running this CLI script with cause the Cassandra server to throw a fatal
exception, and the CLI to hang for some seconds and then just display null:
create keyspace Test;
use Test;
create column family Composite with comparator ='DynamicCompositeType
(a=AsciiType,s=UTF8Type)';
set Composite[ascii('key')]['s@one']=ascii('value');
set Composite[ascii('key')]['a@two']=ascii('value');
It appears DynamicCompositeType does not allow mixing different types of
components in the same position for the same row, which makes sense, but
shouldn't this be a controled error and passed to the client, instead of
throwing a fatal exception in the server side?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3442) TTL histogram for sstable metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3442: - Assignee: Yuki Morishita (was: Sylvain Lebresne) We can get average column size from row size / column count, so we could make it If column size N bytes or sstable is older than gc_grace_period. TTL histogram for sstable metadata -- Key: CASSANDRA-3442 URL: https://issues.apache.org/jira/browse/CASSANDRA-3442 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Yuki Morishita Priority: Minor Labels: compaction Under size-tiered compaction, you can generate large sstables that compact infrequently. With expiring columns mixed in, we could waste a lot of space in this situation. If we kept a TTL EstimatedHistogram in the sstable metadata, we could do a single-sstable compaction aginst sstables with over 20% (?) expired data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3424) Selecting just the row_key returns nil instead of just the row_key
[
https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3424:
-
Assignee: Pavel Yaskevich
Odd, that should be handled by this code:
{code}
. if (term.getText().equalsIgnoreCase(keyString))
{
// preserve case of key as it was requested
ByteBuffer requestedKey =
ByteBufferUtil.bytes(term.getText());
thriftColumns.add(new
Column(requestedKey).setValue(row.key.key).setTimestamp(-1));
result.schema.name_types.put(requestedKey,
TypeParser.getShortName(AsciiType.instance));
result.schema.value_types.put(requestedKey,
TypeParser.getShortName(metadata.getKeyValidator()));
continue;
}
{code}
Selecting just the row_key returns nil instead of just the row_key
--
Key: CASSANDRA-3424
URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Pavel Yaskevich
Priority: Minor
Labels: cql
CREATE KEYSPACE CassandraCQLTestKeyspace WITH
strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND
strategy_options:replication_factor=1
USE CassandraCQLTestKeyspace
CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY,
test_column text)
INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test
string', 'test')
# Works as expected
SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
# Returns an empty result, unexpected
SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3442) TTL histogram for sstable metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3442: - Assignee: Sylvain Lebresne Sylvain, what do you think of this idea? (If it has merit, we can assign to Yuki for implementation.) TTL histogram for sstable metadata -- Key: CASSANDRA-3442 URL: https://issues.apache.org/jira/browse/CASSANDRA-3442 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor Labels: compaction Under size-tiered compaction, you can generate large sstables that compact infrequently. With expiring columns mixed in, we could waste a lot of space in this situation. If we kept a TTL EstimatedHistogram in the sstable metadata, we could do a single-sstable compaction aginst sstables with over 20% (?) expired data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3407) Changing partitioner causes interval tree build failure before the change can be detected
[ https://issues.apache.org/jira/browse/CASSANDRA-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3407: - Assignee: Yuki Morishita Changing partitioner causes interval tree build failure before the change can be detected - Key: CASSANDRA-3407 URL: https://issues.apache.org/jira/browse/CASSANDRA-3407 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: Linux 2.6.18 Reporter: Zhong Li Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.2 Attachments: 3407-assert-intervals.patch, exception1.txt, system.log, system.log, system.tar.gz After installed 1.0.0 and changed config file cassandra.yaml, restart cassandra and got exception, INFO 22:25:37,727 Opening /srv/opt/cassandra8/data/system/IndexInfo-g-121 (5428 bytes) ERROR 22:25:37,753 Exception encountered during startup_type: 0}, java.lang.StackOverflowError, validation_class: UTF8Type, index_type: 0}, at java.math.BigInteger.compareMagnitude(BigInteger.java:2477) at java.math.BigInteger.compareTo(BigInteger.java:2463)type: 0}, at org.apache.cassandra.dht.BigIntegerToken.compareTo(BigIntegerToken.java:39) at org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:83) at org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38) at java.util.Arrays.mergeSort(Arrays.java:1144)dex_type: 0}, at java.util.Arrays.sort(Arrays.java:1079)dex_type: 0}, at java.util.Collections.sort(Collections.java:117)}, at org.apache.cassandra.utils.IntervalTree.IntervalNode.findMinMedianMax(IntervalNode.java:102) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:43) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:51) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:51) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:51) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:51) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:51) at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:51) . at org.apache.cassandra.utils.IntervalTree.IntervalNode.init(IntervalNode.java:51) at org.apache.cassandra.utils.IntervalTree.IntervalTree.init(IntervalTree.java:38) at org.apache.cassandra.db.DataTracker$View.buildIntervalTree(DataTracker.java:522) at org.apache.cassandra.db.DataTracker$View.replace(DataTracker.java:547) at org.apache.cassandra.db.DataTracker.replace(DataTracker.java:268) at org.apache.cassandra.db.DataTracker.addSSTables(DataTracker.java:237) at org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:216) at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:315) at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:285) at org.apache.cassandra.db.Table.initCf(Table.java:372) at org.apache.cassandra.db.Table.init(Table.java:320) at org.apache.cassandra.db.Table.open(Table.java:121) at org.apache.cassandra.db.Table.open(Table.java:104) at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:215) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:150) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:337) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106) Exception encountered during startup: null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3399) Truncate disregards running compactions when deleting sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3399: - Assignee: Jonathan Ellis (patch is against 1.0, will also commit to 0.8) Truncate disregards running compactions when deleting sstables -- Key: CASSANDRA-3399 URL: https://issues.apache.org/jira/browse/CASSANDRA-3399 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Jonathan Ellis Fix For: 0.8.8, 1.0.2 Attachments: 3399.txt All truncation do is `cfs.markCompacted(truncatedSSTables)` without holding any lock or anything. Which have the effect of actually deleting sstables that may be compacting. More precisely there is three problems: # It removes those compacting sstables from the current set of active sstables for the cfs. But when they are done compacting, DataTracker.replaceCompactedSSTables() will be called and it assumes that the compacted sstable are parts of the current set of active sstables. In other words, we'll get an exception looking like the one of CASSANDRA-3306. # The result of the compaction will be added as a new active sstable (actually no, because the code will throw an exception before because of the preceding point, but that's something we should probably deal with). # Currently, compaction don't 'acquire references' on SSTR. That's because the code assumes we won't compact twice the same sstable and that compaction is the only mean to delete an sstable. With these two assumption, acquiring references is not necessary, but truncate break that first assumption. As for solution, I see two possibilities: # make the compaction lock be per-cf instead of global (which I think is easy and a good idea anyway) and grab the write lock to do the markCompacted call. The big downside is that truncation will potentially take much longer. # had two phases: mark the sstable that are not compacting as compacted and set the dataTracker as 'truncated at', and let it deal with the other sstable when their compaction is done. A bit like what is proposed for CASSANDRA-3116 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3422) Can create a Column Family with comparator CounterColumnType which is subsequently unusable
[ https://issues.apache.org/jira/browse/CASSANDRA-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3422: - Assignee: Sylvain Lebresne Can create a Column Family with comparator CounterColumnType which is subsequently unusable --- Key: CASSANDRA-3422 URL: https://issues.apache.org/jira/browse/CASSANDRA-3422 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Kelley Reynolds Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.8, 1.0.2 It's probably the case that this shouldn't be allowed at all but one is currently allowed to create a Column Family with comparator CounterColumnType which then appears unusable. CREATE COLUMNFAMILY comparator_cf_counter (id text PRIMARY KEY) WITH comparator=CounterColumnType # Fails UPDATE comparator_cf_counter SET 1=1 + 1 WHERE id='test_key' Error = invalid operation for non commutative columnfamily comparator_cf_counter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3316) Add a JMX call to force cleaning repair sessions (in case they are hang up)
[ https://issues.apache.org/jira/browse/CASSANDRA-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3316: - Assignee: Yuki Morishita (was: Sylvain Lebresne) Add a JMX call to force cleaning repair sessions (in case they are hang up) --- Key: CASSANDRA-3316 URL: https://issues.apache.org/jira/browse/CASSANDRA-3316 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.6 Reporter: Sylvain Lebresne Assignee: Yuki Morishita Priority: Minor Fix For: 1.0.2 A repair session contains many parts, most of which are not local to the node (implying the node waits on those operation). You request merkle trees, then you schedule streaming (and in 1.0.0, some of the streaming don't involve the local node itself). It's lots of place where something can go wrong, and if so it leaves the repair hanging and as a consequence it leaves a repairSessions tasks sitting active on the 'AntiEntropy Session' executor. Obviously, we should improve the detection by repair of those things that can go wrong. CASSANDRA-2433 started and CASSANDRA-3112 is open to fill as much of the remaining parts as possible, but my bet is that it will be hard to cover everything (and it may not be worth of handling very improbable failure scenario). Besides CASSANDRA-3112 will involve change in the wire protocol, so it may take some time to be committed. In the meantime, it would be nice to provide a JMX call to force terminating repairSessions so that you don't end up in the case where you have enough 'zombie' sessions on the executor that you can't submit new ones (you could restart the node but it's ugly). Anyway, it's not a big issue but it would be simple to add such a JMX call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3419) CQL queries should allow CF names to be qualified by keyspace, part 2
[
https://issues.apache.org/jira/browse/CASSANDRA-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3419:
-
Assignee: Pavel Yaskevich
CQL queries should allow CF names to be qualified by keyspace, part 2
-
Key: CASSANDRA-3419
URL: https://issues.apache.org/jira/browse/CASSANDRA-3419
Project: Cassandra
Issue Type: New Feature
Reporter: paul cannon
Assignee: Pavel Yaskevich
Priority: Minor
Labels: cql
Fix For: 1.0.2
See CASSANDRA-3130. The same treatment should be applied to the other related
CQL commands dealing with column family names, viz:
* {{INSERT}}
* {{UPDATE}}
* {{DELETE}}
* {{TRUNCATE}}
Also, if the intent is to make it possible to go without {{USE}} entirely
(I'm not sure if it is):
* {{CREATE COLUMNFAMILY}}
* {{CREATE INDEX}}
* {{DROP COLUMNFAMILY}}
* {{ALTER COLUMNFAMILY}}
* {{DROP INDEX}} (support {{keyspacename.indexname}}?)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3412) make nodetool ring ownership smarter
[ https://issues.apache.org/jira/browse/CASSANDRA-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3412: - Assignee: Brandon Williams make nodetool ring ownership smarter Key: CASSANDRA-3412 URL: https://issues.apache.org/jira/browse/CASSANDRA-3412 Project: Cassandra Issue Type: Improvement Reporter: Jackson Chung Assignee: Brandon Williams Priority: Minor just a thought.. the ownership info currently just look at the token and calculate the % between nodes. It would be nice if it could do more, such as discriminate nodes of each DC, replica set, etc. ticket is open for suggestion... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3412) make nodetool ring ownership smarter
[ https://issues.apache.org/jira/browse/CASSANDRA-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3412: - Assignee: paul cannon (was: Brandon Williams) In particular the current design ignores all but the partitioner-defined replica, which usually results in nonsense when NTS is used w/ multiple DC. make nodetool ring ownership smarter Key: CASSANDRA-3412 URL: https://issues.apache.org/jira/browse/CASSANDRA-3412 Project: Cassandra Issue Type: Improvement Reporter: Jackson Chung Assignee: paul cannon Priority: Minor just a thought.. the ownership info currently just look at the token and calculate the % between nodes. It would be nice if it could do more, such as discriminate nodes of each DC, replica set, etc. ticket is open for suggestion... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2392) Saving IndexSummaries to disk
[ https://issues.apache.org/jira/browse/CASSANDRA-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2392: - Assignee: Vijay (was: Pavel Yaskevich) Saving IndexSummaries to disk - Key: CASSANDRA-2392 URL: https://issues.apache.org/jira/browse/CASSANDRA-2392 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Vijay Priority: Minor Fix For: 1.1 For nodes with millions of keys, doing rolling restarts that take over 10 minutes per node can be painful if you have 100 node cluster. All of our time is spent on doing index summary computations on startup. It would be great if we could save those to disk as well. Our indexes are quite large. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3393) report compression ratio in CFSMBean
[ https://issues.apache.org/jira/browse/CASSANDRA-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3393: - Assignee: Vijay (was: Pavel Yaskevich) report compression ratio in CFSMBean Key: CASSANDRA-3393 URL: https://issues.apache.org/jira/browse/CASSANDRA-3393 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.0.0 Reporter: Jonathan Ellis Assignee: Vijay Priority: Minor Labels: jmx Fix For: 1.0.2 (should expose in nodetool cfstats as well) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3101) Should check for errors when calling /bin/ln
[ https://issues.apache.org/jira/browse/CASSANDRA-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3101: - Assignee: Vijay (was: Pavel Yaskevich) Should check for errors when calling /bin/ln Key: CASSANDRA-3101 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.4 Reporter: paul cannon Assignee: Vijay Priority: Minor Labels: lhf Fix For: 1.0.2 It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not check for any errors in the execution of the hard-link-making utility. This could be bad if, for example, the user has put the snapshot directory on a different filesystem from the data directory. The hard linking would fail and the sstable snapshots would not exist, but no error would be reported. It does look like errors with the more direct JNA link() call are handled correctly- an exception is thrown. The WithExec version should probably do the same thing. Definitely it would be enough to check the process exit value from /bin/ln for nonzero in the *nix case, but I don't know whether 'fsutil hardlink create' or 'cmd /c mklink /H' return nonzero on failure. For bonus points, use any output from the Process's error stream in the text of the exception, to aid in debugging problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-1740) Nodetool commands to query and stop compaction, repair, cleanup and scrub
[ https://issues.apache.org/jira/browse/CASSANDRA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-1740: - Assignee: Vijay (was: Pavel Yaskevich) Nodetool commands to query and stop compaction, repair, cleanup and scrub - Key: CASSANDRA-1740 URL: https://issues.apache.org/jira/browse/CASSANDRA-1740 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Chip Salzenberg Assignee: Vijay Priority: Minor Fix For: 1.0.2 Attachments: CASSANDRA-1740.patch Original Estimate: 24h Remaining Estimate: 24h The only way to stop compaction, repair, cleanup, or scrub in progress is to stop and restart the entire Cassandra server. Please provide nodetool commands to query whether such things are running, and stop them if they are. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3402) Runtime exception thrown periodically under load
[ https://issues.apache.org/jira/browse/CASSANDRA-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3402: - Assignee: Sylvain Lebresne Runtime exception thrown periodically under load Key: CASSANDRA-3402 URL: https://issues.apache.org/jira/browse/CASSANDRA-3402 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: Cassandra 1.0 Red Hat Enterprise Linux Server 6.0 Reporter: Andy Stec Assignee: Sylvain Lebresne Fix For: 1.0.1 The exception listed below is thrown periodically. We're using thrift interface for C++. Jonathan Ellis requested that we open a bug for this. ERROR [ReadStage:1761] 2011-10-25 12:17:16,088 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[ReadStage:1761,5,main] java.lang.RuntimeException: error reading 5 of 5 at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:40) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:107) at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:145) at org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:124) at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:116) at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:144) at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:225) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:61) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1297) at org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1128) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1157) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1114) at org.apache.cassandra.db.Table.getRow(Table.java:388) at org.apache.cassandra.db.SliceByNamesReadCommand.getRow(SliceByNamesReadCommand.java:58) at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:62) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.cassandra.db.ColumnSerializer$CorruptColumnException: invalid column name length 0 at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:89) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:82) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:72) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:36) at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:79) ... 24 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3371) Cassandra inferred schema and actual data don't match
[
https://issues.apache.org/jira/browse/CASSANDRA-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3371:
-
Assignee: Brandon Williams
Cassandra inferred schema and actual data don't match
-
Key: CASSANDRA-3371
URL: https://issues.apache.org/jira/browse/CASSANDRA-3371
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.7
Reporter: Pete Warden
Assignee: Brandon Williams
It's looking like there may be a mismatch between the schema that's being
reported by the latest CassandraStorage.java, and the data that's actually
returned. Here's an example:
rows = LOAD 'cassandra://Frap/PhotoVotes' USING CassandraStorage();
DESCRIBE rows;
rows: {key: chararray,columns: {(name: chararray,value:
bytearray,photo_owner: chararray,value_photo_owner: bytearray,pid:
chararray,value_pid: bytearray,matched_string:
chararray,value_matched_string: bytearray,src_big: chararray,value_src_big:
bytearray,time: chararray,value_time: bytearray,vote_type:
chararray,value_vote_type: bytearray,voter: chararray,value_voter:
bytearray)}}
DUMP rows;
(691831038_1317937188.48955,{(photo_owner,1596090180),(pid,6855155124568798560),(matched_string,),(src_big,),(time,Thu
Oct 06 14:39:48 -0700 2011),(vote_type,album_dislike),(voter,691831038)})
getSchema() is reporting the columns as an inner bag of tuples, each of which
contains 16 values. In fact, getNext() seems to return an inner bag
containing 7 tuples, each of which contains two values.
It appears that things got out of sync with this change:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?r1=1177083r2=1177082pathrev=1177083
See more discussion at:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/pig-cassandra-problem-quot-Incompatible-field-schema-quot-error-tc6882703.html
Here's a patch I ended up creating for my own use, which gives the results I
need (though it doesn't handle super-columns):
DESCRIBE rows;
rows: {cassandra_key: chararray,photo_owner: bytearray,pid:
bytearray,place_matched_string: bytearray,src_big: bytearray,time:
bytearray,vote_type: bytearray,voter: bytearray}
Index:
contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
===
---
contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
(revision 1185044)
+++
contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
(working copy)
@@ -26,7 +26,7 @@
import org.apache.cassandra.db.marshal.IntegerType;
import org.apache.cassandra.db.marshal.TypeParser;
import org.apache.cassandra.thrift.*;
-import org.apache.cassandra.utils.Hex;
+import org.apache.cassandra.utils.FBUtilities;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -122,15 +122,15 @@
assert key != null cf != null;
// and wrap it in a tuple
- Tuple tuple = TupleFactory.getInstance().newTuple(2);
+ Tuple tuple = TupleFactory.getInstance().newTuple(cf.size()+1);
ArrayListTuple columns = new ArrayListTuple();
-tuple.set(0, new DataByteArray(key.array(),
key.position()+key.arrayOffset(), key.limit()+key.arrayOffset()));
+int tupleIndex = 0;
+tuple.set(tupleIndex++, new DataByteArray(key.array(),
key.position()+key.arrayOffset(), key.limit()+key.arrayOffset()));
for (Map.EntryByteBuffer, IColumn entry : cf.entrySet())
{
-columns.add(columnToTuple(entry.getKey(), entry.getValue(),
cfDef));
+tuple.set(tupleIndex++, columnToTuple(entry.getKey(),
entry.getValue(), cfDef));
}
-tuple.set(1, new DefaultDataBag(columns));
return tuple;
}
catch (InterruptedException e)
@@ -139,30 +139,22 @@
}
}
-private Tuple columnToTuple(ByteBuffer name, IColumn col, CfDef cfDef)
throws IOException
+private Object columnToTuple(ByteBuffer name, IColumn col, CfDef cfDef)
throws IOException
{
-Tuple pair = TupleFactory.getInstance().newTuple(2);
ListAbstractType marshallers = getDefaultMarshallers(cfDef);
MapByteBuffer,AbstractType validators = getValidatorMap(cfDef);
-setTupleValue(pair, 0, marshallers.get(0).compose(name));
if (col instanceof Column)
{
// standard
if (validators.get(name) == null)
-setTupleValue(pair, 1,
[jira] [Assigned] (CASSANDRA-3170) Schema versions output should be on separate lines for separate versions
[ https://issues.apache.org/jira/browse/CASSANDRA-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3170: - Assignee: Pavel Yaskevich Schema versions output should be on separate lines for separate versions Key: CASSANDRA-3170 URL: https://issues.apache.org/jira/browse/CASSANDRA-3170 Project: Cassandra Issue Type: Improvement Reporter: Jeremy Hanna Assignee: Pavel Yaskevich Priority: Minor Labels: cli, lhf On the CLI if you do a 'describe cluster;' it would be really nice to have different versions on different lines or some way to call out multiple versions more. Right now it's a UUID with a list of nodes for one, but with multiple versions, it's on the same line - another UUID and another list of nodes. That's hard to distinguish between one version and multiple versions at a glance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3217) javax.management.InstanceAlreadyExistsException: during startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3217: - Assignee: Pavel Yaskevich The second report here is confusing to me, I'm not sure how it could fail once but then succeed with no schema changes in between. javax.management.InstanceAlreadyExistsException: during startup --- Key: CASSANDRA-3217 URL: https://issues.apache.org/jira/browse/CASSANDRA-3217 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.5 Reporter: Thibaut Assignee: Pavel Yaskevich Priority: Minor Hi, I got this error on one machines after restarting (the node could have been killed due to an outofmemory error). It would crash on each restart on this error. I copied over the system table from another machine and deleted the locationinfo files and everything worked fine. I also had to delete 2 db files which coulnd't be loaded due to UTF-8 encoding errors. These rows were from the same table_feedfetch. The node might have memory errors, I'm going to check this. So it might be related to that. ERROR [main] 2011-09-16 16:13:18,468 AbstractCassandraDaemon.java (line 358) Exception encountered during startup. java.lang.RuntimeException: javax.management.InstanceAlreadyExistsException: org.apache.cassandra.db:type=ColumnFamilies,keyspace=table_feedfetch,columnfamily=table_feedfetch at org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:303) at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:465) at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:435) at org.apache.cassandra.db.Table.initCf(Table.java:369) at org.apache.cassandra.db.Table.init(Table.java:306) at org.apache.cassandra.db.Table.open(Table.java:111) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:187) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:341) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:97) Caused by: javax.management.InstanceAlreadyExistsException: org.apache.cassandra.db:type=ColumnFamilies,keyspace=table_feedfetch,columnfamily=table_feedfetch at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) at org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:299) ... 8 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3189) redhat init script can report success (exit 0) for startup failures
[ https://issues.apache.org/jira/browse/CASSANDRA-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3189: - Assignee: paul cannon redhat init script can report success (exit 0) for startup failures --- Key: CASSANDRA-3189 URL: https://issues.apache.org/jira/browse/CASSANDRA-3189 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8.5 Reporter: Eric Evans Assignee: paul cannon Priority: Minor Fix For: 1.0.1 The Redhat init script's start target merely returns the status code of the JVM. In a perfect world that would be adequate, but the JVM does not always return a non-zero status when it should. The most obvious fix is to test that the process is live before exiting. See the Debian init script for an example of this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3130) CQL queries should alow talbe names to be qualified by keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3130:
-
Assignee: Pavel Yaskevich
CQL queries should alow talbe names to be qualified by keyspace
---
Key: CASSANDRA-3130
URL: https://issues.apache.org/jira/browse/CASSANDRA-3130
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 1.0.1
While the 0.6.X api was ugly in terms of method signatures, it did allow
you to use the same client to query multiple keyspaces without having to call
set_keyspace(String). I totally dislike set_keyspace but I know the thrift
API is definitely not changing.
The following command sequence is three RPC operations.
{noformat}
select * from cf;
use otherkeyspace;
select * from othercf;
{noformat}
CQL should allow us to do:
{noformat}
select * from keyspace1.cf;
select * from keyspace2.cf;
{noformat}
This will make the connection pool management on the client much easier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3105) MarshallException no longer showing for incompatible key_validation_class
[ https://issues.apache.org/jira/browse/CASSANDRA-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3105: - Assignee: Pavel Yaskevich MarshallException no longer showing for incompatible key_validation_class - Key: CASSANDRA-3105 URL: https://issues.apache.org/jira/browse/CASSANDRA-3105 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Environment: Mac OS X 10.6.8 Cassandra-cli 0.8.4 Cassandra 0.8.1 Reporter: Anthony Ikeda Assignee: Pavel Yaskevich Priority: Minor Recently I tried querying a column family which had the default bytes key_validation_class using a string. Rather than the usual MarshallException error displayed, it just displays 'null' [default@unknown] connect localhost/9160; Connected to: Test Cluster on localhost/9160 [default@unknown] use RegistryFoundation; Authenticated to keyspace: RegistryFoundation [default@RegistryFoundation] list Registry limit 1; --- RowKey: REG:e38e47af-da8d-4cea-917b-44b93198643d = (column=c-createInfo, value=7b2274696d657374616d70223a22323031312d30382d31315431333a33343a32362e3136312d30373a3030222c2270726f66696c654964223a2265636f6d6d3a70742f7072663a61696b65646140777367632e636f6d227d, timestamp=1313094866191002) = (column=c-externalId, value=15cf9a223f8ad92768499dbdd497c524, timestamp=1313094866191001) = (column=c-name, value=416e74686f6e79277320776973686c697374, timestamp=1313094866191000) = (column=l-pt-bfbb2342-c85e-43c9-bb69-b3bb54c723fb, value=7074, timestamp=1313094866388000) = (column=p-ecomm:pt/prf:aik...@wsgc.com, value=4f574e4552, timestamp=1313094866191003) 1 Row Returned. [default@RegistryFoundation] assume Registry keys as bytes; Assumption for column family 'Registry' added successfully. [default@RegistryFoundation] get Registry['REG:e38e47af-da8d-4cea-917b-44b93198643d']; null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3065) Major file corruption after running nodetool cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3065: - Assignee: Sylvain Lebresne Major file corruption after running nodetool cleanup Key: CASSANDRA-3065 URL: https://issues.apache.org/jira/browse/CASSANDRA-3065 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.3 Reporter: Benjamin Schrauwen Assignee: Sylvain Lebresne After running nodetool cleanup on two of the nodes in my 4 node cluster, almost all SSTables on those those machine got corrupted. I am not able to read them anymore with sstable2json, and the cassandra daemon is repetitively throwing: ERROR [ReadStage:11] 2011-08-20 04:44:46,846 AbstractCassandraDaemon.java (line 139) Fatal exception in thread Thread[ReadStage:11,5,main] java.lang.RuntimeException: java.lang.IndexOutOfBoundsException at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34) 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.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Buffer.java:514) at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:209) at org.apache.cassandra.io.util.MappedFileDataInput.read(MappedFileDataInput.java:104) at java.io.InputStream.read(InputStream.java:154) at org.apache.cassandra.io.util.AbstractDataInput.readInt(AbstractDataInput.java:196) at org.apache.cassandra.io.sstable.IndexHelper.skipIndex(IndexHelper.java:61) at org.apache.cassandra.db.columniterator.SimpleSliceReader.init(SimpleSliceReader.java:58) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:91) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:67) at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:66) at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:80) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1314) at org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1181) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1221) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1168) at org.apache.cassandra.db.Table.getRow(Table.java:385) at org.apache.cassandra.db.SliceByNamesReadCommand.getRow(SliceByNamesReadCommand.java:58) at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:641) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2997) Enhance human-readability of snapshot names created by drop column family
[ https://issues.apache.org/jira/browse/CASSANDRA-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2997: - Assignee: Yuki Morishita Eric's suggestion to include the CF name in single-CF snapshots is a good one. Enhance human-readability of snapshot names created by drop column family - Key: CASSANDRA-2997 URL: https://issues.apache.org/jira/browse/CASSANDRA-2997 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8.2 Reporter: Eric Gilmore Assignee: Yuki Morishita Priority: Minor Currently when you drop a column family, a snapshot is automatically created in a directory named with the timestamp of the drop. Clever folk will find a way to understand the timestamps and locate particular snapshots, but it is not as effortless as it could be if part or all of the CF name was included in the snapshot name. Any strategy to make the snapshot name more user-friendly and easy to find would be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2268) CQL-enabled stress.java
[ https://issues.apache.org/jira/browse/CASSANDRA-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2268: - Assignee: paul cannon (was: Aaron Morton) CQL-enabled stress.java --- Key: CASSANDRA-2268 URL: https://issues.apache.org/jira/browse/CASSANDRA-2268 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Eric Evans Assignee: paul cannon Priority: Minor Labels: cql Fix For: 0.8.8 Attachments: 0001-2268-wip.patch It would be great if stress.java had a CQL mode. For making the inevitable RPC-CQL comparisons, but also as a basis for measuring optimizations, and spotting performance regressions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3088) Expose compaction_throughput_mb_per_sec for JMX tweaking
[ https://issues.apache.org/jira/browse/CASSANDRA-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3088: - Assignee: Brandon Williams Expose compaction_throughput_mb_per_sec for JMX tweaking Key: CASSANDRA-3088 URL: https://issues.apache.org/jira/browse/CASSANDRA-3088 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8.0 Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Minor Labels: lhf Fix For: 0.8.8 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3186) nodetool should not NPE when rack/dc info is not yet available
[ https://issues.apache.org/jira/browse/CASSANDRA-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3186: - Assignee: Brandon Williams nodetool should not NPE when rack/dc info is not yet available -- Key: CASSANDRA-3186 URL: https://issues.apache.org/jira/browse/CASSANDRA-3186 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Labels: lhf Fix For: 0.8.8 As the title says. What happens is the persisted ring is loaded, but if those nodes are down and you're using a snitch like ec2 that gets rack/dc info from gossip, nodetool NPEs instead of showing that the node is down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3126) unable to remove column metadata via CLI
[
https://issues.apache.org/jira/browse/CASSANDRA-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3126:
-
Assignee: Pavel Yaskevich
unable to remove column metadata via CLI
Key: CASSANDRA-3126
URL: https://issues.apache.org/jira/browse/CASSANDRA-3126
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0
Reporter: Radim Kolar
Assignee: Pavel Yaskevich
Priority: Minor
Labels: cassandra-cli
Fix For: 0.8.8
I cant find way how to remove all columns definitions without CF
import/export.
[default@int4] update column family sipdb with column_metadata = [];
Syntax error at position 51: required (...)+ loop did not match anything at
input ']'
[default@int4] update column family sipdb with column_metadata = [{}];
Command not found: `update column family sipdb with column_metadata = [{}];`.
Type 'help;' or '?' for help.
[default@int4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3354) tombstone not removed after compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3354: - Assignee: Yang Yang (was: Sylvain Lebresne) tombstone not removed after compaction -- Key: CASSANDRA-3354 URL: https://issues.apache.org/jira/browse/CASSANDRA-3354 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Assignee: Yang Yang Priority: Minor I set GC_grace to 2 hours, for testing. then I compacted the sstables using nodecmd, but the resulting sstables contained many Deletion records older than 2 hours 0d5e32633036663463310001: [[0132f8820139303030303030303030303030303030303030303030303030303030303030303030303263303666346332,4e95a659,1318429297125,d]], yyang@ip-10-71-86-162:~/src/svn/whisky$ perl -e 'print gmtime(1318429297).\n ' Wed Oct 12 14:21:37 2011 -rw-r--r-- 1 yyang yyang 381366163 2011-10-12 16:39 /mnt/cass/lib/cassandra/data/testBudget_items/multi_click_filter-h-511-Data.db but it seems that after running a few more compactions, these records are gone -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3196) Cassandra-CLI command should have --version option
[ https://issues.apache.org/jira/browse/CASSANDRA-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3196: - Assignee: Pavel Yaskevich Can we just make the cli print FBUtilities.getReleaseVersionString() on startup? Cassandra-CLI command should have --version option -- Key: CASSANDRA-3196 URL: https://issues.apache.org/jira/browse/CASSANDRA-3196 Project: Cassandra Issue Type: Wish Components: Tools Affects Versions: 0.8.5 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) Reporter: Mauri Tikka Assignee: Pavel Yaskevich Priority: Minor Implementing cassandra-cli --version command line option would make it easier to write bug reports and check the versions of tools in use. Or if you want to make it a CLI command inside the tool, I don't know. --version option seems to be the standard way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3073) liveSize() calculation is wrong in case of overwrite
[
https://issues.apache.org/jira/browse/CASSANDRA-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3073:
-
Assignee: Yang Yang
liveSize() calculation is wrong in case of overwrite
Key: CASSANDRA-3073
URL: https://issues.apache.org/jira/browse/CASSANDRA-3073
Project: Cassandra
Issue Type: Bug
Reporter: Yang Yang
Assignee: Yang Yang
Priority: Minor
Attachments:
0001-liveSize-is-different-from-throughput-particularly-w.patch
currently liveSize() is the sum of currentThroughput.
this definition is wrong if most of the operations are overwrite, or counter
(which is essentially overwrite).
for example, the following code should always keep a single entry in db, with
one row, one cf, one column, and supposedly should have a size of only about
100 bytes.
connect localhost/9160;
create keyspace blah;
use blah;
create column family cf2 with memtable_throughput=1024 and
memtable_operations=1 ;
set the cassandra.yaml
memtable_total_space_in_mb: 20
to make the error appear faster (but if u set to default, still same issue
will appear)
then we use a simple pycassa script:
pool = pycassa.connect('blah')
mycf = pycassa.ColumnFamily(pool,cf2);
for x in range(1,1000) :
... xx = mycf.insert('key1',{'col1':{}.format(x)})
...
you will see sstables being generated with only sizes of a few k, though we
set the CF options to get high SSTable sizes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3016) CQL: double and float types do not seem to work properly
[
https://issues.apache.org/jira/browse/CASSANDRA-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3016:
-
Assignee: paul cannon (was: Tyler Hobbs)
Paul, is this still a problem w/ latest dbapi driver? if so, can you create a
ticket in that project?
CQL: double and float types do not seem to work properly
Key: CASSANDRA-3016
URL: https://issues.apache.org/jira/browse/CASSANDRA-3016
Project: Cassandra
Issue Type: Bug
Reporter: Matt Hollingsworth
Assignee: paul cannon
Was asked to make this from the mailing list by Jonathan Ellis.
I'm just getting started with CQL, and decided to do a simple test
create/insert/select thing to check that everything was working. Most
everything seems to work, but it appears that double/floats do not work
properly. Here's what I did:
test.cql
--
CREATE KEYSPACE test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor=1;
USE test;
CREATE COLUMNFAMILY testvals (
key varchar PRIMARY KEY,
value float
);
INSERT INTO testvals (key,value) VALUES ('k1',341.32355);
SELECT key, value FROM testvals;
--
The output is this:
cqlsh localhost scripts/test.cql
key |value |
k1 | @uU-B??? |
Same thing happens when I do value double. I also tried to do this from the
python driver, gives the same weirdness:
In [2]: import cql
In [3]: con = cql.connect(localhost,keyspace=test)
In [4]: cursor = con.cursor()
In [5]: cursor.execute(SELECT * from testvals)
Out[5]: True
In [6]: for r in cursor: print r
...:
[u'k1', '?\xf8\x00\x00\x00\x00\x00\x00']
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2893) Add row-level isolation
[ https://issues.apache.org/jira/browse/CASSANDRA-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2893: - Assignee: Sylvain Lebresne Add row-level isolation --- Key: CASSANDRA-2893 URL: https://issues.apache.org/jira/browse/CASSANDRA-2893 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor This could be done using an the atomic ConcurrentMap operations from the Memtable and something like http://code.google.com/p/pcollections/ to replace the ConcurrentSkipListMap in ThreadSafeSortedColumns. The trick is that pcollections does not provide a SortedMap, so we probably need to write our own. Googling [persistent sortedmap] I found http://code.google.com/p/actord/source/browse/trunk/actord/src/main/scala/ff/collection (in scala) and http://clojure.org/data_structures#Data Structures-Maps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3248) CommitLog writer should call fdatasync instead of fsync
[
https://issues.apache.org/jira/browse/CASSANDRA-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3248:
-
Assignee: Brandon Williams
Brandon, can you test?
CommitLog writer should call fdatasync instead of fsync
---
Key: CASSANDRA-3248
URL: https://issues.apache.org/jira/browse/CASSANDRA-3248
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 0.6.13, 0.7.9, 0.8.6, 1.0.0, 1.1
Environment: Linux
Reporter: Zhu Han
Assignee: Brandon Williams
Original Estimate: 48h
Remaining Estimate: 48h
CommitLogSegment uses SequentialWriter to flush the buffered data to log
device. It depends on FileDescriptor#sync() which invokes fsync() as it force
the file attributes to disk.
However, at least on Linux, fdatasync() is good enough for commit log flush:
bq. fdatasync() is similar to fsync(), but does not flush modified metadata
unless that metadata is needed in order to allow a subsequent data retrieval
to be correctly handled. For example, changes to st_atime or st_mtime
(respectively, time of last access and time of last modification; see
stat(2)) do not require flushing because they are not necessary for a
subsequent data read to be handled correctly. On the other hand, a change to
the file size (st_size, as made by say ftruncate(2)), would require a
metadata flush.
File size is synced to disk by fdatasync() either. Although the commit log
recovery logic sorts the commit log segements on their modify timestamp, it
can be removed safely, IMHO.
I checked the native code of JRE 6. On Linux and Solaris,
FileChannel#force(false) invokes fdatasync(). On windows, the false flag does
not have any impact.
On my log device (commodity SATA HDD, write cache disabled), there is large
performance gap between fsync() and fdatasync():
{quote}
$sysbench --test=fileio --num-threads=1 --file-num=1 --file-total-size=10G
--file-fsync-all=on --file-fsync-mode={color:red}fdatasync{color}
--file-test-mode=seqwr --max-time=600 --file-block-size=2K --max-requests=0
run
{color:blue}54.90{color} Requests/sec executed
per-request statistics:
min: 8.29ms
avg: 18.18ms
max:108.36ms
approx. 95 percentile: 25.02ms
$ sysbench --test=fileio --num-threads=1 --file-num=1 --file-total-size=10G
--file-fsync-all=on --file-fsync-mode={color:red}fsync{color}
--file-test-mode=seqwr --max-time=600 --file-block-size=2K --max-requests=0
run
{color:blue}28.08{color} Requests/sec executed
per-request statistics:
min: 33.28ms
avg: 35.61ms
max:911.87ms
approx. 95 percentile: 41.69ms
{quote}
I do think this is a very critical performance improvement.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3354) tombstone not removed after compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3354: - Assignee: Sylvain Lebresne That is a question for Sylvain :) tombstone not removed after compaction -- Key: CASSANDRA-3354 URL: https://issues.apache.org/jira/browse/CASSANDRA-3354 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Assignee: Sylvain Lebresne Priority: Minor I set GC_grace to 2 hours, for testing. then I compacted the sstables using nodecmd, but the resulting sstables contained many Deletion records older than 2 hours 0d5e32633036663463310001: [[0132f8820139303030303030303030303030303030303030303030303030303030303030303030303263303666346332,4e95a659,1318429297125,d]], yyang@ip-10-71-86-162:~/src/svn/whisky$ perl -e 'print gmtime(1318429297).\n ' Wed Oct 12 14:21:37 2011 -rw-r--r-- 1 yyang yyang 381366163 2011-10-12 16:39 /mnt/cass/lib/cassandra/data/testBudget_items/multi_click_filter-h-511-Data.db but it seems that after running a few more compactions, these records are gone -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2863) NPE when writing SSTable generated via repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2863: - Assignee: Sylvain Lebresne Joaquin, can you give steps to reproduce? NPE when writing SSTable generated via repair - Key: CASSANDRA-2863 URL: https://issues.apache.org/jira/browse/CASSANDRA-2863 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: Héctor Izquierdo Assignee: Sylvain Lebresne Fix For: 0.8.8 A NPE is generated during repair when closing an sstable generated via SSTable build. It doesn't happen always. The node had been scrubbed and compacted before calling repair. INFO [CompactionExecutor:2] 2011-07-06 11:11:32,640 SSTableReader.java (line 158) Opening /d2/cassandra/data/sbs/walf-g-730 ERROR [CompactionExecutor:2] 2011-07-06 11:11:34,327 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[CompactionExecutor:2,1,main] java.lang.NullPointerException at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.close(SSTableWriter.java:382) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:370) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) at org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:1103) at org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:1094) 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:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3314) Fail to delete -Index files if index is currently building
[ https://issues.apache.org/jira/browse/CASSANDRA-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3314: - Assignee: (was: Pavel Yaskevich) Also, would be good to know if you can reproduce in latest 0.8, as I would expect. Fail to delete -Index files if index is currently building -- Key: CASSANDRA-3314 URL: https://issues.apache.org/jira/browse/CASSANDRA-3314 Project: Cassandra Issue Type: Bug Reporter: Radim Kolar Priority: Minor Fix For: 0.8.8, 1.0.0 If there is index building in progress, following errors are thrown if cassandra is trying to delete *-Index.db files. There is no problem with deleting -Data or -Filter.. files. CF is using leveled compaction but it is probably not related. ERROR [NonPeriodicTasks:1] 2011-10-05 09:13:03,702 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[NonPeriodicTasks:1,5,main] java.lang.RuntimeException: java.io.IOException: Failed to delete C:\var\lib\cas sandra\data\test\sipdb-h-772-Index.db at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:3 4) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:44 1) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask. access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask. run(ScheduledThreadPoolExecutor.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:908) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2922) Move SimpleAuthenticator and SimpleAuthority to examples/
[ https://issues.apache.org/jira/browse/CASSANDRA-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2922: - Assignee: Sylvain Lebresne (was: Jonathan Ellis) Move SimpleAuthenticator and SimpleAuthority to examples/ - Key: CASSANDRA-2922 URL: https://issues.apache.org/jira/browse/CASSANDRA-2922 Project: Cassandra Issue Type: Task Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0.0 Attachments: 2922.txt We've provided SimpleAuthenticator and SimpleAuthority, toy file-based authentication and authorization mechanisms, since CASSANDRA-547. These are NOT production ready (even non-experts can tell the encryption is a joke) but newcomers don't always realize this. Let's move them to examples/ instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3325) Compaction degrades key cache stats
[ https://issues.apache.org/jira/browse/CASSANDRA-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3325: - Assignee: Fabien Rousseau Compaction degrades key cache stats --- Key: CASSANDRA-3325 URL: https://issues.apache.org/jira/browse/CASSANDRA-3325 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Fabien Rousseau Assignee: Fabien Rousseau Priority: Minor Labels: compaction Fix For: 1.0.0 Attachments: 001-CASSANDRA-3325.patch When compaction_preheat_key_cache is set to true, then during compaction, it keep tracks of cached keys to to re-cache their new position. It does this by calling the following method on every key of the compacted sstable : sstable.getCachedPosition(row.key) which also update cache stats, thus lowering hit rate Below is an attached patch allowing to know if the key is cached, but without updating the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3211) Enhanced IP resolution for machines with multiple network interfaces
[ https://issues.apache.org/jira/browse/CASSANDRA-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3211: - Assignee: Brian ONeill Enhanced IP resolution for machines with multiple network interfaces - Key: CASSANDRA-3211 URL: https://issues.apache.org/jira/browse/CASSANDRA-3211 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.6 Environment: Mac OS X and Linux with machines that have multiple network interfaces whereby the IP associated with the split is not on the network interface associated with localhost. Reporter: Brian ONeill Assignee: Brian ONeill Priority: Minor Fix For: 0.8.7 Attachments: trunk-3211.txt On unix machines that have multiple network interfaces whereby the IP associated with the split is not on the network interface associated with localhost, the getLocation method cannot find the proper IP and throws an exception no connection available. I changed the implementation to use NetworkInterface instead of InetAddress using getLocalHost(). This is more reliable. See the following references: http://stackoverflow.com/questions/5813194/inetaddress-getlocalhost-does-not-return-expected-ip-address-from-c-windows-sy http://stackoverflow.com/questions/4871451/inetaddress-getlocalhost-returns-wrong-result-when-hostname-is-64-chars http://www.jguru.com/faq/view.jsp?EID=790132 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3275) Make Cassandra compile under JDK 7
[
https://issues.apache.org/jira/browse/CASSANDRA-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3275:
-
Assignee: Rick Shaw (was: Pavel Yaskevich)
Is that because JDK7 added some new ResultSet methods, or are we violating some
generics rule that wasn't enforced before?
Make Cassandra compile under JDK 7
--
Key: CASSANDRA-3275
URL: https://issues.apache.org/jira/browse/CASSANDRA-3275
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Pavel Yaskevich
Assignee: Rick Shaw
Fix For: 1.0.0
Currently system won't compile under JDK 7 because of errors in CQL JDBC
component.
{noformat}
[javac]
/usr/src/cassandra/drivers/java/src/org/apache/cassandra/cql/jdbc/CResultSet.java:39:
error: CResultSet is not abstract and does not override abstract method
TgetObject(String,ClassT) in ResultSet
[javac] class CResultSet extends AbstractResultSet implements
CassandraResultSet
[javac] ^
[javac] where T is a type-variable:
[javac] T extends Object declared in method
TgetObject(String,ClassT)
[javac]
/usr/src/cassandra/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraConnection.java:81:
error: CassandraConnection is not abstract and does not override abstract
method getNetworkTimeout() in Connection
[javac] class CassandraConnection extends AbstractCassandraConnection
implements Connection
[javac] ^
[javac]
/usr/src/cassandra/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraDataSource.java:24:
error: CassandraDataSource is not abstract and does not override abstract
method getParentLogger() in CommonDataSource
[javac] public class CassandraDataSource implements DataSource
[javac]^
[javac]
/usr/src/cassandra/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraDatabaseMetaData.java:32:
error: CassandraDatabaseMetaData is not abstract and does not override
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] class CassandraDatabaseMetaData implements DatabaseMetaData
[javac] ^
[javac]
/usr/src/cassandra/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraDriver.java:40:
error: CassandraDriver is not abstract and does not override abstract method
getParentLogger() in Driver
[javac] public class CassandraDriver implements Driver
[javac]^
[javac]
/usr/src/cassandra/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraStatement.java:50:
error: CassandraStatement is not abstract and does not override abstract
method isCloseOnCompletion() in Statement
[javac] class CassandraStatement extends AbstractStatement implements
Statement
[javac] ^
[javac]
/usr/src/cassandra/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraPreparedStatement.java:61:
error: CassandraPreparedStatement is not abstract and does not override
abstract method isCloseOnCompletion() in Statement
[javac] class CassandraPreparedStatement extends CassandraStatement
implements PreparedStatement
[javac] ^
[javac] Note:
/usr/src/cassandra/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraPreparedStatement.java
uses or overrides a deprecated API.
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3268) Cannot read counter value from jdbc cql
[ https://issues.apache.org/jira/browse/CASSANDRA-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3268: - Assignee: Corey Hulen Cannot read counter value from jdbc cql --- Key: CASSANDRA-3268 URL: https://issues.apache.org/jira/browse/CASSANDRA-3268 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.0.0 Reporter: Corey Hulen Assignee: Corey Hulen Priority: Trivial Labels: cql Fix For: 1.0.0 it appears on line #36 in src/java/org/apache/cassandra/cql/jdbc/TypesMap.java (notice it's in the portion of code that sits in the main src dir not the drivers) map.put(org.apache.cassandra.db.marshal.ColumnCounterType, JdbcCounterColumn.instance); should be map.put(org.apache.cassandra.db.marshal.CounterColumnType, JdbcCounterColumn.instance); Notice CounterColumnType is reversed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3258) *.bat files fails when CASSANDRA_HOME contains a white space.
[ https://issues.apache.org/jira/browse/CASSANDRA-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3258: - Assignee: Tim Almdal *.bat files fails when CASSANDRA_HOME contains a white space. - Key: CASSANDRA-3258 URL: https://issues.apache.org/jira/browse/CASSANDRA-3258 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8.6 Environment: Windows 7 Reporter: Tim Almdal Assignee: Tim Almdal Fix For: 0.8.7 Issues 2952 and 2237 fixed the issue for cassandra.bat. But the following bat files need the same fix: json2sstable.bat nodetool.bat sstable2json.bat sstablekeys.bat -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
