[jira] [Commented] (CASSANDRA-4175) Reduce memory (and disk) space requirements with a column name/id map
[ https://issues.apache.org/jira/browse/CASSANDRA-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258027#comment-13258027 ] Dave Brosius commented on CASSANDRA-4175: - how about System.identityHashCode(string) ? Reduce memory (and disk) space requirements with a column name/id map - Key: CASSANDRA-4175 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Fix For: 1.2 We spend a lot of memory on column names, both transiently (during reads) and more permanently (in the row cache). Compression mitigates this on disk but not on the heap. The overhead is significant for typical small column values, e.g., ints. Even though we intern once we get to the memtable, this affects writes too via very high allocation rates in the young generation, hence more GC activity. Now that CQL3 provides us some guarantees that column names must be defined before they are inserted, we could create a map of (say) 32-bit int column id, to names, and use that internally right up until we return a resultset to the client. -- 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] [Commented] (CASSANDRA-4169) Locale settings on windows can break schema
[
https://issues.apache.org/jira/browse/CASSANDRA-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256929#comment-13256929
]
Dave Brosius commented on CASSANDRA-4169:
-
even something silly like mystring.toUpperCase() would access the locale. and
turkish is notorious for creating unsuspected characters when upper/lower
casing a string (adding crazy accents, etc).
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] [Commented] (CASSANDRA-556) nodeprobe snapshot to support specific column families
[ https://issues.apache.org/jira/browse/CASSANDRA-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255038#comment-13255038 ] Dave Brosius commented on CASSANDRA-556: Sure that's fine, i'll fix tonite. Just wanted to make sure folks were ok with splitting the command as it is. 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 Attachments: cf_snapshots_556.diff 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] [Commented] (CASSANDRA-556) nodeprobe snapshot to support specific column families
[ https://issues.apache.org/jira/browse/CASSANDRA-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255055#comment-13255055 ] Dave Brosius commented on CASSANDRA-556: the issue with -flags, is then you have the potential situation of n keyspaces with a cf name... which might be confusing... hopefully people don't have the same cf name in multiple keyspaces. -flags is also different then the way other commands handle cfs. But i'm fine with doing it that way as well. If that were the case there would be only one jmx call i would think. 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 Attachments: cf_snapshots_556.diff 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] [Commented] (CASSANDRA-4152) cache the hashcode of DecoratedKey as it is immutable
[ https://issues.apache.org/jira/browse/CASSANDRA-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255059#comment-13255059 ] Dave Brosius commented on CASSANDRA-4152: - perhaps consider generating the hashcode from the token, rather than the key. Granted the 64k Key is hopefully a corner case, but using the token would provide consistency in that case as well. cache the hashcode of DecoratedKey as it is immutable - Key: CASSANDRA-4152 URL: https://issues.apache.org/jira/browse/CASSANDRA-4152 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Dave Brosius Priority: Trivial Attachments: cache_decoratedkey_hash.diff cache the hashcode of the DecoratedKey on first hashCode() call. DecoratedKey is immutable so no need to run thru all ByteBuffer bytes of the key and do hashcode math. applied to 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] [Commented] (CASSANDRA-556) nodeprobe snapshot to support specific column families
[ https://issues.apache.org/jira/browse/CASSANDRA-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255077#comment-13255077 ] Dave Brosius commented on CASSANDRA-556: if one did nodetool snapshot -cf foo that could potentially take snapshots of multiple 'foo's (one each in multiple keyspaces) which might be something the admin wasn't realizing... right? or am i wrong and cf names are unique across the cluster? 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 Attachments: cf_snapshots_556.diff 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] [Commented] (CASSANDRA-3710) Add a configuration option to disable snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251796#comment-13251796 ] Dave Brosius commented on CASSANDRA-3710: - Generated the same way - I'm guessing just fat fingers, on edit/review. Don't know. 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 Fix For: 1.0.10, 1.1.0 Attachments: Cassandra107Patch_TestModeV1.txt, auto_snapshot.diff, auto_snapshot_2.diff, auto_snapshot_3.diff 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] [Commented] (CASSANDRA-4052) Add way to force the cassandra-cli to refresh it's schema
[ https://issues.apache.org/jira/browse/CASSANDRA-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252196#comment-13252196 ] Dave Brosius commented on CASSANDRA-4052: - Is this schema cached to allow for the assumption of cf attributes? ie, assume cf validator as utf8; ? Add way to force the cassandra-cli to refresh it's schema - Key: CASSANDRA-4052 URL: https://issues.apache.org/jira/browse/CASSANDRA-4052 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.0.8 Reporter: Tupshin Harper Priority: Minor By design, the cassandra-cli caches the schema and doesn't refresh it when various commands like describe keyspaces are run. This is reasonable, and it is easy enough to restart the cli if necessary. However, this does lead to confusion since a new user can reasonably assume that describe keyspaces will always show an accurate current represention of the ring. We should find a way to reduce the surprise (and lack of easy discoverability) of this behaviour. I propose any one of the following(#1 is probably the easiest and most likely): 1) Add a command (that would be documented in the cli's help) to explicitly refresh the schema (schema refresh, refresh schema, or anything similar). 2) Always force a refresh of the schema when performing at least the describe keyspaces command. 3) Add a flag to cassandra-cli to explicitly enable schema caching. If that flag is not passed, then schema caching will be disabled for that session. This suggestion assumes that for simple deployments (few CFs, etc), schema caching isn't very important to the performance of the cli. -- 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] [Commented] (CASSANDRA-4046) when creating keyspace with simple strategy, it should only acception replication_factor as an option
[
https://issues.apache.org/jira/browse/CASSANDRA-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252198#comment-13252198
]
Dave Brosius commented on CASSANDRA-4046:
-
Implementations of AbstractReplicationStrategy.validateOptions only does
positive validations, negative validations for these would need to be
implemented for this issue.
when creating keyspace with simple strategy, it should only acception
replication_factor as an option
---
Key: CASSANDRA-4046
URL: https://issues.apache.org/jira/browse/CASSANDRA-4046
Project: Cassandra
Issue Type: Bug
Reporter: Jackson Chung
Priority: Minor
currently I could do this:
{panel}
[default@unknown] create keyspace test
... with placement_strategy = 'SimpleStrategy'
... and strategy_options = \{DC : testdc, replication_factor :1\};
ebc5f430-6d47-11e1--edee3ea2cbff
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown]
{panel}
while i don't think this creates any problem in terms of the actual
replication being used for the CL , we probably should acknowledge to the
user that DC : testdc is not an valid option for the SimpleStrategy.
--
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] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242576#comment-13242576
]
Dave Brosius commented on CASSANDRA-4093:
-
Ask users@ if anyone actually has such a use case in production, and go with
1 or 2 based on the responses
This makes sense to me... it's possible that this isn't really an issue.
schema_* CFs do not respect column comparator which leads to CLI commands
failure.
--
Key: CASSANDRA-4093
URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.0
Reporter: Dave Brosius
Assignee: Sylvain Lebresne
Fix For: 1.1.0
Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
schema_* CFs column_metadata do not respect CF comparator and use
ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
probably in other places.
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] [Commented] (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:comment-tabpanelfocusedCommentId=13240057#comment-13240057 ] Dave Brosius commented on CASSANDRA-4093: - I just created a brand new database directory, went into cli and did show keyspaces; the output finishes with this: Notice the trailing 'null'. That is caused by the exception. ColumnFamily: schema_columnfamilies ColumnFamily definitions Key Validation Class: org.apache.cassandra.db.marshal.AsciiType Default column value validator: org.apache.cassandra.db.marshal.BytesType Columns sorted by: org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.AsciiType,org.apache.cassandra.db.marshal.AsciiType) GC grace seconds: 10368000 Compaction min/max thresholds: 4/32 Read repair chance: 0.0 DC Local Read repair chance: 0.0 Replicate on write: true Caching: KEYS_ONLY Bloom Filter FP chance: default Built indexes: [] Column Metadata: null 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] [Commented] (CASSANDRA-3755) NPE on invalid CQL DELETE command
[
https://issues.apache.org/jira/browse/CASSANDRA-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240060#comment-13240060
]
Dave Brosius commented on CASSANDRA-3755:
-
sure
NPE on invalid CQL DELETE command
-
Key: CASSANDRA-3755
URL: https://issues.apache.org/jira/browse/CASSANDRA-3755
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: paul cannon
Assignee: Dave Brosius
Priority: Minor
Labels: cql
Fix For: 1.0.9
Attachments: unknown_cf.diff
The CQL command {{delete from k where key='bar';}} causes Cassandra to hit a
NullPointerException when the k column family does not exist, and it
subsequently closes the Thrift connection instead of reporting an IRE or
whatever. This is probably wrong.
--
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] [Commented] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238658#comment-13238658 ] Dave Brosius commented on CASSANDRA-3772: - this patch was only to evaluate... I think we would need to embellish this patch to save the setting in the system table, before committing this patch. Evaluate Murmur3-based partitioner -- Key: CASSANDRA-3772 URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Dave Brosius Fix For: 1.2 Attachments: try_murmur3.diff, try_murmur3_2.diff MD5 is a relatively heavyweight hash to use when we don't need cryptographic qualities, just a good output distribution. Let's see how much overhead we can save by using Murmur3 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] [Commented] (CASSANDRA-4023) Improve BloomFilter deserialization performance
[ https://issues.apache.org/jira/browse/CASSANDRA-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238867#comment-13238867 ] Dave Brosius commented on CASSANDRA-4023: - no v3 has this bug the problem is in the general case where RowIndexEntry.serializer.deserialize() is using the hasPromotedIndexes code, the amount of data read is variable (assuming in this case the first int read in deserialize can be non 0). Therefore in SSTableReader the code can no longer statically predict when a particular key will be the last key. 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, cassandra-1.0-4023-v2.txt, cassandra-1.0-4023-v3.txt, trunk-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] [Commented] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239027#comment-13239027 ] Dave Brosius commented on CASSANDRA-3772: - Sure... I will push the current RandomPartitioner code to an AbstractRandomPartitioner class and then subclass a new RandomPartitioner that uses md5 and a second subclass that does murmur3. Evaluate Murmur3-based partitioner -- Key: CASSANDRA-3772 URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Dave Brosius Fix For: 1.2 Attachments: try_murmur3.diff, try_murmur3_2.diff MD5 is a relatively heavyweight hash to use when we don't need cryptographic qualities, just a good output distribution. Let's see how much overhead we can save by using Murmur3 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] [Commented] (CASSANDRA-4023) Improve BloomFilter deserialization performance
[
https://issues.apache.org/jira/browse/CASSANDRA-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237628#comment-13237628
]
Dave Brosius commented on CASSANDRA-4023:
-
Getting NPE around this code (trunk).
SSTableReader.open on system-schema_columnfamilies-ib-2
SSTableReader.load bails out of the while (true) loop because
if (indexPosition == indexSize)
causing the right variable to remain null, which then gets passed to
this.last = getMinimalKey(right);
which NPEs
boolean lastKey = indexPosition + DBConstants.SHORT_SIZE + len +
DBConstants.LONG_SIZE == indexSize; is false on the last item
indexPosition = 0
len = 9
indexSize = 23
19 != 23
public static DecoratedKey getMinimalKey(DecoratedKey key)
{
return key.key.position() 0 || key.key.hasRemaining()
? new DecoratedKey(key.token,
HeapAllocator.instance.clone(key.key))
: key;
}
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: 0001-fix-loading-promoted-row-index.patch, 4023.txt,
cassandra-1.0-4023-v2.txt, cassandra-1.0-4023-v3.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] [Commented] (CASSANDRA-4023) Improve BloomFilter deserialization performance
[
https://issues.apache.org/jira/browse/CASSANDRA-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237632#comment-13237632
]
Dave Brosius commented on CASSANDRA-4023:
-
Seems like this is the fix to me
diff --git a/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
b/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
index 9e92220..959a66d 100644
--- a/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
+++ b/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
@@ -361,7 +361,7 @@ public class SSTableReader extends SSTable
int len = ByteBufferUtil.readShortLength(input);
boolean firstKey = left == null;
-boolean lastKey = indexPosition + DBConstants.SHORT_SIZE + len
+ DBConstants.LONG_SIZE == indexSize;
+boolean lastKey = indexPosition + DBConstants.SHORT_SIZE + len
+ DBConstants.LONG_SIZE + (descriptor.hasPromotedIndexes ? DBConstants.INT_SIZE
: 0) == indexSize;
boolean shouldAddEntry = indexSummary.shouldAddEntry();
if (shouldAddEntry || cacheLoading || recreatebloom ||
firstKey || lastKey)
{
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: 0001-fix-loading-promoted-row-index.patch, 4023.txt,
cassandra-1.0-4023-v2.txt, cassandra-1.0-4023-v3.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] [Commented] (CASSANDRA-4081) Issue with cassandra-cli assume command and custom types
[ https://issues.apache.org/jira/browse/CASSANDRA-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237635#comment-13237635 ] Dave Brosius commented on CASSANDRA-4081: - It appears you need to supply one of these constants from the CliClient.Function BYTES, INTEGER, LONG, INT, LEXICALUUID, TIMEUUID, UTF8, ASCII, COUNTERCOLUMN and not class names. Given that it would appear to me that the doc is wrong about being able to specify custom class types. Issue with cassandra-cli assume command and custom types -- Key: CASSANDRA-4081 URL: https://issues.apache.org/jira/browse/CASSANDRA-4081 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.7 Environment: Cassandra 1.0.7 on Mac OSX Lion Reporter: Drew Kutcharian There seems to be an issue with cassandra-cli's assume command with a custom type. I get Syntax error at position 35: missing EOF at '.' To make sure the issue is not with my custom type, I tried it with the built-in BytesType and got the same error: [default@test] assume UserDetails validator as org.apache.cassandra.db.marshal.BytesType; Syntax error at position 35: missing EOF at '.' I also tried it with single and double quotes with no success: [default@test] assume UserDetails validator as 'org.apache.cassandra.db.marshal.BytesType'; Syntax error at position 32: mismatched input ''org.apache.cassandra.db.marshal.BytesType'' expecting Identifier Based on the output of help assume I should be able to just pass a fqn of a class. It is also valid to specify the fully-qualified class name to a class that extends org.apache.Cassandra.db.marshal.AbstractType. -- 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] [Commented] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237446#comment-13237446 ] Dave Brosius commented on CASSANDRA-3772: - new patch against trunk using MurmurHash.hash3_x64_128. Preliminary testing show murmur3 hash to be marginally faster than md5, altho not significantly. (this is one very pedestrian hardware tho, so that might mask differences). Running longer tests now to see if jit has had a fair chance to do it's magic. Evaluate Murmur3-based partitioner -- Key: CASSANDRA-3772 URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Dave Brosius Fix For: 1.2 Attachments: try_murmur3.diff, try_murmur3_2.diff MD5 is a relatively heavyweight hash to use when we don't need cryptographic qualities, just a good output distribution. Let's see how much overhead we can save by using Murmur3 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] [Commented] (CASSANDRA-2319) Promote row index
[
https://issues.apache.org/jira/browse/CASSANDRA-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228874#comment-13228874
]
Dave Brosius commented on CASSANDRA-2319:
-
Perhaps i am reading this wrong, but this patch appears to make
SSTableIdentityIterator constructor now expect sstable to not be null, which is
not the case from this constructor
public SSTableIdentityIterator(CFMetaData metadata, DataInput file,
DecoratedKey key, long dataStart, long dataSize, IColumnSerializer.Flag flag)
throws IOException
{
this(metadata, file, key, dataStart, dataSize, false, null, flag);
}
which is called from here IncomingStreamReader.streamIn
I would expect an NPE in this case.
Promote row index
-
Key: CASSANDRA-2319
URL: https://issues.apache.org/jira/browse/CASSANDRA-2319
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Assignee: Sylvain Lebresne
Labels: index, timeseries
Fix For: 1.2
Attachments: 2319-v1.tgz, 2319-v2.tgz, promotion.pdf, version-f.txt,
version-g-lzf.txt, version-g.txt
The row index contains entries for configurably sized blocks of a wide row.
For a row of appreciable size, the row index ends up directing the third seek
(1. index, 2. row index, 3. content) to nearby the first column of a scan.
Since the row index is always used for wide rows, and since it contains
information that tells us whether or not the 3rd seek is necessary (the
column range or name we are trying to slice may not exist in a given
sstable), promoting the row index into the sstable index would allow us to
drop the maximum number of seeks for wide rows back to 2, and, more
importantly, would allow sstables to be eliminated using only the index.
An example usecase that benefits greatly from this change is time series data
in wide rows, where data is appended to the beginning or end of the row. Our
existing compaction strategy gets lucky and clusters the oldest data in the
oldest sstables: for queries to recently appended data, we would be able to
eliminate wide rows using only the sstable index, rather than needing to seek
into the data file to determine that it isn't interesting. For narrow rows,
this change would have no effect, as they will not reach the threshold for
indexing anyway.
A first cut design for this change would look very similar to the file format
design proposed on #674:
http://wiki.apache.org/cassandra/FileFormatDesignDoc: row keys clustered,
column names clustered, and offsets clustered and delta encoded.
--
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] [Commented] (CASSANDRA-3974) Per-CF TTL
[ https://issues.apache.org/jira/browse/CASSANDRA-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226702#comment-13226702 ] Dave Brosius commented on CASSANDRA-3974: - What happens if a column in a ttl'ed column family has a ttl that's longer than the cf's ttl? Would that be allowed? Per-CF TTL -- Key: CASSANDRA-3974 URL: https://issues.apache.org/jira/browse/CASSANDRA-3974 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Priority: Minor Per-CF TTL would allow compaction optimizations (drop an entire sstable's worth of expired data) that we can't do with per-column. -- 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] [Commented] (CASSANDRA-4008) Unable to operate on Schema column family in cassandra-cli as Schema is a reserved word
[
https://issues.apache.org/jira/browse/CASSANDRA-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223967#comment-13223967
]
Dave Brosius commented on CASSANDRA-4008:
-
schema is defined by lexer token
SCHEMA: 'SCHEMA';
and so 'reduces' to that token as opposed to an identifier.
true of any lexer token
create keyspace keyspace
would probably fail as well.
Unable to operate on Schema column family in cassandra-cli as Schema is a
reserved word
-
Key: CASSANDRA-4008
URL: https://issues.apache.org/jira/browse/CASSANDRA-4008
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Kirk True
Assignee: Kirk True
Priority: Minor
Labels: lhf
Fix For: 1.1.0
Steps:
# Run {{./bin/cassandra-cli}}
# Use the system keyspace ({{use system;}})
# List the rows in the {{Schema}} column family ({{list Schema;}})
Expected:
To see a list of rows.
Actual:
Error message: {{Syntax error at position 5: mismatched input 'Schema'
expecting set 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] [Commented] (CASSANDRA-3575) java.lang.ArrayIndexOutOfBoundsException during scrub
[ https://issues.apache.org/jira/browse/CASSANDRA-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222842#comment-13222842 ] Dave Brosius commented on CASSANDRA-3575: - It seems odd to me that the generations structure is a hardcoded array of lists (size 8 -- Math.log10(1000 * 1000 * 1000 / maxSSTableSizeInMB)). Changing to ListListSSTableReader would fix the problem one would think. java.lang.ArrayIndexOutOfBoundsException during scrub - Key: CASSANDRA-3575 URL: https://issues.apache.org/jira/browse/CASSANDRA-3575 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.3 Environment: Centos 5.7 16GB Ram 4GB Java Heap Sun JVM Reporter: Tim McLennan INFO [CompactionExecutor:6] 2011-12-05 22:19:28,788 CompactionManager.java (line 477) Scrubbing SSTableReader(path='/var/lib/cassandra/data/cf/Data-hb-256385-Data.db') ERROR [CompactionExecutor:6] 2011-12-05 22:19:30,195 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[CompactionExecutor:6,1,RMI Runtime] java.lang.ArrayIndexOutOfBoundsException: 8 at org.apache.cassandra.db.compaction.LeveledManifest.add(LeveledManifest.java:293) at org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:184) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:141) at org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:481) at org.apache.cassandra.db.DataTracker.replace(DataTracker.java:275) at org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:232) at org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:979) at org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:654) at org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:472) at org.apache.cassandra.db.compaction.CompactionManager.access$300(CompactionManager.java:63) at org.apache.cassandra.db.compaction.CompactionManager$3.call(CompactionManager.java:224) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- 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] [Commented] (CASSANDRA-3952) avoid quadratic startup time in LeveledManifest
[
https://issues.apache.org/jira/browse/CASSANDRA-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221518#comment-13221518
]
Dave Brosius commented on CASSANDRA-3952:
-
Could the SSTableReader just have a field that held what level it was, and is
set when LeveledManifest.add and .remove were called?
avoid quadratic startup time in LeveledManifest
---
Key: CASSANDRA-3952
URL: https://issues.apache.org/jira/browse/CASSANDRA-3952
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Jonathan Ellis
Priority: Minor
Labels: lhf
Fix For: 1.1.1
Checking that each sstable is in the manifest on startup is O(N**2) in the
number of sstables:
{code}
. // ensure all SSTables are in the manifest
for (SSTableReader ssTableReader : cfs.getSSTables())
{
if (manifest.levelOf(ssTableReader) 0)
manifest.add(ssTableReader);
}
{code}
{code}
private int levelOf(SSTableReader sstable)
{
for (int level = 0; level generations.length; level++)
{
if (generations[level].contains(sstable))
return level;
}
return -1;
}
{code}
Note that the contains call is a linear List.contains.
We need to switch to a sorted list and bsearch, or a tree, to support
TB-levels of data in LeveledCompactionStrategy.
--
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] [Commented] (CASSANDRA-3986) Cli shouldn't call FBU.getBroadcastAddress needlessly
[
https://issues.apache.org/jira/browse/CASSANDRA-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220131#comment-13220131
]
Dave Brosius commented on CASSANDRA-3986:
-
Getting user reports that this is causing cli on windows to fail due to not
being able to load the yaml for some reason (when creating keyspaces)
Cli shouldn't call FBU.getBroadcastAddress needlessly
-
Key: CASSANDRA-3986
URL: https://issues.apache.org/jira/browse/CASSANDRA-3986
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.8
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.0.9, 1.1.0
Attachments: 3986.txt
The cli is calling this, which causes yaml to be loaded, but the broadcast
address isn't needed.
{code}
// adding default data center from SimpleSnitch
if (currentStrategyOptions == null ||
currentStrategyOptions.isEmpty())
{
SimpleSnitch snitch = new SimpleSnitch();
MapString, String options = new HashMapString, String();
options.put(snitch.getDatacenter(FBUtilities.getBroadcastAddress()), 1);
ksDef.setStrategy_options(options);
}
{code}
because SimpleSnitch always returns 'datacenter1'
--
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] [Commented] (CASSANDRA-3978) [patch] quell all the warnings around DecoratorKey and generics
[ https://issues.apache.org/jira/browse/CASSANDRA-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220610#comment-13220610 ] Dave Brosius commented on CASSANDRA-3978: - the only specialization is in SecondaryIndexManager, using LocalToken as in public DecoratedKeyLocalToken getIndexKeyFor(ByteBuffer name, ByteBuffer value) probably could de-generify it though. [patch] quell all the warnings around DecoratorKey and generics --- Key: CASSANDRA-3978 URL: https://issues.apache.org/jira/browse/CASSANDRA-3978 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Dave Brosius Priority: Trivial Attachments: quell_decoratorkey_warnings.diff against 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] [Commented] (CASSANDRA-3979) Consider providing error code with exceptions (and documenting them)
[ https://issues.apache.org/jira/browse/CASSANDRA-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220705#comment-13220705 ] Dave Brosius commented on CASSANDRA-3979: - (or exception subclasses) Consider providing error code with exceptions (and documenting them) Key: CASSANDRA-3979 URL: https://issues.apache.org/jira/browse/CASSANDRA-3979 Project: Cassandra Issue Type: Sub-task Components: API Reporter: Sylvain Lebresne Labels: cql3 Fix For: 1.1.1 It could be a good idea to assign documented error code for the different exception raised. Currently, one may have to parse the exception string (say if one wants to know if its 'create keyspace' failed because the keyspace already exists versus other kind of exception), but it means we cannot improve the error message at the risk of breaking client code. Adding documented error codes with the message would avoid 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] [Commented] (CASSANDRA-3965) Cassandra code base has files with import statements having * causing compilation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218581#comment-13218581
]
Dave Brosius commented on CASSANDRA-3965:
-
Yeah there wasn't one, it went in with
https://issues.apache.org/jira/browse/CASSANDRA-3949
Cassandra code base has files with import statements having * causing
compilation failure
---
Key: CASSANDRA-3965
URL: https://issues.apache.org/jira/browse/CASSANDRA-3965
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.8
Environment: Linux
Reporter: Harish Doddi
I tried to download a jar as part of the new unit test I am writing. I ran my
unit test successfully but later if I run ant without ant clean, I run into
the following compilation issue
{code}
build-project:
[echo] apache-cassandra: /Users/harish/workspace/cassandra/build.xml
[javac] Compiling 40 source files to
/Users/harish/workspace/cassandra/build/classes/thrift
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Compiling 568 source files to
/Users/harish/workspace/cassandra/build/classes/main
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/db/ColumnFamilyStore.java:1607:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] public IterableDecoratedKey? keySamples(RangeToken
range)
[javac] ^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:196:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] public CollectionRangeToken getLocalRanges(String table)
[javac] ^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:201:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] public RangeToken getLocalPrimaryRange()
[javac]^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:912:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] public MapRangeToken, ListInetAddress
getRangeToAddressMap(String keyspace)
[javac]^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:1009:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] private MapRangeToken, ListInetAddress
constructRangeToEndpointMap(String keyspace, ListRangeToken ranges)
[javac]
^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:1009:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] private MapRangeToken, ListInetAddress
constructRangeToEndpointMap(String keyspace, ListRangeToken ranges)
[javac] ^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:1438:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] private MultimapInetAddress, RangeToken
getNewSourceRanges(String table, SetRangeToken ranges)
[javac]
^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:1438:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] private MultimapInetAddress, RangeToken
getNewSourceRanges(String table,
[jira] [Commented] (CASSANDRA-3965) Cassandra code base has files with import statements having * causing compilation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217812#comment-13217812
]
Dave Brosius commented on CASSANDRA-3965:
-
I think you are using a newer version of guava ( r08) that has conflicts with
the class Range.
Cassandra should probably import the fully qualified class
import org.apache.cassandra.dht.Range;
to guard against this.
Cassandra code base has files with import statements having * causing
compilation failure
---
Key: CASSANDRA-3965
URL: https://issues.apache.org/jira/browse/CASSANDRA-3965
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.8
Environment: Linux
Reporter: Harish Doddi
I tried to download a jar as part of the new unit test I am writing. I ran my
unit test successfully but later if I run ant without ant clean, I run into
the following compilation issue
{code}
build-project:
[echo] apache-cassandra: /Users/harish/workspace/cassandra/build.xml
[javac] Compiling 40 source files to
/Users/harish/workspace/cassandra/build/classes/thrift
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Compiling 568 source files to
/Users/harish/workspace/cassandra/build/classes/main
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/db/ColumnFamilyStore.java:1607:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] public IterableDecoratedKey? keySamples(RangeToken
range)
[javac] ^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:196:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] public CollectionRangeToken getLocalRanges(String table)
[javac] ^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:201:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] public RangeToken getLocalPrimaryRange()
[javac]^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:912:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] public MapRangeToken, ListInetAddress
getRangeToAddressMap(String keyspace)
[javac]^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:1009:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] private MapRangeToken, ListInetAddress
constructRangeToEndpointMap(String keyspace, ListRangeToken ranges)
[javac]
^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:1009:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] private MapRangeToken, ListInetAddress
constructRangeToEndpointMap(String keyspace, ListRangeToken ranges)
[javac] ^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:1438:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class com.google.common.collect.Range in
com.google.common.collect match
[javac] private MultimapInetAddress, RangeToken
getNewSourceRanges(String table, SetRangeToken ranges)
[javac]
^
[javac]
/Users/harish/workspace/cassandra/src/java/org/apache/cassandra/service/StorageService.java:1438:
reference to Range is ambiguous, both class org.apache.cassandra.dht.Range
in org.apache.cassandra.dht and class
[jira] [Commented] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206830#comment-13206830 ] Dave Brosius commented on CASSANDRA-3772: - With 10,000 inserts i'm seeing the same ratios, which i'm having a hard time describing why as again the hash function itself is about the same time. Evaluate Murmur3-based partitioner -- Key: CASSANDRA-3772 URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Fix For: 1.2 Attachments: try_murmur3.diff MD5 is a relatively heavyweight hash to use when we don't need cryptographic qualities, just a good output distribution. Let's see how much overhead we can save by using Murmur3 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] [Commented] (CASSANDRA-3890) [patch] add clientutil class for building composite column names
[ https://issues.apache.org/jira/browse/CASSANDRA-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13207415#comment-13207415 ] Dave Brosius commented on CASSANDRA-3890: - Sure, thats fine, but it should probably be broken out of CompositeType and moved to packages used by clientutils for consistency. (Didn't see it there, hiding among the java.management classes :) [patch] add clientutil class for building composite column names Key: CASSANDRA-3890 URL: https://issues.apache.org/jira/browse/CASSANDRA-3890 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Dave Brosius Priority: Trivial Attachments: add_composite_builder.diff allow for clients do do CompositeNameBuilder builder = new CompositeNameBuilder(); builder.append(US); builder.append(91210); builder.append(San Mateo); Column col = new Column(builder.getComposite()); BytesType, UTF8Type, LongType, LexicalUUIDType, TimeUUIDType are directly supported, AsciiType and custom types are supported thru a append(byte... value) catchall. -- 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] [Commented] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13207416#comment-13207416 ] Dave Brosius commented on CASSANDRA-3772: - I'd be glad to rework it, but didn't find this mysterious standalone MH3 library when i first was looking, and only found the guava version. Can you post a link as to where i should get this from? Evaluate Murmur3-based partitioner -- Key: CASSANDRA-3772 URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Dave Brosius Fix For: 1.2 Attachments: try_murmur3.diff MD5 is a relatively heavyweight hash to use when we don't need cryptographic qualities, just a good output distribution. Let's see how much overhead we can save by using Murmur3 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] [Commented] (CASSANDRA-3665) [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications
[ https://issues.apache.org/jira/browse/CASSANDRA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205977#comment-13205977 ] Dave Brosius commented on CASSANDRA-3665: - Also ByteBufferUtils pulls in a dependency on commons-lang for the inconsequential public static final ByteBuffer EMPTY_BYTE_BUFFER = ByteBuffer.wrap(ArrayUtils.EMPTY_BYTE_ARRAY); which seems like a pitty. [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications -- Key: CASSANDRA-3665 URL: https://issues.apache.org/jira/browse/CASSANDRA-3665 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.6 Reporter: Dave Brosius Assignee: Eric Evans Fix For: 1.0.8 Attachments: fix_client_util_jar.diff, v1-0001-CASSANDRA-3665-test-to-expose-missing-dependencies.txt, v1-0002-eliminate-dependency-on-FBUtilities.txt clientutil.jar can't be run from a client by itself without the presence of cassandra.jar which seems wrong. Added needed classes to run by itself. -- 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] [Commented] (CASSANDRA-3869) [patch] don't duplicate ByteBuffers when hashing
[ https://issues.apache.org/jira/browse/CASSANDRA-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13203282#comment-13203282 ] Dave Brosius commented on CASSANDRA-3869: - interesting.. i see messagedigest uses ByteBuffer.get for these. ok, thanks for the info. updated patch, altho i suppose this is starting loose value at this point, so closing. [patch] don't duplicate ByteBuffers when hashing Key: CASSANDRA-3869 URL: https://issues.apache.org/jira/browse/CASSANDRA-3869 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Dave Brosius Attachments: dont_dup_bb_for_hash.diff, dont_dup_bb_for_hash2.diff given how often hashing of ByteBuffers occurs, don't duplicate the ByteBuffer when hashing. (trivial - as the byte array was never copied just the BB wrapper -- but 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] [Commented] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199659#comment-13199659 ] Dave Brosius commented on CASSANDRA-3772: - Interestingly, timing just the hashing function itself shows very little difference (statistically irrelevant). Evaluate Murmur3-based partitioner -- Key: CASSANDRA-3772 URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Fix For: 1.2 Attachments: try_murmur3.diff MD5 is a relatively heavyweight hash to use when we don't need cryptographic qualities, just a good output distribution. Let's see how much overhead we can save by using Murmur3 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] [Commented] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199516#comment-13199516 ] Dave Brosius commented on CASSANDRA-3772: - Doing 1000 inserts of a 5 column CF on a single node cluster on a really lousy machine seems to show that the guava murmur hash is significantly slower than MD5. 5x? perhaps. Perhaps it's just the guava implementation, as opposed to the Murmur3 implementation. Evaluate Murmur3-based partitioner -- Key: CASSANDRA-3772 URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Fix For: 1.2 Attachments: try_murmur3.diff MD5 is a relatively heavyweight hash to use when we don't need cryptographic qualities, just a good output distribution. Let's see how much overhead we can save by using Murmur3 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] [Commented] (CASSANDRA-3814) [patch] add assertion message for deserializing columns assertion failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196473#comment-13196473
]
Dave Brosius commented on CASSANDRA-3814:
-
ah didn't no user would post bug 3813
[patch] add assertion message for deserializing columns assertion failure
-
Key: CASSANDRA-3814
URL: https://issues.apache.org/jira/browse/CASSANDRA-3814
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Dave Brosius
Priority: Trivial
Attachments: assert_msg.diff
use was doing
create column family report_by_account_content with comparator=UTF8Type;
update column family report_by_account_content with comparator=UTF8Type and
column_metadata = [{ column_name:'meta:account-id',
validation_class:UTF8Type,index_type:KEYS},{ column_name:'meta:filter-hash',
validation_class:UTF8Type,index_type:KEYS}];
assert was generated but not represented to client. adding message:
// column name format cf:column name:attribute name
String[] components =
columns.getComparator().getString(column.name()).split(:);
assert components.length == 3 : Number of Comparator components not 3: +
Arrays.toString(components);
--
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] [Commented] (CASSANDRA-3814) [patch] add assertion message for deserializing columns assertion failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196577#comment-13196577
]
Dave Brosius commented on CASSANDRA-3814:
-
as for being a dup, i'm assuming the error i got was the same as the user, but
he didn't debug the server side so i can't say for sure.
[patch] add assertion message for deserializing columns assertion failure
-
Key: CASSANDRA-3814
URL: https://issues.apache.org/jira/browse/CASSANDRA-3814
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Dave Brosius
Priority: Trivial
Attachments: assert_msg.diff
use was doing
create column family report_by_account_content with comparator=UTF8Type;
update column family report_by_account_content with comparator=UTF8Type and
column_metadata = [{ column_name:'meta:account-id',
validation_class:UTF8Type,index_type:KEYS},{ column_name:'meta:filter-hash',
validation_class:UTF8Type,index_type:KEYS}];
assert was generated but not represented to client. adding message:
// column name format cf:column name:attribute name
String[] components =
columns.getComparator().getString(column.name()).split(:);
assert components.length == 3 : Number of Comparator components not 3: +
Arrays.toString(components);
--
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] [Commented] (CASSANDRA-2877) git-cassandra-angosso-angosso.html
[ https://issues.apache.org/jira/browse/CASSANDRA-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195657#comment-13195657 ] Dave Brosius commented on CASSANDRA-2877: - this guy is a major spammer Spams the wiki, and now issues git-cassandra-angosso-angosso.html -- Key: CASSANDRA-2877 URL: https://issues.apache.org/jira/browse/CASSANDRA-2877 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 0.8.0 Environment: https://ango...@github.com/angosso/git-cassandra-angosso-angosso.html.git http://angosso.git.sourceforge.net/git/gitweb-index.cgi configure include/config.h dlls/Makefile.in programs/Makefile.in */Makefile Reporter: Roger Mbiama Priority: Critical Labels: features Fix For: 0.8.0 Attachments: CFMetaData.java, Config.java, ConfigurationException.java, ConfigurationException.java, Converter.java, DatabaseDescriptor.java, ReplicationStrategy.java, RequestSchedulerOptions.java, cassandra.bat, config-converter, json2sstable.bat, netbeans, netbeans.exe, sstable2json.bat Original Estimate: 504h Remaining Estimate: 504h Requirements * Java = 1.6 (OpenJDK and Sun have been tested) Getting started --- This short guide will walk you through getting a basic one node cluster up and running, and demonstrate some simple reads and writes. * tar -zxvf apache-cassandra-$VERSION.tar.gz * cd apache-cassandra-$VERSION * sudo mkdir -p /var/log/cassandra * sudo chown -R `angosso` /var/log/cassandra * sudo mkdir -p /var/lib/cassandra * sudo chown -R `angosso` /var/lib/cassandra Note: The sample configuration files in conf/ determine the file-system locations Cassandra uses for logging and data storage. You are free to change these to suit your own environment and adjust the path names used here accordingly. Now that we're ready, let's start it up! * bin/cassandra -f Running the startup script with the -f argument will cause Cassandra to remain in the foreground and log to standard out. Now let's try to read and write some data using the command line client. * bin/cassandra-cli --host http://angosso1.w02.winhost.com --port 9160 The command line client is interactive so if everything worked you should be sitting in front of a prompt... Connected to http://angosso1.w02.winhost.com/9160 Welcome to cassandra CLI. Type 'help' or '?' for help. Type 'quit' or 'exit' to quit. cassandra As the banner says, you can use 'help' or '?' to see what the CLI has to offer, and 'quit' or 'exit' when you've had enough fun. But lets try something slightly more interesting... cassandra set Keyspace1.Standard2['rmbiama']['first'] = 'Roger' Value inserted. cassandra set Keyspace1.Standard2['rmbiama']['last'] = 'mbiama' Value inserted. cassandra set Keyspace1.Standard2['rmbiama']['age'] = '54' Value inserted. cassandra get Keyspace1.Standard2['rmbiama'] (column=age, value=54; timestamp=1249930062801) (column=first, value=Roger; timestamp=1249930053103) (column=last, value=Mbiama; timestamp=1249930058345) Returned 3 rows. cassandra If your session looks similar to what's above, congrats, your single node cluster is operational! But what exactly was all of that? Let's break it down into pieces and see. set Keyspace1.Standard2['rmbiama']['angosso / git-cassandra-angosso-angosso.html'] = 'Roger' \\ \\ \ \\ \_ key \ \_ value \\ \_ column \_ keyspace \_ column family Data stored in Cassandra is associated with a column family (Standard2), which in turn is associated with a keyspace (Keyspace1). In the example above, we set the value 'Roger' in the 'first' column for key 'rmbiama'. Mirror of Apache Cassandra (incubating); install schematool in debian package A commit object contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. GIT-cassandra/angosso/angosso.html its parents.[rogerM] -- 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] [Commented] (CASSANDRA-3787) [patch] fix bad comparison of column name against * or 1
[ https://issues.apache.org/jira/browse/CASSANDRA-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193806#comment-13193806 ] Dave Brosius commented on CASSANDRA-3787: - dang it.. thanks, good catch. [patch] fix bad comparison of column name against * or 1 Key: CASSANDRA-3787 URL: https://issues.apache.org/jira/browse/CASSANDRA-3787 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Labels: cql Fix For: 1.1 Attachments: bad_column_compare.diff code does (!selectClause.get(0).equals(*) !selectClause.get(0).equals(1))) which is a ColumnDefinition against a string changed to String columnName = selectClause.get(0).toString(); if (!columnName.equals(*) !columnName.equals(1)) -- 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] [Commented] (CASSANDRA-3665) [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications
[ https://issues.apache.org/jira/browse/CASSANDRA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194378#comment-13194378 ] Dave Brosius commented on CASSANDRA-3665: - Tested with patch applied, appears to resolve the issues I found. thanks. [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications -- Key: CASSANDRA-3665 URL: https://issues.apache.org/jira/browse/CASSANDRA-3665 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.6 Reporter: Dave Brosius Assignee: Dave Brosius Attachments: fix_client_util_jar.diff, v1-0001-CASSANDRA-3665-test-to-expose-missing-dependencies.txt, v1-0002-eliminate-dependency-on-FBUtilities.txt clientutil.jar can't be run from a client by itself without the presence of cassandra.jar which seems wrong. Added needed classes to run by itself. -- 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] [Commented] (CASSANDRA-3763) compactionstats throws ArithmeticException: / by zero
[ https://issues.apache.org/jira/browse/CASSANDRA-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194466#comment-13194466 ] Dave Brosius commented on CASSANDRA-3763: - any chance you're specifying a compaction strategy option of sstable_size_in_mb = 0 ? compactionstats throws ArithmeticException: / by zero - Key: CASSANDRA-3763 URL: https://issues.apache.org/jira/browse/CASSANDRA-3763 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.7 Environment: debian linux - openvz kernel, oracle java 1.6.0.26 Reporter: Zenek Kraweznik Priority: Minor compactionstats looks like this: # nodetool -h localhost compactionstats Exception in thread main java.lang.ArithmeticException: / by zero at org.apache.cassandra.db.compaction.LeveledManifest.getEstimatedTasks(LeveledManifest.java:435) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getEstimatedRemainingTasks(LeveledCompactionStrategy.java:128) at org.apache.cassandra.db.compaction.CompactionManager.getPendingTasks(CompactionManager.java:1060) 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 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65) at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1404) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:600) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) 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) # nodetool is working fine in other actions: # nodetool -h localhost netstats Mode: NORMAL Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 0 2 Responses n/a 0 1810 # -- 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] [Commented] (CASSANDRA-3795) Unable to join the mailing list
[ https://issues.apache.org/jira/browse/CASSANDRA-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194503#comment-13194503 ] Dave Brosius commented on CASSANDRA-3795: - Are you sending an email to user-subscr...@cassandra.apache.org ? Unable to join the mailing list --- Key: CASSANDRA-3795 URL: https://issues.apache.org/jira/browse/CASSANDRA-3795 Project: Cassandra Issue Type: Bug Reporter: Krassimir Kostov Hi! Since Jan 25, I have been trying several times to join the mailing list at cassandra-u...@incubator.apache.org, but each time I tried, I got the following email. Please help resolving the issue. Thanks! Date: Fri, 27 Jan 2012 04:30:59 + From: mailer-dae...@apache.org To: x...@yyy.zzz Subject: failure notice Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. cassandra-user-allow-subscribe-XXX=yyy@incubator.apache.org: This mailing list has moved to user at cassandra.apache.org. --- Below this line is a copy of the message. -- 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] [Commented] (CASSANDRA-3665) [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications
[ https://issues.apache.org/jira/browse/CASSANDRA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193445#comment-13193445 ] Dave Brosius commented on CASSANDRA-3665: - I basically kept adding classes until the NoClassDefFoundExceptions stopped. [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications -- Key: CASSANDRA-3665 URL: https://issues.apache.org/jira/browse/CASSANDRA-3665 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.6 Reporter: Dave Brosius Assignee: Dave Brosius Attachments: fix_client_util_jar.diff clientutil.jar can't be run from a client by itself without the presence of cassandra.jar which seems wrong. Added needed classes to run by itself. -- 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] [Commented] (CASSANDRA-3665) [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications
[ https://issues.apache.org/jira/browse/CASSANDRA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193443#comment-13193443 ] Dave Brosius commented on CASSANDRA-3665: - Sorry i should have added that at the time, it was post 1.0 for sure. But i still see it now, I am using UUIDGen.makeType1UUIDFromHost and it's throwing exceptions UUIDGen.makeNode(InetAddress) line: 198 UUIDGen.getClockSeqAndNode(InetAddress) line: 158 UUIDGen.makeType1UUIDFromHost(InetAddress) line: 61 [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications -- Key: CASSANDRA-3665 URL: https://issues.apache.org/jira/browse/CASSANDRA-3665 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.6 Reporter: Dave Brosius Assignee: Dave Brosius Attachments: fix_client_util_jar.diff clientutil.jar can't be run from a client by itself without the presence of cassandra.jar which seems wrong. Added needed classes to run by itself. -- 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] [Commented] (CASSANDRA-3755) NPE on invalid CQL DELETE command
[
https://issues.apache.org/jira/browse/CASSANDRA-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192629#comment-13192629
]
Dave Brosius commented on CASSANDRA-3755:
-
Arg, my apologies, posted to wrong bug.
NPE on invalid CQL DELETE command
-
Key: CASSANDRA-3755
URL: https://issues.apache.org/jira/browse/CASSANDRA-3755
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: paul cannon
Assignee: Dave Brosius
Priority: Minor
Labels: cql
Fix For: 1.0.8
Attachments: unknown_cf.diff
The CQL command {{delete from k where key='bar';}} causes Cassandra to hit a
NullPointerException when the k column family does not exist, and it
subsequently closes the Thrift connection instead of reporting an IRE or
whatever. This is probably wrong.
--
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] [Commented] (CASSANDRA-3755) NPE on invalid CQL DELETE command
[
https://issues.apache.org/jira/browse/CASSANDRA-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192780#comment-13192780
]
Dave Brosius commented on CASSANDRA-3755:
-
yes
NPE on invalid CQL DELETE command
-
Key: CASSANDRA-3755
URL: https://issues.apache.org/jira/browse/CASSANDRA-3755
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: paul cannon
Assignee: Dave Brosius
Priority: Minor
Labels: cql
Fix For: 1.0.8
Attachments: unknown_cf.diff
The CQL command {{delete from k where key='bar';}} causes Cassandra to hit a
NullPointerException when the k column family does not exist, and it
subsequently closes the Thrift connection instead of reporting an IRE or
whatever. This is probably wrong.
--
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] [Commented] (CASSANDRA-3769) Allow for comments in a cassandra-cli file
[
https://issues.apache.org/jira/browse/CASSANDRA-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192910#comment-13192910
]
Dave Brosius commented on CASSANDRA-3769:
-
There is support for commenting, albeit not exactly what you are requesting...
lines start with -- are line comments
you can also use /* and */ as long as those symbols are first on the line, eg:
-- create a keyspce
create keyspace foobar;
/*
now lets see it
*/
use foobar;
describe foobar;
Allow for comments in a cassandra-cli file
--
Key: CASSANDRA-3769
URL: https://issues.apache.org/jira/browse/CASSANDRA-3769
Project: Cassandra
Issue Type: Improvement
Components: Tools
Affects Versions: 1.0.6
Environment: Amazon Linux w/ Apache Cassandra 1.0.6
Reporter: Andrew Halloran
Priority: Trivial
Labels: cassandra-cli
I use the cassandra-cli to create schemas, update schemas, and make other
calls to interrogate keyspaces and columns. I load pre-written statements
from files using the -f option, example: bin/cassandra-cli -host localhost
-port 9160 -f mystatements.txt. It would be useful if I could comment my
statement files with comments similar to how you can comment script and
C++/Java code.
Example contents of mystatements.txt file:
update column family users// This is my column which
holds all my user information
with comparator = UTF8Type// My column names are all
strings so I will use UTF8Type
and key_validation_class = UTF8Type // My row key values are also
UTF8Type
and default_validation_class = UTF8Type // Column values will be
UTF8Type
and column_metadata = [
{column_name: username, validation_class: UTF8Type}, // This
column stores the login name of the user
{column_name: realname, validation_class: UTF8Type}];// This
column stores the real world name of user
--
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] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190612#comment-13190612 ] Dave Brosius commented on CASSANDRA-3706: - Would it be possible to create dynamic RF values based on live endpoints, that would work sort of similar to how consistency specifications work?, ie RFs ALL - equal to the number of live endpoints QUORUM - equal to more than have of the live endpoints, --perhaps other constants-- these constants could be mapped to negative value constants, i suppose, but would be calculated at the time they were needed, and not at startup. Back up configuration files on startup -- Key: CASSANDRA-3706 URL: https://issues.apache.org/jira/browse/CASSANDRA-3706 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: lhf Fix For: 1.1 Attachments: save_configuration.diff, save_configuration_2.diff, save_configuration_3.diff, save_configuration_4.diff Snapshot can backup user data, but it's also nice to be able to have known-good configurations saved as well in case of accidental snafus or even catastrophic loss of a cluster. If we check for changes to cassandra.yaml, cassandra-env.sh, and maybe log4j-server.properties on startup, we can back them up to a columnfamily that can then be handled by normal snapshot/backup procedures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190148#comment-13190148 ] Dave Brosius commented on CASSANDRA-3706: - I was assuming that there would n rows in this CF, one per cluster member, each with it's own yaml. This calls for a non hard coded key, unless you want to make n columns for each machine. As for the digest as the column name, when the yaml changes and you want to update the contents in the row, you would want to remove the old column, but you don't really know what the old column name is now. Perhaps you could just delete columns that you don't know what they are but that seems a little iffy to me. Back up configuration files on startup -- Key: CASSANDRA-3706 URL: https://issues.apache.org/jira/browse/CASSANDRA-3706 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: lhf Fix For: 1.1 Attachments: save_configuration.diff, save_configuration_2.diff, save_configuration_3.diff Snapshot can backup user data, but it's also nice to be able to have known-good configurations saved as well in case of accidental snafus or even catastrophic loss of a cluster. If we check for changes to cassandra.yaml, cassandra-env.sh, and maybe log4j-server.properties on startup, we can back them up to a columnfamily that can then be handled by normal snapshot/backup procedures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190272#comment-13190272 ] Dave Brosius commented on CASSANDRA-3706: - Ah, the fact that system was local-only had escaped me, this makes your original comments (brandon) make alot more sense. As Jonathan points out, it makes no sense to save this information in the system keyspace then, as the point of this storage is for easing disaster recovery, and if the node goes down, the yaml as depicted in the keyspace is no more likely to survive than the yaml file in the conf directory. If this feature is to have value at all, it must be replicated, so a secondary quasi-system keyspace that is replicated would be needed. I planned to add support for the cassandra-env and log4j files as well, but wanted to get feed back first before proceeding with those as those files are not first class files in cassandra as the yaml file is, and thus marginally more tricky. Glad I did :) Let me know what you want to do, and i'll be glad to go forward, or cancel whatever is appropriate. Back up configuration files on startup -- Key: CASSANDRA-3706 URL: https://issues.apache.org/jira/browse/CASSANDRA-3706 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: lhf Fix For: 1.1 Attachments: save_configuration.diff, save_configuration_2.diff, save_configuration_3.diff Snapshot can backup user data, but it's also nice to be able to have known-good configurations saved as well in case of accidental snafus or even catastrophic loss of a cluster. If we check for changes to cassandra.yaml, cassandra-env.sh, and maybe log4j-server.properties on startup, we can back them up to a columnfamily that can then be handled by normal snapshot/backup procedures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
