[jira] [Commented] (CASSANDRA-6402) cannot query using DynamicCompositeType
[ https://issues.apache.org/jira/browse/CASSANDRA-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831253#comment-13831253 ] Sylvain Lebresne commented on CASSANDRA-6402: - While I agree with not supporting DCT specifically in cqlsh, it wouldn't be crazy to have a default strategy in cqlsh to handle types it doesn't know. Typically, printing it as hex bytes feels appropriate to me, crashing, less so. cannot query using DynamicCompositeType --- Key: CASSANDRA-6402 URL: https://issues.apache.org/jira/browse/CASSANDRA-6402 Project: Cassandra Issue Type: Bug Components: API, Core Reporter: victorsosa Priority: Minor HI, I cannot query using DynamicCompositeType. And this is how it is define the column family: DynamicCompositeType (l=LongType,t=TimeUUIDType,s=UTF8Type,S=UTF8Type(reversed=true),L=LongType(reversed=true),T=TimeUUIDType(reversed=true)) this code is from the project countandra: csdb.createColumnFamily( CassandraStorage.s_keySpace, countandraCF, UTF8Type, DynamicCompositeType (l=LongType,t=TimeUUIDType,s=UTF8Type,S=UTF8Type(reversed=true),L=LongType(reversed=true),T=TimeUUIDType(reversed=true)), CounterColumnType); you can get the code for test from: https://github.com/milindparikh/Countandra The Hector api is calling the same column family with data and it is WORKING FINE, the issue is only when I am trying to use CQL to query the table ddcc. NOTE: the project is using cassandra 1.0.1, I updated it to cassandra 2.0.2 If I try something like: select * from ddcc; Error get trying to query a table that have a DynamicCompositeType cqlsh use countandra; cqlsh:countandra select * from ddcc; Traceback (most recent call last): File ./cqlsh, line 901, in perform_statement_untraced self.cursor.execute(statement, decoder=decoder) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 81, in execute return self.process_execution_results(response, decoder=decoder) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py, line 116, in process_execution_results self.get_metadata_info(self.result[0]) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 97, in get_metadata_info name, nbytes, vtype, ctype = self.get_column_metadata(colid) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 104, in get_column_metadata return self.decoder.decode_metadata_and_type(column_id) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/decoders.py, line 40, in decode_metadata_and_type valdtype = cqltypes.lookup_casstype(validator) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cqltypes.py, line 145, in lookup_casstype raise ValueError(Don't know how to parse type string %r: %s % (casstype, e)) ValueError: Don't know how to parse type string 'org.apache.cassandra.db.marshal.DynamicCompositeType(T=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType),t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,S=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.UTF8Type),L=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.LongType),l=org.apache.cassandra.db.marshal.LongType)': weird characters '=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType),t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,S=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.UTF8Type),L=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.LongType),l=org.apache.cassandra.db.marshal.LongType)' at end -- This message was sent by Atlassian JIRA (v6.1#6144)
Git Push Summary
Updated Tags: refs/tags/1.2.12-tentative [deleted] 026865f2a
Git Push Summary
Updated Tags: refs/tags/cassandra-1.2.12 [created] d4d273dcc
[jira] [Commented] (CASSANDRA-6402) cannot query using DynamicCompositeType
[ https://issues.apache.org/jira/browse/CASSANDRA-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831256#comment-13831256 ] Aleksey Yeschenko commented on CASSANDRA-6402: -- bq. While I agree with not supporting DCT specifically in cqlsh, it wouldn't be crazy to have a default strategy in cqlsh to handle types it doesn't know. Typically, printing it as hex bytes feels appropriate to me, crashing, less so. We do. DCT is the exception here, b/c the type itself can't be parsed. 'regular' custom type implementations are just shown as blobs. cannot query using DynamicCompositeType --- Key: CASSANDRA-6402 URL: https://issues.apache.org/jira/browse/CASSANDRA-6402 Project: Cassandra Issue Type: Bug Components: API, Core Reporter: victorsosa Priority: Minor HI, I cannot query using DynamicCompositeType. And this is how it is define the column family: DynamicCompositeType (l=LongType,t=TimeUUIDType,s=UTF8Type,S=UTF8Type(reversed=true),L=LongType(reversed=true),T=TimeUUIDType(reversed=true)) this code is from the project countandra: csdb.createColumnFamily( CassandraStorage.s_keySpace, countandraCF, UTF8Type, DynamicCompositeType (l=LongType,t=TimeUUIDType,s=UTF8Type,S=UTF8Type(reversed=true),L=LongType(reversed=true),T=TimeUUIDType(reversed=true)), CounterColumnType); you can get the code for test from: https://github.com/milindparikh/Countandra The Hector api is calling the same column family with data and it is WORKING FINE, the issue is only when I am trying to use CQL to query the table ddcc. NOTE: the project is using cassandra 1.0.1, I updated it to cassandra 2.0.2 If I try something like: select * from ddcc; Error get trying to query a table that have a DynamicCompositeType cqlsh use countandra; cqlsh:countandra select * from ddcc; Traceback (most recent call last): File ./cqlsh, line 901, in perform_statement_untraced self.cursor.execute(statement, decoder=decoder) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 81, in execute return self.process_execution_results(response, decoder=decoder) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py, line 116, in process_execution_results self.get_metadata_info(self.result[0]) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 97, in get_metadata_info name, nbytes, vtype, ctype = self.get_column_metadata(colid) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 104, in get_column_metadata return self.decoder.decode_metadata_and_type(column_id) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/decoders.py, line 40, in decode_metadata_and_type valdtype = cqltypes.lookup_casstype(validator) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cqltypes.py, line 145, in lookup_casstype raise ValueError(Don't know how to parse type string %r: %s % (casstype, e)) ValueError: Don't know how to parse type string 'org.apache.cassandra.db.marshal.DynamicCompositeType(T=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType),t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,S=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.UTF8Type),L=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.LongType),l=org.apache.cassandra.db.marshal.LongType)': weird characters '=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType),t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,S=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.UTF8Type),L=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.LongType),l=org.apache.cassandra.db.marshal.LongType)' at end -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6402) cannot query using DynamicCompositeType
[ https://issues.apache.org/jira/browse/CASSANDRA-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831262#comment-13831262 ] Sylvain Lebresne commented on CASSANDRA-6402: - Then can't we just bail on the parsing and use the same treatment as 'regular' custom types? Being pedantic, it would actually be possible for a custom type to use the same kind of definition than DCT. cannot query using DynamicCompositeType --- Key: CASSANDRA-6402 URL: https://issues.apache.org/jira/browse/CASSANDRA-6402 Project: Cassandra Issue Type: Bug Components: API, Core Reporter: victorsosa Priority: Minor HI, I cannot query using DynamicCompositeType. And this is how it is define the column family: DynamicCompositeType (l=LongType,t=TimeUUIDType,s=UTF8Type,S=UTF8Type(reversed=true),L=LongType(reversed=true),T=TimeUUIDType(reversed=true)) this code is from the project countandra: csdb.createColumnFamily( CassandraStorage.s_keySpace, countandraCF, UTF8Type, DynamicCompositeType (l=LongType,t=TimeUUIDType,s=UTF8Type,S=UTF8Type(reversed=true),L=LongType(reversed=true),T=TimeUUIDType(reversed=true)), CounterColumnType); you can get the code for test from: https://github.com/milindparikh/Countandra The Hector api is calling the same column family with data and it is WORKING FINE, the issue is only when I am trying to use CQL to query the table ddcc. NOTE: the project is using cassandra 1.0.1, I updated it to cassandra 2.0.2 If I try something like: select * from ddcc; Error get trying to query a table that have a DynamicCompositeType cqlsh use countandra; cqlsh:countandra select * from ddcc; Traceback (most recent call last): File ./cqlsh, line 901, in perform_statement_untraced self.cursor.execute(statement, decoder=decoder) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 81, in execute return self.process_execution_results(response, decoder=decoder) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py, line 116, in process_execution_results self.get_metadata_info(self.result[0]) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 97, in get_metadata_info name, nbytes, vtype, ctype = self.get_column_metadata(colid) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 104, in get_column_metadata return self.decoder.decode_metadata_and_type(column_id) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/decoders.py, line 40, in decode_metadata_and_type valdtype = cqltypes.lookup_casstype(validator) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cqltypes.py, line 145, in lookup_casstype raise ValueError(Don't know how to parse type string %r: %s % (casstype, e)) ValueError: Don't know how to parse type string 'org.apache.cassandra.db.marshal.DynamicCompositeType(T=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType),t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,S=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.UTF8Type),L=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.LongType),l=org.apache.cassandra.db.marshal.LongType)': weird characters '=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType),t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,S=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.UTF8Type),L=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.LongType),l=org.apache.cassandra.db.marshal.LongType)' at end -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6402) cannot query using DynamicCompositeType
[ https://issues.apache.org/jira/browse/CASSANDRA-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831268#comment-13831268 ] Aleksey Yeschenko commented on CASSANDRA-6402: -- The issue lies in deep cassandra-dbapi2 internals, not in cqlsh. It will go away once we switch from cassandra-dbapi2 to python-driver for cqlsh (CASSANDRA-6307). cannot query using DynamicCompositeType --- Key: CASSANDRA-6402 URL: https://issues.apache.org/jira/browse/CASSANDRA-6402 Project: Cassandra Issue Type: Bug Components: API, Core Reporter: victorsosa Priority: Minor HI, I cannot query using DynamicCompositeType. And this is how it is define the column family: DynamicCompositeType (l=LongType,t=TimeUUIDType,s=UTF8Type,S=UTF8Type(reversed=true),L=LongType(reversed=true),T=TimeUUIDType(reversed=true)) this code is from the project countandra: csdb.createColumnFamily( CassandraStorage.s_keySpace, countandraCF, UTF8Type, DynamicCompositeType (l=LongType,t=TimeUUIDType,s=UTF8Type,S=UTF8Type(reversed=true),L=LongType(reversed=true),T=TimeUUIDType(reversed=true)), CounterColumnType); you can get the code for test from: https://github.com/milindparikh/Countandra The Hector api is calling the same column family with data and it is WORKING FINE, the issue is only when I am trying to use CQL to query the table ddcc. NOTE: the project is using cassandra 1.0.1, I updated it to cassandra 2.0.2 If I try something like: select * from ddcc; Error get trying to query a table that have a DynamicCompositeType cqlsh use countandra; cqlsh:countandra select * from ddcc; Traceback (most recent call last): File ./cqlsh, line 901, in perform_statement_untraced self.cursor.execute(statement, decoder=decoder) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 81, in execute return self.process_execution_results(response, decoder=decoder) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py, line 116, in process_execution_results self.get_metadata_info(self.result[0]) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 97, in get_metadata_info name, nbytes, vtype, ctype = self.get_column_metadata(colid) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cursor.py, line 104, in get_column_metadata return self.decoder.decode_metadata_and_type(column_id) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/decoders.py, line 40, in decode_metadata_and_type valdtype = cqltypes.lookup_casstype(validator) File ./../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cqltypes.py, line 145, in lookup_casstype raise ValueError(Don't know how to parse type string %r: %s % (casstype, e)) ValueError: Don't know how to parse type string 'org.apache.cassandra.db.marshal.DynamicCompositeType(T=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType),t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,S=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.UTF8Type),L=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.LongType),l=org.apache.cassandra.db.marshal.LongType)': weird characters '=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType),t=org.apache.cassandra.db.marshal.TimeUUIDType,s=org.apache.cassandra.db.marshal.UTF8Type,S=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.UTF8Type),L=org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.LongType),l=org.apache.cassandra.db.marshal.LongType)' at end -- This message was sent by Atlassian JIRA (v6.1#6144)
Git Push Summary
Updated Tags: refs/tags/2.0.3-tentative [deleted] 3c9760bdb
Git Push Summary
Updated Tags: refs/tags/cassandra-2.0.3 [created] 7c21e122f
[jira] [Commented] (CASSANDRA-6401) Clustering order by property does not support when the column name is written in uppercase
[ https://issues.apache.org/jira/browse/CASSANDRA-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831347#comment-13831347 ] DIKSHA KUSHWAH commented on CASSANDRA-6401: --- why it is not needed with lower case? we can create table without quote with lower case num. Clustering order by property does not support when the column name is written in uppercase --- Key: CASSANDRA-6401 URL: https://issues.apache.org/jira/browse/CASSANDRA-6401 Project: Cassandra Issue Type: Bug Components: Core Environment: Windows 7 64 bit Reporter: DIKSHA KUSHWAH Database Version : CASSANDRA 2.0.1 1. Connect cassandra 2.0.1 and execute following query:- CREATE TABLE test.cat ( cache text, num int, PRIMARY KEY(cache,num) ) WITH CLUSTERING ORDER BY (num DESC); 2. Now execute following query:- CREATE TABLE DOG ( CACHE text, NUM int, PRIMARY KEY(CACHE,NUM) ) WITH CLUSTERING ORDER BY (NUM DESC); 3. When we create table cat,it is successfully created but when we create table DOG it gives error Missing CLUSTERING ORDER for column NUM because Table DOG column name NUM is in upper case and Table CAT column name num is in lower case. 4. Cassandra supports when we create a Table with column names in upper case without CLUSTERING ORDER BY property then it should also support this property with upper case column names. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-5417) Push composites support in the storage engine
[
https://issues.apache.org/jira/browse/CASSANDRA-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831351#comment-13831351
]
Sylvain Lebresne commented on CASSANDRA-5417:
-
Thanks for the review.
bq. 0xFF looks suspicious to me - should perhaps be 0x?
Correct, good catch (pushed a fix to the same branch as before).
bq. It looks like we're interning TimeUUIDType column identifiers
I don't think that's the case but we may have to be a little more precise here.
Bug notwithstanding, we only intern names that are part of the column_metadata
in thrift parlance. Now thrift does let you declare a column_metadata that is a
timeUUID (it's useless and probably nobody does it, but it's possible) but even
in that case, we'll only intern the timeUUID that were declared. We do not
intern dynamic names in particular if that is what you meant (contrarily to the
current code I might add).
bq. CellName is confusing, as it isn't a name-of-a-cell, but a Cell-with-a-name
Well, actually no. It *is* a name-of-a-cell. At that point, I need to add that
what we refer as 'cell' nowadays is what is currently the Column class.
Obviously, the naming would be a lot more sensible if the Column class was
actually named Cell, and we plan on changing that (CASSANDRA-6063), but I
didn't wanted to include it in this patch-set because it's big enough as it is
(CASSANDRA-6063 is marked 3.0 but I'm definitively for doing at least the
Column-Cell renaming along with this patch (though I'd leave the rest of
CASSANDRA-6063 for later)). Anyway, this also means than in your nits patch,
I'd rather not do the cellNameFromByteBuffer-cellFromByteBuffer renaming.
bq. Compound(.*)CellName was also a little confusing (to me, at least), suggest
either Prefixed/Clustered and (Blank)/Unclustered
Can't say I'm overjoy with Compound myself. However, Prefixed and/or Clustered
doesn't really apply here (a simple cell name is not more or less
prefixed/clustered than a compound one) so I don't think it's better. The
difference between Simple and Compound (using the naming of the patch) is
largely an implementation detail, namely whether the underlying encoding starts
by 'number of components' or not (I would have loved not leaking the
isCompound() method in the CellName interface in particular, to really nail the
point that it's an implementation detail (for backward compatibility) but there
still is a handful of places where we kind of need it so I've let it be).
{quote}
Remove Sparse from *SparseCellName - misleading, really it is just !Dense, so
leave out Dense from the name
{quote}
At the risk of sounding obtuse, I've tried that initially and I kind of like it
the way it is. Let me note that the Sparse naming doesn't really leak outside
the 'composite' packages, most of the code just use the 'isDense' method of
CellName and that's it. But as far as the implementations of CellName goes, I
think SimpleCellName would suggest it's somewhat a super-class of
SimpleDenseCellName which it's not (see the point below too). We do have 4
largely orthogonal layout and I like making that very explicit in the
implementation names. Probably a matter of personal preference though.
bq. I would possibly suggest removing CellName interface, and having
SimpleSparseCellName be simply NamedCell
That would be wrong imo. There is no meaningful inheritance relations between
the cell names implementations (each pair of implementations do share a number
of characteristics, which is why there is a few Abstract classes to avoid code
duplication, but at the concrete implementation level there is no inheritance
relation). I also like having CellName being an interface because that allows
to cleanly have a few specific implementations like the EMPTY one (and the
FakeCellName from ColumnSlice, though that one is largely a hack so it's
probably a bad example).
bq. Also, suggest renaming CompositeBound to one of BoundedComposite
Good idea.
bq. Changed toByteBuffer to always return a ByteBuffer that cannot affect the
state of the callee, and modified callers that were using .duplicate() to no
longer do so
I'd rather not. We have an implicit rule in the code base that a caller should
never expect it can modify the state of a ByteBuffer and it should call
duplicate() if it needs to (one goal being to avoid defensive duplicate() when
it's not needed since most of the code is written in a way that don't modify
the ByteBuffers anyway) so the patch is consistent with the code base in that
respect. Besides, in this particular case, thrift queries will call
toByteBuffer() all the time without needing the duplication so leaving it to
the caller does save some.
bq. Following code comment in CompositeType appears to be incomplete
Definitively not the most clear comment but as far as I can tell it's not
incomplete. Can you clarify what you
[jira] [Commented] (CASSANDRA-6234) Add metrics for native protocols
[ https://issues.apache.org/jira/browse/CASSANDRA-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831354#comment-13831354 ] Sylvain Lebresne commented on CASSANDRA-6234: - Yeah, let's start with that for this ticket. We can always add more later if more is needed. Add metrics for native protocols Key: CASSANDRA-6234 URL: https://issues.apache.org/jira/browse/CASSANDRA-6234 Project: Cassandra Issue Type: New Feature Reporter: Adam Hattrell Assignee: Mikhail Stepura Attachments: Oracle_Java_Mission_Control_2013-11-22_15-50-09.png It would be very useful to expose metrics related to the native protocol. Initially I have a user that would like to be able to monitor the usage of native transport threads. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-5417) Push composites support in the storage engine
[ https://issues.apache.org/jira/browse/CASSANDRA-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831386#comment-13831386 ] Benedict commented on CASSANDRA-5417: - bq. Bug notwithstanding, we only intern names that are part of the column_metadata in thrift parlance Good point, I misread this at the start of processing the patch, should have confirmed once I'd got a proper handle on it. bq. Well, actually no. It is a name-of-a-cell. ... the naming would be a lot more sensible if the Column class was actually named Cell, and we plan on changing that... Well, it seems to me the nomenclature is a little confused because we're overloading the name with data. This is parcelled up in the Prefix business too. A Simple cell name isn't really prefixed/clustered (by the terminology of CQL), and is simply a name-of-a-cell, but when we're mungung data into the name to support our clustering behaviour it becomes (to me) a (part-of-a-)cell-with-a-name. These were simply suggestions for maybe clarifying though, after struggling to grasp it initially. Since I understand what's going on now, I won't lose much sleep over the naming, and I can now see where you're coming from. I certainly agree that it's used to identify a cell, so I'll leave it be. Sparse in particular threw me, as I can't see a reason for the moniker, and in normal English usage it means more than 'not dense', but I won't lose any sleep over it either. bq. There is no meaningful inheritance relations between the cell names implementations This was definitely my most tentative suggestion, and I suggested it only for simplifying the class naming and because it didn't seem *too* ugly. Definitely happy to ignore it. bq. Besides, in this particular case, thrift queries will call toByteBuffer() all the time without needing the duplication so leaving it to the caller does save some Fair enough - seemed we had the opposite problem with new BBs created in Composite*, but since duplicate() will be almost free in almost all cases, it was a bit of a non-issue in the first place. Happy to stick with the current conventions. bq. Definitively not the most clear comment but as far as I can tell it's not incomplete. Well, e.g., it says we can select = 'a AND = 'a' both by using 'a'0. I assume the intention is to use the latter in a range, with an inclusive lower bound and exclusive upper bound. But it isn't clear. Push composites support in the storage engine - Key: CASSANDRA-5417 URL: https://issues.apache.org/jira/browse/CASSANDRA-5417 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: performance Fix For: 2.1 CompositeType happens to be very useful and is now widely used: CQL3 heavily rely on it, and super columns are now using it too internally. Besides, CompositeType has been advised as a replacement of super columns on the thrift side for a while, so it's safe to assume that it's generally used there too. CompositeType has initially been introduced as just another AbstractType. Meaning that the storage engine has no nothing whatsoever of composites being, well, composite. This has the following drawbacks: * Because internally a composite value is handled as just a ByteBuffer, we end up doing a lot of extra work. Typically, each time we compare 2 composite value, we end up deserializing the components (which, while it doesn't copy data per-se because we just slice the global ByteBuffer, still waste some cpu cycles and allocate a bunch of ByteBuffer objects). And since compare can be called *a lot*, this is likely not negligible. * This make CQL3 code uglier than necessary. Basically, CQL3 makes extensive use of composites, and since it gets backs ByteBuffer from the internal columns, it always have to check if it's actually a compositeType or not, and then split it and pick the different parts it needs. It's only an API problem, but having things exposed as composites directly would definitively make thinks cleaner. In particular, in most cases, CQL3 don't care whether it has a composite with only one component or a non-really-composite value, but we still always distinguishes both cases. Lastly, if we do expose composites more directly internally, it's not a lot more work to internalize better the different parts of the cell name that CQL3 uses (what's the clustering key, what's the actuall CQL3 column name, what's the collection element), making things cleaner. Last but not least, there is currently a bunch of places where methods take a ByteBuffer as argument and it's hard to know whether it expects a cell name or a CQL3 column name. This is pretty error prone. * It makes it
[jira] [Commented] (CASSANDRA-5493) Confusing output of CommandDroppedTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831497#comment-13831497
]
Ondřej Černoš commented on CASSANDRA-5493:
--
Yes, the output reports 6 addresses from local datacenter (both private and
public) and 3 addresses from the remote datacenter (public IPs). Tested on
1.2.9.
Confusing output of CommandDroppedTasks
---
Key: CASSANDRA-5493
URL: https://issues.apache.org/jira/browse/CASSANDRA-5493
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Reporter: Ondřej Černoš
Assignee: Mikhail Stepura
Priority: Minor
We have 2 DCs, 3 nodes in each, using EC2 support. We are debugging nodetool
repair problems (roughly 1 out of 2 attempts just freezes). We looked into
the MessagingServiceBean to see what is going on using jmxterm. See the
following:
{noformat}
#mbean = org.apache.cassandra.net:type=MessagingService:
CommandDroppedTasks = {
107.aaa.bbb.ccc = 0;
166.ddd.eee.fff = 124320;
10.ggg.hhh.iii = 0;
107.jjj.kkk.lll = 0;
166.mmm.nnn.ooo = 1336699;
166.ppp.qqq.rrr = 1329171;
10.sss.ttt.uuu = 0;
107.vvv.www.xxx = 0;
};
{noformat}
The problem with this output is it has 8 records. The node's neighbours (the
107 and 10 nodes) are mentioned twice in the output, once with their public
IPs and once with their private IPs. The nodes in remote DC (the 166 ones)
are reported only once. I am pretty sure this is a bug - the node should be
reported only with one of its addresses in all outputs from Cassandra and it
should be consistent.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CASSANDRA-6404) Tools emit ERRORs and WARNINGs about missing javaagent
[
https://issues.apache.org/jira/browse/CASSANDRA-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-6404:
---
Attachment: 0001-Set-javaagent-when-running-tools-in-bin.patch
Tools emit ERRORs and WARNINGs about missing javaagent
---
Key: CASSANDRA-6404
URL: https://issues.apache.org/jira/browse/CASSANDRA-6404
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
Priority: Minor
Fix For: 1.2.12, 2.0.3
Attachments: 0001-Set-javaagent-when-running-tools-in-bin.patch
The combination of CASSANDRA-6107 CASSANDRA-6293 has lead to a number of
the tools shipped in bin/ to display the following warnings when run:
{code}
ERROR 15:21:47,337 Unable to initialize MemoryMeter (jamm not specified as
javaagent). This means Cassandra will be unable to measure object sizes
accurately and may consequently OOM.
WARN 15:21:47,506 MemoryMeter uninitialized (jamm not specified as java
agent); KeyCache size in JVM Heap will not be calculated accurately. Usually
this means cassandra-env.sh disabled jamm because you are u
{code}
Although harmless, these are a bit disconcerting. The simplest fix seems to
be to set the javaagent switch as we do for the main C* launch.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CASSANDRA-6404) Tools emit ERRORs and WARNINGs about missing javaagent
[
https://issues.apache.org/jira/browse/CASSANDRA-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe reassigned CASSANDRA-6404:
--
Assignee: Sam Tunnicliffe
Tools emit ERRORs and WARNINGs about missing javaagent
---
Key: CASSANDRA-6404
URL: https://issues.apache.org/jira/browse/CASSANDRA-6404
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
Priority: Minor
Fix For: 1.2.12, 2.0.3
Attachments: 0001-Set-javaagent-when-running-tools-in-bin.patch
The combination of CASSANDRA-6107 CASSANDRA-6293 has lead to a number of
the tools shipped in bin/ to display the following warnings when run:
{code}
ERROR 15:21:47,337 Unable to initialize MemoryMeter (jamm not specified as
javaagent). This means Cassandra will be unable to measure object sizes
accurately and may consequently OOM.
WARN 15:21:47,506 MemoryMeter uninitialized (jamm not specified as java
agent); KeyCache size in JVM Heap will not be calculated accurately. Usually
this means cassandra-env.sh disabled jamm because you are u
{code}
Although harmless, these are a bit disconcerting. The simplest fix seems to
be to set the javaagent switch as we do for the main C* launch.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CASSANDRA-6404) Tools emit ERRORs and WARNINGs about missing javaagent
Sam Tunnicliffe created CASSANDRA-6404:
--
Summary: Tools emit ERRORs and WARNINGs about missing javaagent
Key: CASSANDRA-6404
URL: https://issues.apache.org/jira/browse/CASSANDRA-6404
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Sam Tunnicliffe
Priority: Minor
Fix For: 2.0.3, 1.2.12
Attachments: 0001-Set-javaagent-when-running-tools-in-bin.patch
The combination of CASSANDRA-6107 CASSANDRA-6293 has lead to a number of the
tools shipped in bin/ to display the following warnings when run:
{code}
ERROR 15:21:47,337 Unable to initialize MemoryMeter (jamm not specified as
javaagent). This means Cassandra will be unable to measure object sizes
accurately and may consequently OOM.
WARN 15:21:47,506 MemoryMeter uninitialized (jamm not specified as java
agent); KeyCache size in JVM Heap will not be calculated accurately. Usually
this means cassandra-env.sh disabled jamm because you are u
{code}
Although harmless, these are a bit disconcerting. The simplest fix seems to be
to set the javaagent switch as we do for the main C* launch.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-1632) Thread workflow and cpu affinity
[ https://issues.apache.org/jira/browse/CASSANDRA-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831609#comment-13831609 ] Chris Burroughs commented on CASSANDRA-1632: Jason, thank you for the long writeup. On affinity and IRQs: A commonly recommended setup for an event driven load balancer (ie haproxy) is to pin network interrupts to one core and run the lb on another core with a shared L2 cache. This works better on CPUs when some cores actually share L2 caches. The closest analogue for Cassandra would be to pin interrupts, run an evented selector thread on another core, and everything else on the rest. It would be interesting of there are best practices around interrupts that could get that 5% performance bump. Pinning, disable/enabling irqbalance are all relativity easy to change at least in a bash-script kind of way. On the other hand, I've never heard a %sintr is too high! complaints on the mailing list. Thread workflow and cpu affinity Key: CASSANDRA-1632 URL: https://issues.apache.org/jira/browse/CASSANDRA-1632 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Chris Goffinet Assignee: Jason Brown Labels: performance Fix For: 2.1 Attachments: 1632-v2.txt, 1632-v3.diff, 1632-v4.diff, 1632_batchRead-v1.diff, patch_v5.diff, patch_v5a.diff, threadAff_reads.txt, threadAff_writes.txt Here are some thoughts I wanted to write down, we need to run some serious benchmarks to see the benefits: 1) All thread pools for our stages use a shared queue per stage. For some stages we could move to a model where each thread has its own queue. This would reduce lock contention on the shared queue. This workload only suits the stages that have no variance, else you run into thread starvation. Some stages that this might work: ROW-MUTATION. 2) Set cpu affinity for each thread in each stage. If we can pin threads to specific cores, and control the workflow of a message from Thrift down to each stage, we should see improvements on reducing L1 cache misses. We would need to build a JNI extension (to set cpu affinity), as I could not find anywhere in JDK where it was exposed. 3) Batching the delivery of requests across stage boundaries. Peter Schuller hasn't looked deep enough yet into the JDK, but he thinks there may be significant improvements to be had there. Especially in high-throughput situations. If on each consumption you were to consume everything in the queue, rather than implying a synchronization point in between each request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6404) Tools emit ERRORs and WARNINGs about missing javaagent
[
https://issues.apache.org/jira/browse/CASSANDRA-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-6404:
Reviewer: Brandon Williams
Tools emit ERRORs and WARNINGs about missing javaagent
---
Key: CASSANDRA-6404
URL: https://issues.apache.org/jira/browse/CASSANDRA-6404
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe
Priority: Minor
Attachments: 0001-Set-javaagent-when-running-tools-in-bin.patch
The combination of CASSANDRA-6107 CASSANDRA-6293 has lead to a number of
the tools shipped in bin/ to display the following warnings when run:
{code}
ERROR 15:21:47,337 Unable to initialize MemoryMeter (jamm not specified as
javaagent). This means Cassandra will be unable to measure object sizes
accurately and may consequently OOM.
WARN 15:21:47,506 MemoryMeter uninitialized (jamm not specified as java
agent); KeyCache size in JVM Heap will not be calculated accurately. Usually
this means cassandra-env.sh disabled jamm because you are u
{code}
Although harmless, these are a bit disconcerting. The simplest fix seems to
be to set the javaagent switch as we do for the main C* launch.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6231) Add snapshot disk space to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831677#comment-13831677 ] Jonathan Ellis commented on CASSANDRA-6231: --- How hard would it be to break out space used by sstables that aren't live anymore? Could be confusing to double-count (or 10x-count or more with lots of snapshots). Add snapshot disk space to cfstats -- Key: CASSANDRA-6231 URL: https://issues.apache.org/jira/browse/CASSANDRA-6231 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Mikhail Stepura Priority: Minor Labels: lhf Attachments: CASSANDRA-2.0-6231.patch As discussed in CASSANDRA-6179, this could help avoid some user confusion, especially when snapshots are autocreated for drop/truncate. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6234) Add metrics for native protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-6234:
---
Attachment: CASSANDRA-2.0-6234.patch
Patch to expose {{RequestThreadPoolExecutor}} through
{{o.a.c.metrics.ThreadPoolMetrics}}.
{{currentBlocked}} will always be 0, because we don't try to re-execute the
rejected task (in contradiction to DebuggableThreadPoolExecutor-based
executors).
Add metrics for native protocols
Key: CASSANDRA-6234
URL: https://issues.apache.org/jira/browse/CASSANDRA-6234
Project: Cassandra
Issue Type: New Feature
Reporter: Adam Hattrell
Assignee: Mikhail Stepura
Attachments: CASSANDRA-2.0-6234.patch,
Oracle_Java_Mission_Control_2013-11-22_15-50-09.png
It would be very useful to expose metrics related to the native protocol.
Initially I have a user that would like to be able to monitor the usage of
native transport threads.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CASSANDRA-6374) AssertionError for rows with zero columns
[
https://issues.apache.org/jira/browse/CASSANDRA-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-6374:
-
Fix Version/s: (was: 2.0.4)
2.0.3
AssertionError for rows with zero columns
-
Key: CASSANDRA-6374
URL: https://issues.apache.org/jira/browse/CASSANDRA-6374
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Anton Gorbunov
Assignee: Jonathan Ellis
Fix For: 2.0.3
Attachments: 6374.txt
After upgrading from 1.2.5 to 1.2.9 and then to 2.0.2 we've got those
exceptions:
{code}
ERROR [FlushWriter:1] 2013-11-18 16:14:36,305 CassandraDaemon.java (line 187)
Exception in thread Thread[FlushWriter:1,5,main]
java.lang.AssertionError
at
org.apache.cassandra.io.sstable.SSTableWriter.rawAppend(SSTableWriter.java:198)
at
org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:186)
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:360)
at
org.apache.cassandra.db.Memtable$FlushRunnable.runWith(Memtable.java:315)
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
Also found similar issue in this thread:
http://www.mail-archive.com/user@cassandra.apache.org/msg32875.html
There Aaron Morton said that its caused by leaving rows with zero columns -
that's exactly what we do in some CFs (using Thrift Astyanax).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6327) select with in clause wrongly returns empty result
[
https://issues.apache.org/jira/browse/CASSANDRA-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831886#comment-13831886
]
Constance Eustace commented on CASSANDRA-6327:
--
Does this fix CASSANDRA-6137?
select with in clause wrongly returns empty result
Key: CASSANDRA-6327
URL: https://issues.apache.org/jira/browse/CASSANDRA-6327
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 2.0.2, x86-64 Ubuntu 13.10
Reporter: Duncan Sands
Assignee: Sylvain Lebresne
Fix For: 2.0.3
Attachments: 0001-check-if-any-of-the-slices-intersects.patch,
6327.txt, current_prices.tar
This query returns no result:
cqlsh:tick_data select syd from current_prices where shard = 1 and syd in
(1, 556129);
(0 rows)
However this query does return a result, showing that the previous query was
wrong to return no result:
cqlsh:tick_data select syd from current_prices where shard = 1 and syd in
(556129);
syd
556129
(1 rows)
This can be reproduced as follows:
(a) Create a keyspace tick_data:
create keyspace tick_data WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
(b) Create a table current_prices:
CREATE TABLE current_prices (
shard int,
syd int,
ask decimal,
bid decimal,
currency ascii,
when timeuuid,
PRIMARY KEY (shard, syd)
);
(c) Stop Cassandra and untar the attached tar file in
/var/lib/cassandra/data/tick_data/. It populates the current_prices table.
(d) Restart Cassandra and perform the above selects.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CASSANDRA-6327) select with in clause wrongly returns empty result
[
https://issues.apache.org/jira/browse/CASSANDRA-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831886#comment-13831886
]
Constance Eustace edited comment on CASSANDRA-6327 at 11/25/13 8:39 PM:
Does this fix CASSANDRA-6137?
Nevermind, you put in a comment saying it probably was...
I have an audit job looking for this, so if we see it come up, we'll let you
know once we move prod to 2.0.3
was (Author: cowardlydragon):
Does this fix CASSANDRA-6137?
select with in clause wrongly returns empty result
Key: CASSANDRA-6327
URL: https://issues.apache.org/jira/browse/CASSANDRA-6327
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 2.0.2, x86-64 Ubuntu 13.10
Reporter: Duncan Sands
Assignee: Sylvain Lebresne
Fix For: 2.0.3
Attachments: 0001-check-if-any-of-the-slices-intersects.patch,
6327.txt, current_prices.tar
This query returns no result:
cqlsh:tick_data select syd from current_prices where shard = 1 and syd in
(1, 556129);
(0 rows)
However this query does return a result, showing that the previous query was
wrong to return no result:
cqlsh:tick_data select syd from current_prices where shard = 1 and syd in
(556129);
syd
556129
(1 rows)
This can be reproduced as follows:
(a) Create a keyspace tick_data:
create keyspace tick_data WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
(b) Create a table current_prices:
CREATE TABLE current_prices (
shard int,
syd int,
ask decimal,
bid decimal,
currency ascii,
when timeuuid,
PRIMARY KEY (shard, syd)
);
(c) Stop Cassandra and untar the attached tar file in
/var/lib/cassandra/data/tick_data/. It populates the current_prices table.
(d) Restart Cassandra and perform the above selects.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CASSANDRA-6327) select with in clause wrongly returns empty result
[
https://issues.apache.org/jira/browse/CASSANDRA-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831886#comment-13831886
]
Constance Eustace edited comment on CASSANDRA-6327 at 11/25/13 8:41 PM:
Does this fix CASSANDRA-6137?
Nevermind, you put in a comment saying it probably was...
I have an audit job looking for this, so if we see it come up, we'll let you
know once we move prod to 2.0.3
Any idea why compaction run right after schema creation seemed to fix this?
was (Author: cowardlydragon):
Does this fix CASSANDRA-6137?
Nevermind, you put in a comment saying it probably was...
I have an audit job looking for this, so if we see it come up, we'll let you
know once we move prod to 2.0.3
select with in clause wrongly returns empty result
Key: CASSANDRA-6327
URL: https://issues.apache.org/jira/browse/CASSANDRA-6327
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 2.0.2, x86-64 Ubuntu 13.10
Reporter: Duncan Sands
Assignee: Sylvain Lebresne
Fix For: 2.0.3
Attachments: 0001-check-if-any-of-the-slices-intersects.patch,
6327.txt, current_prices.tar
This query returns no result:
cqlsh:tick_data select syd from current_prices where shard = 1 and syd in
(1, 556129);
(0 rows)
However this query does return a result, showing that the previous query was
wrong to return no result:
cqlsh:tick_data select syd from current_prices where shard = 1 and syd in
(556129);
syd
556129
(1 rows)
This can be reproduced as follows:
(a) Create a keyspace tick_data:
create keyspace tick_data WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
(b) Create a table current_prices:
CREATE TABLE current_prices (
shard int,
syd int,
ask decimal,
bid decimal,
currency ascii,
when timeuuid,
PRIMARY KEY (shard, syd)
);
(c) Stop Cassandra and untar the attached tar file in
/var/lib/cassandra/data/tick_data/. It populates the current_prices table.
(d) Restart Cassandra and perform the above selects.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6327) select with in clause wrongly returns empty result
[
https://issues.apache.org/jira/browse/CASSANDRA-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831890#comment-13831890
]
Marcus Eriksson commented on CASSANDRA-6327:
there is logic in 2.0 to be able to skip sstables on the read path, a (major)
compaction means there is only one sstable, and it wont be skipped since
atleast one of slices will intersect it
select with in clause wrongly returns empty result
Key: CASSANDRA-6327
URL: https://issues.apache.org/jira/browse/CASSANDRA-6327
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 2.0.2, x86-64 Ubuntu 13.10
Reporter: Duncan Sands
Assignee: Sylvain Lebresne
Fix For: 2.0.3
Attachments: 0001-check-if-any-of-the-slices-intersects.patch,
6327.txt, current_prices.tar
This query returns no result:
cqlsh:tick_data select syd from current_prices where shard = 1 and syd in
(1, 556129);
(0 rows)
However this query does return a result, showing that the previous query was
wrong to return no result:
cqlsh:tick_data select syd from current_prices where shard = 1 and syd in
(556129);
syd
556129
(1 rows)
This can be reproduced as follows:
(a) Create a keyspace tick_data:
create keyspace tick_data WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
(b) Create a table current_prices:
CREATE TABLE current_prices (
shard int,
syd int,
ask decimal,
bid decimal,
currency ascii,
when timeuuid,
PRIMARY KEY (shard, syd)
);
(c) Stop Cassandra and untar the attached tar file in
/var/lib/cassandra/data/tick_data/. It populates the current_prices table.
(d) Restart Cassandra and perform the above selects.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CASSANDRA-6231) Add snapshot disk space to cfstats
[
https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-6231:
---
Attachment: CASSANDRA-2.0-6231-v2.patch
Patch v2. Separately report a space used by obsolete sstables. Assuming
obsolete are those not reported by {{SSTableLister}}
Add snapshot disk space to cfstats
--
Key: CASSANDRA-6231
URL: https://issues.apache.org/jira/browse/CASSANDRA-6231
Project: Cassandra
Issue Type: Bug
Reporter: Jonathan Ellis
Assignee: Mikhail Stepura
Priority: Minor
Labels: lhf
Attachments: CASSANDRA-2.0-6231-v2.patch, CASSANDRA-2.0-6231.patch
As discussed in CASSANDRA-6179, this could help avoid some user confusion,
especially when snapshots are autocreated for drop/truncate.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CASSANDRA-6342) cassandra document errata
[
https://issues.apache.org/jira/browse/CASSANDRA-6342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyuben Todorov updated CASSANDRA-6342:
--
Attachment: 6342.patch
cassandra document errata
-
Key: CASSANDRA-6342
URL: https://issues.apache.org/jira/browse/CASSANDRA-6342
Project: Cassandra
Issue Type: Bug
Reporter: Kim Yong Hwan
Assignee: Lyuben Todorov
Priority: Trivial
Fix For: 1.2.13, 2.0.3
Attachments: 6342.patch
Hi
I think a sample cql statement of cassandra document
(http://cassandra.apache.org/doc/cql3/CQL.html) is wrong. Please change it.
--
Note that TTLs are allowed for both INSERT and UPDATE, but in both case the
TTL set only apply to the newly inserted/updated values. In other words,
// Updating (or inserting)
UPDATE users USING TTL 10 SET favs['color'] = 'green' WHERE id = 'jsmith'
will only apply the TTL to the { 'color' : 'green' } record, the rest of the
map remaining unaffected.
Deleting a map record is done with:
DELETE favs['author'] FROM plays WHERE id = 'jsmith'
upper DELETE cql statement is changed to below. On context of document,
'plays' table might be changed 'users' table.
DELETE favs['author'] FROM users WHERE id = 'jsmith'
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-6231) Add snapshot disk space to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831980#comment-13831980 ] Jonathan Ellis commented on CASSANDRA-6231: --- - Both numbers need to be de-duplicated across snapshots right? - Looks like we could cut down on the file walking if we restricted it to the subdirectory of the CFS in question Add snapshot disk space to cfstats -- Key: CASSANDRA-6231 URL: https://issues.apache.org/jira/browse/CASSANDRA-6231 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Mikhail Stepura Priority: Minor Labels: lhf Attachments: CASSANDRA-2.0-6231-v2.patch, CASSANDRA-2.0-6231.patch As discussed in CASSANDRA-6179, this could help avoid some user confusion, especially when snapshots are autocreated for drop/truncate. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6231) Add snapshot disk space to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832021#comment-13832021 ] Jonathan Ellis commented on CASSANDRA-6231: --- Ah, right. Then isn't the prefix check redundant? Add snapshot disk space to cfstats -- Key: CASSANDRA-6231 URL: https://issues.apache.org/jira/browse/CASSANDRA-6231 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Mikhail Stepura Priority: Minor Labels: lhf Attachments: CASSANDRA-2.0-6231-v2.patch, CASSANDRA-2.0-6231.patch As discussed in CASSANDRA-6179, this could help avoid some user confusion, especially when snapshots are autocreated for drop/truncate. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6231) Add snapshot disk space to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832025#comment-13832025 ] Mikhail Stepura commented on CASSANDRA-6231: bq. Ah, right. Then isn't the prefix check redundant? That is to separate the CF in question and its index CFs, they are reported separately in cfstats. Add snapshot disk space to cfstats -- Key: CASSANDRA-6231 URL: https://issues.apache.org/jira/browse/CASSANDRA-6231 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Mikhail Stepura Priority: Minor Labels: lhf Attachments: CASSANDRA-2.0-6231-v2.patch, CASSANDRA-2.0-6231.patch As discussed in CASSANDRA-6179, this could help avoid some user confusion, especially when snapshots are autocreated for drop/truncate. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6231) Add snapshot disk space to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832038#comment-13832038 ] Mikhail Stepura commented on CASSANDRA-6231: And it seems that we only have to report that obsolete number. Because it makes no sense to count those from snapshots which are just links to existing files. Add snapshot disk space to cfstats -- Key: CASSANDRA-6231 URL: https://issues.apache.org/jira/browse/CASSANDRA-6231 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Mikhail Stepura Priority: Minor Labels: lhf Attachments: CASSANDRA-2.0-6231-v2.patch, CASSANDRA-2.0-6231.patch As discussed in CASSANDRA-6179, this could help avoid some user confusion, especially when snapshots are autocreated for drop/truncate. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6198) Distinguish streaming traffic at network level
[ https://issues.apache.org/jira/browse/CASSANDRA-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832045#comment-13832045 ] sankalp kohli commented on CASSANDRA-6198: -- I am having trouble setting the value on the socket. Since we create the socket from SocketChannel, I am not able to set the TOS. http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SocketChannel.html Here is a sample code I tried running on OSX and Linux in Java 1.7. The IP x.y.z pointed to a test cassandra instance running 2.0.2 Socket socket = SocketChannel.open(new InetSocketAddress(x.y.z, 7000)).socket(); socket.setTrafficClass(8); System.out.println(socket.getTrafficClass());// WIll print 0 SocketChannel channel = SocketChannel.open(new InetSocketAddress(x.y.z, 7000)); channel.setOption(StandardSocketOptions.IP_TOS, 8); System.out.println(channel.getOption(StandardSocketOptions.IP_TOS));// WIll print 0 System.out.println(channel.socket().getTrafficClass());// WIll print 0 channel.socket().setTrafficClass(8); System.out.println(channel.socket().getTrafficClass()); // WIll print 0 //This will work and prints 8 Socket socket1 = new Socket(x.y.z, 7000); socket1.setTrafficClass(8); System.out.println(socket1.getTrafficClass()); // WIll print 8 Distinguish streaming traffic at network level -- Key: CASSANDRA-6198 URL: https://issues.apache.org/jira/browse/CASSANDRA-6198 Project: Cassandra Issue Type: Improvement Components: Core Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor It would be nice to have some information in the TCP packet which network teams can inspect to distinguish between streaming traffic and other organic cassandra traffic. This is very useful for monitoring WAN traffic. Here are some solutions: 1) Use a different port for streaming. 2) Add some IP header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6231) Add snapshot disk space to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832047#comment-13832047 ] Jonathan Ellis commented on CASSANDRA-6231: --- Makes sense to me. Add snapshot disk space to cfstats -- Key: CASSANDRA-6231 URL: https://issues.apache.org/jira/browse/CASSANDRA-6231 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Mikhail Stepura Priority: Minor Labels: lhf Attachments: CASSANDRA-2.0-6231-v2.patch, CASSANDRA-2.0-6231.patch As discussed in CASSANDRA-6179, this could help avoid some user confusion, especially when snapshots are autocreated for drop/truncate. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6198) Distinguish streaming traffic at network level
[
https://issues.apache.org/jira/browse/CASSANDRA-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832051#comment-13832051
]
Jonathan Ellis commented on CASSANDRA-6198:
---
Hmm. At the very least I would expect
{{channel.setOption(StandardSocketOptions.IP_TOS, 8);}} to work. Suggest
filing a bug at https://bugs.openjdk.java.net/secure/Dashboard.jspa and see
what they come back with.
Distinguish streaming traffic at network level
--
Key: CASSANDRA-6198
URL: https://issues.apache.org/jira/browse/CASSANDRA-6198
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: sankalp kohli
Assignee: sankalp kohli
Priority: Minor
It would be nice to have some information in the TCP packet which network
teams can inspect to distinguish between streaming traffic and other organic
cassandra traffic. This is very useful for monitoring WAN traffic.
Here are some solutions:
1) Use a different port for streaming.
2) Add some IP header.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
git commit: Ninja-fix CQL3 doc
Updated Branches:
refs/heads/cassandra-1.2 aec8f1670 - fce173532
Ninja-fix CQL3 doc
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fce17353
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fce17353
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fce17353
Branch: refs/heads/cassandra-1.2
Commit: fce173532438d4ff4269c5db29a0f15906311eb0
Parents: aec8f16
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Nov 26 02:29:30 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Nov 26 02:29:30 2013 +0300
--
doc/cql3/CQL.textile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fce17353/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index c4e39d1..507ad13 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -844,7 +844,7 @@ will only apply the TTL to the @{ 'color' : 'green' }@
record, the rest of the m
Deleting a map record is done with:
bc(sample).
-DELETE favs['author'] FROM plays WHERE id = 'jsmith'
+DELETE favs['author'] FROM users WHERE id = 'jsmith'
h4(#set). Sets
[3/3] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4a1b4322 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4a1b4322 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4a1b4322 Branch: refs/heads/trunk Commit: 4a1b4322d8bfc4f7a8d2668a4326bac86c49a01d Parents: f69e043 6c68b30 Author: Aleksey Yeschenko alek...@apache.org Authored: Tue Nov 26 02:30:18 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Tue Nov 26 02:30:18 2013 +0300 -- doc/cql3/CQL.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --
[1/2] git commit: Ninja-fix CQL3 doc
Updated Branches:
refs/heads/cassandra-2.0 5eaa2164e - 6c68b30fe
Ninja-fix CQL3 doc
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fce17353
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fce17353
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fce17353
Branch: refs/heads/cassandra-2.0
Commit: fce173532438d4ff4269c5db29a0f15906311eb0
Parents: aec8f16
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Nov 26 02:29:30 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Nov 26 02:29:30 2013 +0300
--
doc/cql3/CQL.textile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fce17353/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index c4e39d1..507ad13 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -844,7 +844,7 @@ will only apply the TTL to the @{ 'color' : 'green' }@
record, the rest of the m
Deleting a map record is done with:
bc(sample).
-DELETE favs['author'] FROM plays WHERE id = 'jsmith'
+DELETE favs['author'] FROM users WHERE id = 'jsmith'
h4(#set). Sets
[1/3] git commit: Ninja-fix CQL3 doc
Updated Branches:
refs/heads/trunk f69e043ce - 4a1b4322d
Ninja-fix CQL3 doc
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fce17353
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fce17353
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fce17353
Branch: refs/heads/trunk
Commit: fce173532438d4ff4269c5db29a0f15906311eb0
Parents: aec8f16
Author: Aleksey Yeschenko alek...@apache.org
Authored: Tue Nov 26 02:29:30 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Tue Nov 26 02:29:30 2013 +0300
--
doc/cql3/CQL.textile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fce17353/doc/cql3/CQL.textile
--
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index c4e39d1..507ad13 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -844,7 +844,7 @@ will only apply the TTL to the @{ 'color' : 'green' }@
record, the rest of the m
Deleting a map record is done with:
bc(sample).
-DELETE favs['author'] FROM plays WHERE id = 'jsmith'
+DELETE favs['author'] FROM users WHERE id = 'jsmith'
h4(#set). Sets
[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6c68b30f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6c68b30f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6c68b30f Branch: refs/heads/trunk Commit: 6c68b30fef95f8f4a621969f5d0434bc2326c2e2 Parents: 5eaa216 fce1735 Author: Aleksey Yeschenko alek...@apache.org Authored: Tue Nov 26 02:30:00 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Tue Nov 26 02:30:00 2013 +0300 -- doc/cql3/CQL.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c68b30f/doc/cql3/CQL.textile --
[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6c68b30f Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6c68b30f Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6c68b30f Branch: refs/heads/cassandra-2.0 Commit: 6c68b30fef95f8f4a621969f5d0434bc2326c2e2 Parents: 5eaa216 fce1735 Author: Aleksey Yeschenko alek...@apache.org Authored: Tue Nov 26 02:30:00 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Tue Nov 26 02:30:00 2013 +0300 -- doc/cql3/CQL.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/6c68b30f/doc/cql3/CQL.textile --
[jira] [Commented] (CASSANDRA-2915) Lucene based Secondary Indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832066#comment-13832066 ] Camille Vergara commented on CASSANDRA-2915: If you're interested in seeing this feature implemented, you should consider supporting the fundraiser for bounties on Bountysource: https://www.bountysource.com/fundraisers/508. Lucene based Secondary Indexes -- Key: CASSANDRA-2915 URL: https://issues.apache.org/jira/browse/CASSANDRA-2915 Project: Cassandra Issue Type: New Feature Components: Core Reporter: T Jake Luciani Labels: secondary_index Secondary indexes (of type KEYS) suffer from a number of limitations in their current form: - Multiple IndexClauses only work when there is a subset of rows under the highest clause - One new column family is created per index this means 10 new CFs for 10 secondary indexes This ticket will use the Lucene library to implement secondary indexes as one index per CF, and utilize the Lucene query engine to handle multiple index clauses. Also, by using the Lucene we get a highly optimized file format. There are a few parallels we can draw between Cassandra and Lucene. Lucene indexes segments in memory then flushes them to disk so we can sync our memtable flushes to lucene flushes. Lucene also has optimize() which correlates to our compaction process, so these can be sync'd as well. We will also need to correlate column validators to Lucene tokenizers, so the data can be stored properly, the big win in once this is done we can perform complex queries within a column like wildcard searches. The downside of this approach is we will need to read before write since documents in Lucene are written as complete documents. For random workloads with lot's of indexed columns this means we need to read the document from the index, update it and write it back. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CASSANDRA-6231) Add snapshot disk space to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-6231: --- Attachment: CASSANDRA-2.0-6231-v3.patch Patch v3. Count only the size of snapshot files (once for each file) which are not links for live SSTables. Add snapshot disk space to cfstats -- Key: CASSANDRA-6231 URL: https://issues.apache.org/jira/browse/CASSANDRA-6231 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Mikhail Stepura Priority: Minor Labels: lhf Attachments: CASSANDRA-2.0-6231-v2.patch, CASSANDRA-2.0-6231-v3.patch, CASSANDRA-2.0-6231.patch As discussed in CASSANDRA-6179, this could help avoid some user confusion, especially when snapshots are autocreated for drop/truncate. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6326) Snapshot should create manifest file
[ https://issues.apache.org/jira/browse/CASSANDRA-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832116#comment-13832116 ] sankalp kohli commented on CASSANDRA-6326: -- In JBOD with multiple data directories, where should we put this manifest file? Also I think we need to create the manifest file in the end as existence of manifest file will prove that snapshot is good. Snapshot should create manifest file - Key: CASSANDRA-6326 URL: https://issues.apache.org/jira/browse/CASSANDRA-6326 Project: Cassandra Issue Type: Improvement Components: Core Reporter: sankalp kohli Priority: Minor We should create a manifest file as part of the snapshot which should contain all the stables included in the snapshot. This will be very important for systems consuming this snapshot as they can validate the fact that they got the complete snapshot. If Cassandra crashes mid way creating a snapshot, I think it will create an incomplete snapshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6198) Distinguish streaming traffic at network level
[ https://issues.apache.org/jira/browse/CASSANDRA-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832117#comment-13832117 ] sankalp kohli commented on CASSANDRA-6198: -- As per javadoc in http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SocketChannel.html IP_TOS is not listed. So I am not sure whether it is a bug. Distinguish streaming traffic at network level -- Key: CASSANDRA-6198 URL: https://issues.apache.org/jira/browse/CASSANDRA-6198 Project: Cassandra Issue Type: Improvement Components: Core Reporter: sankalp kohli Assignee: sankalp kohli Priority: Minor It would be nice to have some information in the TCP packet which network teams can inspect to distinguish between streaming traffic and other organic cassandra traffic. This is very useful for monitoring WAN traffic. Here are some solutions: 1) Use a different port for streaming. 2) Add some IP header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-2915) Lucene based Secondary Indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832125#comment-13832125 ] Alex Liu commented on CASSANDRA-2915: - We may need use Twitter's RealTime search. Lucene based Secondary Indexes -- Key: CASSANDRA-2915 URL: https://issues.apache.org/jira/browse/CASSANDRA-2915 Project: Cassandra Issue Type: New Feature Components: Core Reporter: T Jake Luciani Labels: secondary_index Secondary indexes (of type KEYS) suffer from a number of limitations in their current form: - Multiple IndexClauses only work when there is a subset of rows under the highest clause - One new column family is created per index this means 10 new CFs for 10 secondary indexes This ticket will use the Lucene library to implement secondary indexes as one index per CF, and utilize the Lucene query engine to handle multiple index clauses. Also, by using the Lucene we get a highly optimized file format. There are a few parallels we can draw between Cassandra and Lucene. Lucene indexes segments in memory then flushes them to disk so we can sync our memtable flushes to lucene flushes. Lucene also has optimize() which correlates to our compaction process, so these can be sync'd as well. We will also need to correlate column validators to Lucene tokenizers, so the data can be stored properly, the big win in once this is done we can perform complex queries within a column like wildcard searches. The downside of this approach is we will need to read before write since documents in Lucene are written as complete documents. For random workloads with lot's of indexed columns this means we need to read the document from the index, update it and write it back. -- This message was sent by Atlassian JIRA (v6.1#6144)
git commit: simple naming fixes
Updated Branches:
refs/heads/trunk 4a1b4322d - 9f3a7f8a6
simple naming fixes
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9f3a7f8a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9f3a7f8a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9f3a7f8a
Branch: refs/heads/trunk
Commit: 9f3a7f8a6989be44bed01aaf526567df8aca
Parents: 4a1b432
Author: Dave Brosius dbros...@mebigfatguy.com
Authored: Mon Nov 25 20:06:42 2013 -0500
Committer: Dave Brosius dbros...@mebigfatguy.com
Committed: Mon Nov 25 20:06:42 2013 -0500
--
.../unit/org/apache/cassandra/service/QueryPagerTest.java | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9f3a7f8a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --git a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
index f395cf4..6239ba0 100644
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
@@ -155,7 +155,7 @@ public class QueryPagerTest extends SchemaLoader
}
@Test
-public void NamesQueryTest() throws Exception
+public void namesQueryTest() throws Exception
{
QueryPager pager = QueryPagers.localPager(namesQuery(k0, c1, c5,
c7, c8));
@@ -168,7 +168,7 @@ public class QueryPagerTest extends SchemaLoader
}
@Test
-public void SliceQueryTest() throws Exception
+public void sliceQueryTest() throws Exception
{
QueryPager pager = QueryPagers.localPager(sliceQuery(k0, c1, c8,
10));
@@ -218,7 +218,7 @@ public class QueryPagerTest extends SchemaLoader
}
@Test
-public void MultiQueryTest() throws Exception
+public void multiQueryTest() throws Exception
{
QueryPager pager = QueryPagers.localPager(new
Pageable.ReadCommands(new ArrayListReadCommand() {{
add(sliceQuery(k1, c2, c6, 10));
@@ -247,7 +247,7 @@ public class QueryPagerTest extends SchemaLoader
}
@Test
-public void RangeNamesQueryTest() throws Exception
+public void rangeNamesQueryTest() throws Exception
{
QueryPager pager = QueryPagers.localPager(rangeNamesQuery(range(k0,
k5), 100, c1, c4, c8));
@@ -269,7 +269,7 @@ public class QueryPagerTest extends SchemaLoader
}
@Test
-public void RangeSliceQueryTest() throws Exception
+public void rangeSliceQueryTest() throws Exception
{
QueryPager pager = QueryPagers.localPager(rangeSliceQuery(range(k1,
k5), 100, c1, c7));
[jira] [Commented] (CASSANDRA-5493) Confusing output of CommandDroppedTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832294#comment-13832294
]
Mikhail Stepura commented on CASSANDRA-5493:
[~ondrej.cernos] what are values for _listen_address_ and _broadcast_address_
for your nodes?
Confusing output of CommandDroppedTasks
---
Key: CASSANDRA-5493
URL: https://issues.apache.org/jira/browse/CASSANDRA-5493
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Reporter: Ondřej Černoš
Assignee: Mikhail Stepura
Priority: Minor
We have 2 DCs, 3 nodes in each, using EC2 support. We are debugging nodetool
repair problems (roughly 1 out of 2 attempts just freezes). We looked into
the MessagingServiceBean to see what is going on using jmxterm. See the
following:
{noformat}
#mbean = org.apache.cassandra.net:type=MessagingService:
CommandDroppedTasks = {
107.aaa.bbb.ccc = 0;
166.ddd.eee.fff = 124320;
10.ggg.hhh.iii = 0;
107.jjj.kkk.lll = 0;
166.mmm.nnn.ooo = 1336699;
166.ppp.qqq.rrr = 1329171;
10.sss.ttt.uuu = 0;
107.vvv.www.xxx = 0;
};
{noformat}
The problem with this output is it has 8 records. The node's neighbours (the
107 and 10 nodes) are mentioned twice in the output, once with their public
IPs and once with their private IPs. The nodes in remote DC (the 166 ones)
are reported only once. I am pretty sure this is a bug - the node should be
reported only with one of its addresses in all outputs from Cassandra and it
should be consistent.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CASSANDRA-5493) Confusing output of CommandDroppedTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832294#comment-13832294
]
Mikhail Stepura edited comment on CASSANDRA-5493 at 11/26/13 4:28 AM:
--
[~ondrej.cernos] what are values for _listen_address_ and _broadcast_address_
for your nodes? And which EC2 snitch do you use?
was (Author: mishail):
[~ondrej.cernos] what are values for _listen_address_ and _broadcast_address_
for your nodes?
Confusing output of CommandDroppedTasks
---
Key: CASSANDRA-5493
URL: https://issues.apache.org/jira/browse/CASSANDRA-5493
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Reporter: Ondřej Černoš
Assignee: Mikhail Stepura
Priority: Minor
We have 2 DCs, 3 nodes in each, using EC2 support. We are debugging nodetool
repair problems (roughly 1 out of 2 attempts just freezes). We looked into
the MessagingServiceBean to see what is going on using jmxterm. See the
following:
{noformat}
#mbean = org.apache.cassandra.net:type=MessagingService:
CommandDroppedTasks = {
107.aaa.bbb.ccc = 0;
166.ddd.eee.fff = 124320;
10.ggg.hhh.iii = 0;
107.jjj.kkk.lll = 0;
166.mmm.nnn.ooo = 1336699;
166.ppp.qqq.rrr = 1329171;
10.sss.ttt.uuu = 0;
107.vvv.www.xxx = 0;
};
{noformat}
The problem with this output is it has 8 records. The node's neighbours (the
107 and 10 nodes) are mentioned twice in the output, once with their public
IPs and once with their private IPs. The nodes in remote DC (the 166 ones)
are reported only once. I am pretty sure this is a bug - the node should be
reported only with one of its addresses in all outputs from Cassandra and it
should be consistent.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Reopened] (CASSANDRA-6401) Clustering order by property does not support when the column name is written in uppercase
[ https://issues.apache.org/jira/browse/CASSANDRA-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DIKSHA KUSHWAH reopened CASSANDRA-6401: --- Since Version: 2.0.1 Tester: DIKSHA KUSHWAH Clustering order by property does not support when the column name is written in uppercase --- Key: CASSANDRA-6401 URL: https://issues.apache.org/jira/browse/CASSANDRA-6401 Project: Cassandra Issue Type: Bug Components: Core Environment: Windows 7 64 bit Reporter: DIKSHA KUSHWAH Database Version : CASSANDRA 2.0.1 1. Connect cassandra 2.0.1 and execute following query:- CREATE TABLE test.cat ( cache text, num int, PRIMARY KEY(cache,num) ) WITH CLUSTERING ORDER BY (num DESC); 2. Now execute following query:- CREATE TABLE DOG ( CACHE text, NUM int, PRIMARY KEY(CACHE,NUM) ) WITH CLUSTERING ORDER BY (NUM DESC); 3. When we create table cat,it is successfully created but when we create table DOG it gives error Missing CLUSTERING ORDER for column NUM because Table DOG column name NUM is in upper case and Table CAT column name num is in lower case. 4. Cassandra supports when we create a Table with column names in upper case without CLUSTERING ORDER BY property then it should also support this property with upper case column names. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CASSANDRA-6231) Add snapshot disk space to cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832333#comment-13832333 ] Jonathan Ellis commented on CASSANDRA-6231: --- LGTM! Last thing, the size methods in CFSMBean are deprecated because we're moving to CFMetrics. Not much reason to add this to both places; let's just do it in metrics. (So it's probably easier to just do this for trunk since otherwise you'd have to do support both in nodecmd.) Add snapshot disk space to cfstats -- Key: CASSANDRA-6231 URL: https://issues.apache.org/jira/browse/CASSANDRA-6231 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Mikhail Stepura Priority: Minor Labels: lhf Attachments: CASSANDRA-2.0-6231-v2.patch, CASSANDRA-2.0-6231-v3.patch, CASSANDRA-2.0-6231.patch As discussed in CASSANDRA-6179, this could help avoid some user confusion, especially when snapshots are autocreated for drop/truncate. -- This message was sent by Atlassian JIRA (v6.1#6144)
