[jira] [Commented] (CASSANDRA-4417) invalid counter shard detected
[ https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453798#comment-13453798 ] Peter Schuller commented on CASSANDRA-4417: --- @Sylvain I know it wouldn't be correlated with the *same* node; I was referring to uncontrolled shutdowns in general in the cluster. @Omid: Presumably the premise was that the mutation goes through the commit log on the leader prior to replication. I'm not sure if this is the case, but if it is, then it should work. @jbellis FWIW, our counter use-cases are such that going commit log synch is probably not feasable due to very high write throughput. Doesn't mean other people's use-cases are the same, and of course I *fully* support the idea of being correct by default (as opposed to performant by default). @Sylvain again: I agree about refreshing nodeid on every unclean restart being potentially dangerous. Counters are already huge due to the size of counter shards, and refreshing nodeids in any situation which might result in en-masse refreshment can definitely be dangerous both from a CPU usage perspective as well as a disk space one. invalid counter shard detected --- Key: CASSANDRA-4417 URL: https://issues.apache.org/jira/browse/CASSANDRA-4417 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1 Environment: Amazon Linux Reporter: Senthilvel Rangaswamy Seeing errors like these: 2012-07-06_07:00:27.22662 ERROR 07:00:27,226 invalid counter shard detected; (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 13) and (17bfd850-ac52-11e1--6ecd0b5b61e7, 1, 1) differ only in count; will pick highest to self-heal; this indicates a bug or corruption generated a bad counter shard What does it mean ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4565) TTL columns with older then gcgrace do not need to flush
[ https://issues.apache.org/jira/browse/CASSANDRA-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453801#comment-13453801 ] Aleksey Yeschenko commented on CASSANDRA-4565: -- Do you think expired ttl columns should be replaced with tombstones at memtable flush? (I'm leaning towards no). If you agree then I'm closing this task. TTL columns with older then gcgrace do not need to flush Key: CASSANDRA-4565 URL: https://issues.apache.org/jira/browse/CASSANDRA-4565 Project: Cassandra Issue Type: Improvement Reporter: Edward Capriolo Assignee: Aleksey Yeschenko Fix For: 1.3 Attachments: cassandra-4565.patch.1.txt With memcache many people are willing to sacrifice durability for performance. Cassandra has a TimeToLive feature that can be used in caching scenarios with low values for gc_grace_seconds. However from a code dive it seems that cassandra will always write TTL to disk, even those that are beyond gc_grace_seconds. If a use case very large memtables,small ttl, and small gc_grace it is possible that flushing these columns to disk can be skipped entirely in some scenarios. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4643) AssertionError: DecoratedKey(-1, ) != DecoratedKey
[ https://issues.apache.org/jira/browse/CASSANDRA-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453823#comment-13453823 ] Radim Kolar commented on CASSANDRA-4643: it is migrated installation from 1.0 AssertionError: DecoratedKey(-1, ) != DecoratedKey -- Key: CASSANDRA-4643 URL: https://issues.apache.org/jira/browse/CASSANDRA-4643 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.5 Reporter: Radim Kolar i got lot of following errors: decorated key -1 != some number INFO [CompactionExecutor:10] 2012-09-11 02:22:13,586 CompactionController.java (line 172) Compacting large row system/HintsColumnFamily:67fd0f04ca3294558142a5b33a30f6f5 (241502947 bytes) incrementally ERROR [ReadStage:44] 2012-09-11 02:22:13,992 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[ReadStage:44,5,main] java.lang.AssertionError: DecoratedKey(-1, ) != DecoratedKey(133375303318769338050543368330356089660, ad4f) in c:\cassandra\data\test\sipdb\test-sipdb-he-5-Data.db at org.apache.cassandra.db.columniterator.SSTableNamesIterator.init(SSTableNamesIterator.java:72) at org.apache.cassandra.db.filter.NamesQueryFilter.getSSTableColumnIterator(NamesQueryFilter.java:61) at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79) at org.apache.cassandra.db.CollationController.collectTimeOrderedData(CollationController.java:124) at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4654) Using CQL 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-4654. - Resolution: Invalid Please use the user mailing list (u...@cassandra.apache.org, you can also subscribe directly from http://cassandra.apache.org/) for that type of help inquiry. Jira is for tracking development tasks. Using CQL 3.0 - Key: CASSANDRA-4654 URL: https://issues.apache.org/jira/browse/CASSANDRA-4654 Project: Cassandra Issue Type: Bug Environment: Linux Ubuntu Reporter: Nguyen Manh Hung How to use CQL 3.0 with php? help me, pls -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4653) nodetool cfstats Lantecy unit is wrong , it should be sec (seconds) instead of ms (micro seconds)
[ https://issues.apache.org/jira/browse/CASSANDRA-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453832#comment-13453832 ] Sylvain Lebresne commented on CASSANDRA-4653: - Oh and maybe that's the confusion but ms stands for milliseconds, not microseconds (not sure for Cassandra, this is standard. The symbol for microseconds is µs). nodetool cfstats Lantecy unit is wrong , it should be sec (seconds) instead of ms (micro seconds) - Key: CASSANDRA-4653 URL: https://issues.apache.org/jira/browse/CASSANDRA-4653 Project: Cassandra Issue Type: Bug Components: Tools Reporter: laneser kuo Priority: Trivial Attachments: mstosec.txt I was mislead by the nodetool cfstats Read Latency and Write Latency data. Until I read the source code, it should display sec instead of ms. for example: outs.println(\t\tRead Latency: + String.format(%01.3f, cfstore.getRecentReadLatencyMicros() / 1000) + ms.); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4653) nodetool cfstats Lantecy unit is wrong , it should be sec (seconds) instead of ms (micro seconds)
[ https://issues.apache.org/jira/browse/CASSANDRA-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453832#comment-13453832 ] Sylvain Lebresne edited comment on CASSANDRA-4653 at 9/12/12 7:37 PM: -- Oh and maybe that's the confusion but ms stands for milliseconds, not microseconds (not just for Cassandra, this is standard. The symbol for microseconds is µs). was (Author: slebresne): Oh and maybe that's the confusion but ms stands for milliseconds, not microseconds (not sure for Cassandra, this is standard. The symbol for microseconds is µs). nodetool cfstats Lantecy unit is wrong , it should be sec (seconds) instead of ms (micro seconds) - Key: CASSANDRA-4653 URL: https://issues.apache.org/jira/browse/CASSANDRA-4653 Project: Cassandra Issue Type: Bug Components: Tools Reporter: laneser kuo Priority: Trivial Attachments: mstosec.txt I was mislead by the nodetool cfstats Read Latency and Write Latency data. Until I read the source code, it should display sec instead of ms. for example: outs.println(\t\tRead Latency: + String.format(%01.3f, cfstore.getRecentReadLatencyMicros() / 1000) + ms.); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4565) TTL columns with older then gcgrace do not need to flush
[ https://issues.apache.org/jira/browse/CASSANDRA-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453838#comment-13453838 ] Sylvain Lebresne commented on CASSANDRA-4565: - bq. Do you think expired ttl columns should be replaced with tombstones at memtable flush? No, I'm even pretty sure it would be a bad idea. Currently the code does two iterations over a row to flush it: first it computes the row serialized size (to write that at the beginning of the row), then it actually writes it. We should *not* transform expired columns to tombstone during the 2nd iteration because it would screw up the serialized size computation. And the first iteration is just ill suited too because doing that transformation in the serializedSize() method would be a big hack. So we would need to do an iteration just for that purpose, and given that having expired column during flush is a corner case, it would cost more than it would give us. If we remove the row serialized size (and column count) in the sstable format (which we may at some point), then we can revisit as it will be trivial then. TTL columns with older then gcgrace do not need to flush Key: CASSANDRA-4565 URL: https://issues.apache.org/jira/browse/CASSANDRA-4565 Project: Cassandra Issue Type: Improvement Reporter: Edward Capriolo Assignee: Aleksey Yeschenko Fix For: 1.3 Attachments: cassandra-4565.patch.1.txt With memcache many people are willing to sacrifice durability for performance. Cassandra has a TimeToLive feature that can be used in caching scenarios with low values for gc_grace_seconds. However from a code dive it seems that cassandra will always write TTL to disk, even those that are beyond gc_grace_seconds. If a use case very large memtables,small ttl, and small gc_grace it is possible that flushing these columns to disk can be skipped entirely in some scenarios. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4565) TTL columns with older then gcgrace do not need to flush
[ https://issues.apache.org/jira/browse/CASSANDRA-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453842#comment-13453842 ] Aleksey Yeschenko commented on CASSANDRA-4565: -- bq. So we would need to do an iteration just for that purpose, and given that having expired column during flush is a corner case, it would cost more than it would give us. That's what I thought as well. Closing the issue then. TTL columns with older then gcgrace do not need to flush Key: CASSANDRA-4565 URL: https://issues.apache.org/jira/browse/CASSANDRA-4565 Project: Cassandra Issue Type: Improvement Reporter: Edward Capriolo Assignee: Aleksey Yeschenko Fix For: 1.3 Attachments: cassandra-4565.patch.1.txt With memcache many people are willing to sacrifice durability for performance. Cassandra has a TimeToLive feature that can be used in caching scenarios with low values for gc_grace_seconds. However from a code dive it seems that cassandra will always write TTL to disk, even those that are beyond gc_grace_seconds. If a use case very large memtables,small ttl, and small gc_grace it is possible that flushing these columns to disk can be skipped entirely in some scenarios. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4565) TTL columns with older then gcgrace do not need to flush
[ https://issues.apache.org/jira/browse/CASSANDRA-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-4565. -- Resolution: Not A Problem TTL columns with older then gcgrace do not need to flush Key: CASSANDRA-4565 URL: https://issues.apache.org/jira/browse/CASSANDRA-4565 Project: Cassandra Issue Type: Improvement Reporter: Edward Capriolo Assignee: Aleksey Yeschenko Fix For: 1.3 Attachments: cassandra-4565.patch.1.txt With memcache many people are willing to sacrifice durability for performance. Cassandra has a TimeToLive feature that can be used in caching scenarios with low values for gc_grace_seconds. However from a code dive it seems that cassandra will always write TTL to disk, even those that are beyond gc_grace_seconds. If a use case very large memtables,small ttl, and small gc_grace it is possible that flushing these columns to disk can be skipped entirely in some scenarios. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4648) Unable to start Cassandra with simple authentication enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4648: Attachment: 4648.txt Attaching patch that is so that processInternal skips StorageProxy and authorization (so it also solve CASSANDRA-4617 in particular). I'm keen on keeping QP here because we use a mix of cf with and without compact storage internally, and not using QP would get annoying and error prone, while QP already deal with that. Also, collections are another thing that might be painful without QP (I don't think we have any in the system tables yet but I'm betting we'll have some soon enough). Unable to start Cassandra with simple authentication enabled Key: CASSANDRA-4648 URL: https://issues.apache.org/jira/browse/CASSANDRA-4648 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.0 beta 1 Environment: Mac OS X Reporter: John Sanda Assignee: Sylvain Lebresne Labels: security Fix For: 1.2.0 Attachments: 4648.txt I followed the steps for enabling simple authentication as described here, http://www.datastax.com/docs/1.1/configuration/authentication. I tried starting Cassandra with, cassandra -f -Dpasswd.properties=conf/passwd.properties -Daccess.properties=conf/access.properties Start up failed with this exception in my log: ERROR [main] 2012-09-11 15:03:04,642 CassandraDaemon.java (line 403) Exception encountered during startup java.lang.AssertionError: org.apache.cassandra.exceptions.InvalidRequestException: You have not logged in at org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:136) at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:298) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:203) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:386) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:429) Caused by: org.apache.cassandra.exceptions.InvalidRequestException: You have not logged in at org.apache.cassandra.service.ClientState.validateLogin(ClientState.java:254) at org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:235) at org.apache.cassandra.cql3.statements.SelectStatement.checkAccess(SelectStatement.java:105) at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:106) at org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:124) ... 4 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4649) Cassandra 1.2 should not accept CQL version 3.0.0-beta1
[ https://issues.apache.org/jira/browse/CASSANDRA-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4649: Attachment: 4649.txt Patch attached that * changes the version to 3.0.0 (we don't have anything in store that would need to break syntax further and we're about to roll 1.2.0 beta1 soon (hopefully) so I think it's indeed time to drop the beta). * Makes 1.2 refuse 3.0.0-beta1 version (with an hopefully useful error message). I note however that 1.1 was happily accepting 3.0.0 as a version, and I don't think we have advertised much that people should use 3.0.0-beta1 in 1.1, so most people will be surprised that their CREATE KEYSPACE query is invalid all of a sudden anyway (including user of cqlsh). We do have a NEWS entry to explain that however so not sure there is more we can/need to do. Cassandra 1.2 should not accept CQL version 3.0.0-beta1 - Key: CASSANDRA-4649 URL: https://issues.apache.org/jira/browse/CASSANDRA-4649 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 Reporter: paul cannon Priority: Minor Labels: cql3 Attachments: 4649.txt During Cassandra 1.1's whole lifecycle, the CREATE KEYSPACE syntax was pretty dramatically and incompatibly different from what is there now for 1.2. That's ok, since we explicitly said there could be breaking changes in the syntax before 3.0.0 final, but at least we should make it clear that 3.0.0 is not compatible with the 3.0.0-beta1 syntax we had out for quite a while. If we don't want to reject connections asking for 3.0.0-beta1, we should bump the version number to 3.0.1 or something. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4655) Truncate operation doesn't delete rows from HintsColumnFamily.
Alexey Zotov created CASSANDRA-4655: --- Summary: Truncate operation doesn't delete rows from HintsColumnFamily. Key: CASSANDRA-4655 URL: https://issues.apache.org/jira/browse/CASSANDRA-4655 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.4 Environment: Centos 6.2, Cassandra 1.1.4 (DataStax distribution), three-nodes cluster. Reporter: Alexey Zotov Priority: Minor Step to reproduce: 1. Start writing of data to some column family, let name it 'MyCF' 2. Stop 1 node 3. Wait some time (until some data will be collected in HintsColumnFamily) 4. Start node (HintedHandoff will be started automatically for 'MyCF') 5. Run 'truncate' command for 'MyCF' column family from command from cli 6. Wait until truncate will be finished 7. You will see that 'MyCF' is not empty because HintedHandoff is copying data So, I suggest to clean HintsColumnFamily (for truncated column family) before we had started to discard sstables. I think it should be done in CompactionManager#submitTrucate() method. I can try to create patch but I need to know right way of cleaning HintsColumnFamily. Could you clarify it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4656) StorageProxy histograms
Alexey Zotov created CASSANDRA-4656:
---
Summary: StorageProxy histograms
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in 'SSTables'
column. Output is not usable for parse because of that. I suggest to insert '0'
instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
15970 0 505 0
0
19160 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Description:
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in 'SSTables'
column. Output is not usable for parse because of that. I suggest to insert '0'
instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
15970 0 505 0
0
19160 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
was:
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in 'SSTables'
column. Output is not usable for parse because of that. I suggest to insert '0'
instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
15970 0 505 0
0
19160 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Description:
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in 'SSTables'
column. Output is not usable for parse because of that. I suggest to insert '0'
instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
was:
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in 'SSTables'
column. Output is not usable for parse because of that. I suggest to insert '0'
instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
15970 0 505 0
0
19160 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: StorageProxy_histograms.patch
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov updated CASSANDRA-4656:
Attachment: StorageProxy_histograms.patch
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: StorageProxy_histograms.patch
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4617) OPTIMIZE_LOCAL_REQUESTS=false no longer works
[ https://issues.apache.org/jira/browse/CASSANDRA-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4617. --- Resolution: Duplicate Fix Version/s: (was: 1.2.0) Assignee: (was: Sylvain Lebresne) Will address both in that ticket. OPTIMIZE_LOCAL_REQUESTS=false no longer works - Key: CASSANDRA-4617 URL: https://issues.apache.org/jira/browse/CASSANDRA-4617 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Jonathan Ellis Priority: Trivial SystemTable.checkHealth is called before starting to listen for intra-cluster RPC requests, so since QueryProcessor compiles down to StorageProxy calls, it will time out and fail the server startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4656:
--
Reviewer: yukim
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: StorageProxy_histograms.patch
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4609: --- Reviewer: xedin Fix Version/s: 1.1.6 Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4657) cql version race condition with rpc_server_type: sync
Emmanuel Courreges created CASSANDRA-4657: - Summary: cql version race condition with rpc_server_type: sync Key: CASSANDRA-4657 URL: https://issues.apache.org/jira/browse/CASSANDRA-4657 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.5, 1.1.2, 1.1.1 Environment: Ubuntu 12.04 Reporter: Emmanuel Courreges If clients connect to a cassandra cluster configured with rpc_server_type: sync with heterogeneous cql versions (2 and 3), the cql version used for execution on the server changes seemingly randomly. It's due to the fact that CustomTThreadPoolServer.java does not set the remoteSocket anytime, or does not clear the cql version in the ThreadLocal clientState object. When CassandraServer.java calls state() it gets the ThreadLocal object clientState, which has its cqlversion already changed by a previous socket that was using the same thread. The easiest fix is probably to do a SocketSessionManagementService.instance.put when accepting a new client and SocketSessionManagementService.instance.remove when the client is closed, but if you really want to use the ThreadLocal clientState and not alloc/destroy a ClientState everytime, then you should clear this clientState on accept of a new client. The problem can be reproduced with cqlsh -3 on one side and a client that does not set the cql version, expecting to get version 2 by default, but actually gettingv v2/v3 depending on which thread it connects to. The problem does not happen with other rpc_server_types, nor with clients that set their cql version at connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of DataModel by MattSheppard
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The DataModel page has been changed by MattSheppard: http://wiki.apache.org/cassandra/DataModel?action=diffrev1=14rev2=15 Comment: grammer Timestamps can be anything you like, but microseconds since 1970 is a convention. Whatever you use, it must be consistent across the application, otherwise earlier changes may overwrite newer ones. = Column Families = - A column family is a container for rows, analogous to the table in a relational system. Each row in a column family can referenced by its key. + A column family is a container for rows, analogous to the table in a relational system. Each row in a column family can be referenced by its key. Column families have a configurable ordering applied to the columns within each row, which affects the behavior of the get_slice call in the thrift API. Out of the box ordering implementations include ASCII, UTF-8, Long, UUID (lexical or time), Date, combinations of these using CompositeType, and others.
[jira] [Updated] (CASSANDRA-4657) cql version race condition with rpc_server_type: sync
[ https://issues.apache.org/jira/browse/CASSANDRA-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Courreges updated CASSANDRA-4657: -- Description: If clients connect to a cassandra cluster configured with rpc_server_type: sync with heterogeneous cql versions (2 and 3), the cql version used for execution on the server changes seemingly randomly. It's due to the fact that CustomTThreadPoolServer.java does not set the remoteSocket anytime, or does not clear the cql version in the ThreadLocal clientState object. When CassandraServer.java calls state() it gets the ThreadLocal object clientState, which has its cqlversion already changed by a previous socket that was using the same thread. The easiest fix is probably to do a SocketSessionManagementService.instance.set when accepting a new client and SocketSessionManagementService.instance.remove when the client is closed, but if you really want to use the ThreadLocal clientState and not alloc/destroy a ClientState everytime, then you should clear this clientState on accept of a new client. The problem can be reproduced with cqlsh -3 on one side and a client that does not set the cql version, expecting to get version 2 by default, but actually gettingv v2/v3 depending on which thread it connects to. The problem does not happen with other rpc_server_types, nor with clients that set their cql version at connection. was: If clients connect to a cassandra cluster configured with rpc_server_type: sync with heterogeneous cql versions (2 and 3), the cql version used for execution on the server changes seemingly randomly. It's due to the fact that CustomTThreadPoolServer.java does not set the remoteSocket anytime, or does not clear the cql version in the ThreadLocal clientState object. When CassandraServer.java calls state() it gets the ThreadLocal object clientState, which has its cqlversion already changed by a previous socket that was using the same thread. The easiest fix is probably to do a SocketSessionManagementService.instance.put when accepting a new client and SocketSessionManagementService.instance.remove when the client is closed, but if you really want to use the ThreadLocal clientState and not alloc/destroy a ClientState everytime, then you should clear this clientState on accept of a new client. The problem can be reproduced with cqlsh -3 on one side and a client that does not set the cql version, expecting to get version 2 by default, but actually gettingv v2/v3 depending on which thread it connects to. The problem does not happen with other rpc_server_types, nor with clients that set their cql version at connection. cql version race condition with rpc_server_type: sync - Key: CASSANDRA-4657 URL: https://issues.apache.org/jira/browse/CASSANDRA-4657 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1, 1.1.2, 1.1.5 Environment: Ubuntu 12.04 Reporter: Emmanuel Courreges Labels: features If clients connect to a cassandra cluster configured with rpc_server_type: sync with heterogeneous cql versions (2 and 3), the cql version used for execution on the server changes seemingly randomly. It's due to the fact that CustomTThreadPoolServer.java does not set the remoteSocket anytime, or does not clear the cql version in the ThreadLocal clientState object. When CassandraServer.java calls state() it gets the ThreadLocal object clientState, which has its cqlversion already changed by a previous socket that was using the same thread. The easiest fix is probably to do a SocketSessionManagementService.instance.set when accepting a new client and SocketSessionManagementService.instance.remove when the client is closed, but if you really want to use the ThreadLocal clientState and not alloc/destroy a ClientState everytime, then you should clear this clientState on accept of a new client. The problem can be reproduced with cqlsh -3 on one side and a client that does not set the cql version, expecting to get version 2 by default, but actually gettingv v2/v3 depending on which thread it connects to. The problem does not happen with other rpc_server_types, nor with clients that set their cql version at connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4611) Add AlterKeyspace statement
[ https://issues.apache.org/jira/browse/CASSANDRA-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454058#comment-13454058 ] Pavel Yaskevich commented on CASSANDRA-4611: +1 Add AlterKeyspace statement --- Key: CASSANDRA-4611 URL: https://issues.apache.org/jira/browse/CASSANDRA-4611 Project: Cassandra Issue Type: New Feature Components: API Affects Versions: 1.1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: cql3 Fix For: 1.2.0 beta 1 Attachments: 4611.txt, 4611-v2.txt Somehow we never added an ALTER KEYSPACE statement. We should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize free memory
[
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454061#comment-13454061
]
Martin Mokry commented on CASSANDRA-4104:
-
Yes, with the -f (foreground) option. By nothing printed I meant nothing but
what seems to be running config option:
cassandra -f
xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms105M -Xmx105M -Xmn92M
-XX:+HeapDumpOnOutOfMemoryError -Xss128k
^C^C
after that the process is killable only by -9
Cassandra appears to hang when JNA enabled and heapsize free memory
-
Key: CASSANDRA-4104
URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.8
Reporter: Joaquin Casares
Priority: Minor
Labels: datastax_qa
When JNA is enabled heapsize is larger than free memory, all that is printed
out is the classpath, then the printouts stop.
If you hit enter again, you get the commandline, but no Cassandra process is
running.
Tested on both OpenJDK and Oracle Java.
{noformat}
datastax@datastax-image:~/repos/cassandra$ free -m
total used free sharedbuffers cached
Mem: 2008740 1267 0 3 54
-/+ buffers/cache:682 1326
Swap:0 0 0
datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
datastax@datastax-image:~/repos/cassandra$ INFO 14:31:32,520 Logging
initialized
INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_31
INFO 14:31:32,534 Heap size: 1247805440/1247805440
INFO 14:31:32,534 Classpath:
bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
datastax 18374 1.0 0.0 13448 904 pts/2S+ 14:32 0:00 grep
--color=auto cass
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4655) Truncate operation doesn't delete rows from HintsColumnFamily.
[ https://issues.apache.org/jira/browse/CASSANDRA-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zotov updated CASSANDRA-4655: Description: Steps to reproduce: 1. Start writing of data to some column family, let name it 'MyCF' 2. Stop 1 node 3. Wait some time (until some data will be collected in HintsColumnFamily) 4. Start node (HintedHandoff will be started automatically for 'MyCF') 5. Run 'truncate' command for 'MyCF' column family from command from cli 6. Wait until truncate will be finished 7. You will see that 'MyCF' is not empty because HintedHandoff is copying data So, I suggest to clean HintsColumnFamily (for truncated column family) before we had started to discard sstables. I think it should be done in CompactionManager#submitTrucate() method. I can try to create patch but I need to know right way of cleaning HintsColumnFamily. Could you clarify it? was: Step to reproduce: 1. Start writing of data to some column family, let name it 'MyCF' 2. Stop 1 node 3. Wait some time (until some data will be collected in HintsColumnFamily) 4. Start node (HintedHandoff will be started automatically for 'MyCF') 5. Run 'truncate' command for 'MyCF' column family from command from cli 6. Wait until truncate will be finished 7. You will see that 'MyCF' is not empty because HintedHandoff is copying data So, I suggest to clean HintsColumnFamily (for truncated column family) before we had started to discard sstables. I think it should be done in CompactionManager#submitTrucate() method. I can try to create patch but I need to know right way of cleaning HintsColumnFamily. Could you clarify it? Truncate operation doesn't delete rows from HintsColumnFamily. -- Key: CASSANDRA-4655 URL: https://issues.apache.org/jira/browse/CASSANDRA-4655 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.4 Environment: Centos 6.2, Cassandra 1.1.4 (DataStax distribution), three-nodes cluster. Reporter: Alexey Zotov Priority: Minor Steps to reproduce: 1. Start writing of data to some column family, let name it 'MyCF' 2. Stop 1 node 3. Wait some time (until some data will be collected in HintsColumnFamily) 4. Start node (HintedHandoff will be started automatically for 'MyCF') 5. Run 'truncate' command for 'MyCF' column family from command from cli 6. Wait until truncate will be finished 7. You will see that 'MyCF' is not empty because HintedHandoff is copying data So, I suggest to clean HintsColumnFamily (for truncated column family) before we had started to discard sstables. I think it should be done in CompactionManager#submitTrucate() method. I can try to create patch but I need to know right way of cleaning HintsColumnFamily. Could you clarify it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4657) cql version race condition with rpc_server_type: sync
[ https://issues.apache.org/jira/browse/CASSANDRA-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Courreges updated CASSANDRA-4657: -- Attachment: 4657.patch Patch with set and remove cql version race condition with rpc_server_type: sync - Key: CASSANDRA-4657 URL: https://issues.apache.org/jira/browse/CASSANDRA-4657 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.1, 1.1.2, 1.1.5 Environment: Ubuntu 12.04 Reporter: Emmanuel Courreges Labels: features Attachments: 4657.patch If clients connect to a cassandra cluster configured with rpc_server_type: sync with heterogeneous cql versions (2 and 3), the cql version used for execution on the server changes seemingly randomly. It's due to the fact that CustomTThreadPoolServer.java does not set the remoteSocket anytime, or does not clear the cql version in the ThreadLocal clientState object. When CassandraServer.java calls state() it gets the ThreadLocal object clientState, which has its cqlversion already changed by a previous socket that was using the same thread. The easiest fix is probably to do a SocketSessionManagementService.instance.set when accepting a new client and SocketSessionManagementService.instance.remove when the client is closed, but if you really want to use the ThreadLocal clientState and not alloc/destroy a ClientState everytime, then you should clear this clientState on accept of a new client. The problem can be reproduced with cqlsh -3 on one side and a client that does not set the cql version, expecting to get version 2 by default, but actually gettingv v2/v3 depending on which thread it connects to. The problem does not happen with other rpc_server_types, nor with clients that set their cql version at connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Add ALTER KEYSPACE statement to CQL3
Updated Branches:
refs/heads/trunk c64d975cd - 1e126dada
Add ALTER KEYSPACE statement to CQL3
patch by slebresne; reviewed by xedin for CASSANDRA-4611
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1e126dad
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1e126dad
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1e126dad
Branch: refs/heads/trunk
Commit: 1e126dadac0498a8fac9841da6d216d2510a2a1c
Parents: c64d975
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Wed Sep 12 18:03:19 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Wed Sep 12 18:03:19 2012 +0200
--
CHANGES.txt|1 +
.../org/apache/cassandra/config/KSMetaData.java|8 +-
.../org/apache/cassandra/cql/QueryProcessor.java |3 +-
src/java/org/apache/cassandra/cql3/CFPropDefs.java | 194 ---
src/java/org/apache/cassandra/cql3/Cql.g | 32 ++-
src/java/org/apache/cassandra/cql3/KSPropDefs.java | 86 +++
.../apache/cassandra/cql3/PropertyDefinitions.java | 148 +++
.../cql3/statements/AlterKeyspaceStatement.java| 86 +++
.../cql3/statements/AlterTableStatement.java |6 +-
.../statements/CreateColumnFamilyStatement.java|2 +-
.../cql3/statements/CreateKeyspaceStatement.java | 38 +--
11 files changed, 412 insertions(+), 192 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e126dad/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 630ae18..371af7c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -61,6 +61,7 @@
* Replace Throttle with Guava's RateLimiter for HintedHandOff (CASSANDRA-4541)
* fix counter add/get using CQL2 and CQL3 in stress tool (CASSANDRA-4633)
* Add sstable count per level to cfstats (CASSANDRA-4537)
+ * (cql3) Add ALTER KEYSPACE statement (CASSANDRA-4611)
1.1.6
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e126dad/src/java/org/apache/cassandra/config/KSMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/KSMetaData.java
b/src/java/org/apache/cassandra/config/KSMetaData.java
index 9feb0d3..050e32f 100644
--- a/src/java/org/apache/cassandra/config/KSMetaData.java
+++ b/src/java/org/apache/cassandra/config/KSMetaData.java
@@ -57,18 +57,18 @@ public final class KSMetaData
}
// For new user created keyspaces (through CQL)
-public static KSMetaData newKeyspace(String name, String strategyName,
MapString, String options) throws ConfigurationException
+public static KSMetaData newKeyspace(String name, String strategyName,
MapString, String options, boolean durableWrites) throws
ConfigurationException
{
Class? extends AbstractReplicationStrategy cls =
AbstractReplicationStrategy.getClass(strategyName);
if (cls.equals(LocalStrategy.class))
throw new ConfigurationException(Unable to use given strategy
class: LocalStrategy is reserved for internal use.);
-return newKeyspace(name, cls, options,
Collections.CFMetaDataemptyList());
+return newKeyspace(name, cls, options, durableWrites,
Collections.CFMetaDataemptyList());
}
-public static KSMetaData newKeyspace(String name, Class? extends
AbstractReplicationStrategy strategyClass, MapString, String options,
IterableCFMetaData cfDefs)
+public static KSMetaData newKeyspace(String name, Class? extends
AbstractReplicationStrategy strategyClass, MapString, String options,
boolean durablesWrites, IterableCFMetaData cfDefs)
{
-return new KSMetaData(name, strategyClass, options, true, cfDefs);
+return new KSMetaData(name, strategyClass, options, durablesWrites,
cfDefs);
}
public static KSMetaData cloneWith(KSMetaData ksm, IterableCFMetaData
cfDefs)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e126dad/src/java/org/apache/cassandra/cql/QueryProcessor.java
--
diff --git a/src/java/org/apache/cassandra/cql/QueryProcessor.java
b/src/java/org/apache/cassandra/cql/QueryProcessor.java
index 074c50a..f3800cb 100644
--- a/src/java/org/apache/cassandra/cql/QueryProcessor.java
+++ b/src/java/org/apache/cassandra/cql/QueryProcessor.java
@@ -647,7 +647,8 @@ public class QueryProcessor
{
KSMetaData ksm = KSMetaData.newKeyspace(create.getName(),
create.getStrategyClass(),
-
create.getStrategyOptions());
+
[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize free memory
[
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454092#comment-13454092
]
Jonathan Ellis commented on CASSANDRA-4104:
---
Did you check for swap activity? I'd expect it to start swapping fiercely when
you ask it to do something like that.
Cassandra appears to hang when JNA enabled and heapsize free memory
-
Key: CASSANDRA-4104
URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.8
Reporter: Joaquin Casares
Priority: Minor
Labels: datastax_qa
When JNA is enabled heapsize is larger than free memory, all that is printed
out is the classpath, then the printouts stop.
If you hit enter again, you get the commandline, but no Cassandra process is
running.
Tested on both OpenJDK and Oracle Java.
{noformat}
datastax@datastax-image:~/repos/cassandra$ free -m
total used free sharedbuffers cached
Mem: 2008740 1267 0 3 54
-/+ buffers/cache:682 1326
Swap:0 0 0
datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
datastax@datastax-image:~/repos/cassandra$ INFO 14:31:32,520 Logging
initialized
INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_31
INFO 14:31:32,534 Heap size: 1247805440/1247805440
INFO 14:31:32,534 Classpath:
bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
datastax 18374 1.0 0.0 13448 904 pts/2S+ 14:32 0:00 grep
--color=auto cass
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454101#comment-13454101
]
Brandon Williams commented on CASSANDRA-4656:
-
In CASSANDRA-3722 I added similar functionality (nodetool proxyhistograms), but
that's only in 1.2. I suggest backporting that if this is targeting 1.1 to make
merging easier.
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Priority: Minor
Attachments: StorageProxy_histograms.patch
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize free memory
[
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454103#comment-13454103
]
Martin Mokry commented on CASSANDRA-4104:
-
the memory doesn't even fill up. It looks like it just assesses that there is
not enough memory to starts so it just hangs there but doesnt print any message
about it http://pastebin.com/A1pDMWYk . Now I have turned on set -x in
cassandra-env.sh and got some extra messages out of it
http://pastebin.com/S1HxJNLs but still hangs at the end with no apparent system
activity.
Cassandra appears to hang when JNA enabled and heapsize free memory
-
Key: CASSANDRA-4104
URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.8
Reporter: Joaquin Casares
Priority: Minor
Labels: datastax_qa
When JNA is enabled heapsize is larger than free memory, all that is printed
out is the classpath, then the printouts stop.
If you hit enter again, you get the commandline, but no Cassandra process is
running.
Tested on both OpenJDK and Oracle Java.
{noformat}
datastax@datastax-image:~/repos/cassandra$ free -m
total used free sharedbuffers cached
Mem: 2008740 1267 0 3 54
-/+ buffers/cache:682 1326
Swap:0 0 0
datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
datastax@datastax-image:~/repos/cassandra$ INFO 14:31:32,520 Logging
initialized
INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_31
INFO 14:31:32,534 Heap size: 1247805440/1247805440
INFO 14:31:32,534 Classpath:
bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
datastax 18374 1.0 0.0 13448 904 pts/2S+ 14:32 0:00 grep
--color=auto cass
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4104) Cassandra appears to hang when JNA enabled and heapsize free memory
[
https://issues.apache.org/jira/browse/CASSANDRA-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454129#comment-13454129
]
Brandon Williams commented on CASSANDRA-4104:
-
According to the set -x log, JNA isn't enabled.
Cassandra appears to hang when JNA enabled and heapsize free memory
-
Key: CASSANDRA-4104
URL: https://issues.apache.org/jira/browse/CASSANDRA-4104
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.8
Reporter: Joaquin Casares
Priority: Minor
Labels: datastax_qa
When JNA is enabled heapsize is larger than free memory, all that is printed
out is the classpath, then the printouts stop.
If you hit enter again, you get the commandline, but no Cassandra process is
running.
Tested on both OpenJDK and Oracle Java.
{noformat}
datastax@datastax-image:~/repos/cassandra$ free -m
total used free sharedbuffers cached
Mem: 2008740 1267 0 3 54
-/+ buffers/cache:682 1326
Swap:0 0 0
datastax@datastax-image:~/repos/cassandra$ sudo bin/cassandra
datastax@datastax-image:~/repos/cassandra$ INFO 14:31:32,520 Logging
initialized
INFO 14:31:32,533 JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_31
INFO 14:31:32,534 Heap size: 1247805440/1247805440
INFO 14:31:32,534 Classpath:
bin/../conf:bin/../build/classes/main:bin/../build/classes/thrift:bin/../lib/antlr-3.2.jar:bin/../lib/avro-1.4.0-fixes.jar:bin/../lib/avro-1.4.0-sources-fixes.jar:bin/../lib/commons-cli-1.1.jar:bin/../lib/commons-codec-1.2.jar:bin/../lib/commons-lang-2.4.jar:bin/../lib/compress-lzf-0.8.4.jar:bin/../lib/concurrentlinkedhashmap-lru-1.2.jar:bin/../lib/guava-r08.jar:bin/../lib/high-scale-lib-1.1.2.jar:bin/../lib/jackson-core-asl-1.4.0.jar:bin/../lib/jackson-mapper-asl-1.4.0.jar:bin/../lib/jamm-0.2.5.jar:bin/../lib/jline-0.9.94.jar:bin/../lib/jna.jar:bin/../lib/json-simple-1.1.jar:bin/../lib/libthrift-0.6.jar:bin/../lib/log4j-1.2.16.jar:bin/../lib/servlet-api-2.5-20081211.jar:bin/../lib/slf4j-api-1.6.1.jar:bin/../lib/slf4j-log4j12-1.6.1.jar:bin/../lib/snakeyaml-1.6.jar:bin/../lib/snappy-java-1.0.4.1.jar:bin/../lib/jamm-0.2.5.jar
datastax@datastax-image:~/repos/cassandra$ ps auwx | grep cass
datastax 18374 1.0 0.0 13448 904 pts/2S+ 14:32 0:00 grep
--color=auto cass
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4448:
Attachment: (was: 4448.txt)
CQL3: allow to define a per-cf default consistency level
Key: CASSANDRA-4448
URL: https://issues.apache.org/jira/browse/CASSANDRA-4448
Project: Cassandra
Issue Type: New Feature
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0
Attachments: 4448.txt
One of the goal of CQL3 is that client library should not have to parse
queries to provide a good experience. In particular, that means such client
(that don't want to parse queries) won't be able to allow the user to define
a specific default read/write consistency level per-CF, forcing user to
specific the consistency level with every query, which is not very user
friendly.
This ticket suggests the addition of per-cf default read/write consitency
level. Typically the syntax would be:
{noformat}
CREATE TABLE foo (...)
WITH DEFAULT_READ_CONSISTENCY = QUORUM
AND DEFAULT_WRITE_CONSISTENCY = QUORUM
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4448:
Attachment: 4448.txt
Patch rebased to latest trunk
CQL3: allow to define a per-cf default consistency level
Key: CASSANDRA-4448
URL: https://issues.apache.org/jira/browse/CASSANDRA-4448
Project: Cassandra
Issue Type: New Feature
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0
Attachments: 4448.txt
One of the goal of CQL3 is that client library should not have to parse
queries to provide a good experience. In particular, that means such client
(that don't want to parse queries) won't be able to allow the user to define
a specific default read/write consistency level per-CF, forcing user to
specific the consistency level with every query, which is not very user
friendly.
This ticket suggests the addition of per-cf default read/write consitency
level. Typically the syntax would be:
{noformat}
CREATE TABLE foo (...)
WITH DEFAULT_READ_CONSISTENCY = QUORUM
AND DEFAULT_WRITE_CONSISTENCY = QUORUM
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4658) NTS/RackAwareness doesn't work with vnodes
Nick Bailey created CASSANDRA-4658: -- Summary: NTS/RackAwareness doesn't work with vnodes Key: CASSANDRA-4658 URL: https://issues.apache.org/jira/browse/CASSANDRA-4658 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Nick Bailey Fix For: 1.2.0 It doesn't look like the current vnode placement strategy will work with people using NTS and multiple racks. For reasons also described on CASSANDRA-3810, using racks and NTS requires tokens to alternate racks around the ring in order to get an even distribution of data. The current solution for upgrading/placing vnodes won't take this into account and will likely generate some hotspots around the ring. Not sure what the best solution is. The two immediately obvious approaches appear to be quite complicated at first. * Fixing NTS to remove the requirement for rack ordering ** No idea how this would be accomplished ** Presents challenges for people upgrading. Would need to deprecate NTS for a new strategy that replaces it, then have a clear upgrade path to that strategy which would need to be in a pre 1.2 release. * Changing vnode placement strategy ** Ordering vnodes would require quite a bit of additional logic. Adding a new node or rack would also need to maintain ordering which could cause enough data movement to remove any benefits vnodes have already. ** We could potentially adjust vnode token placement to offset any imbalances caused by NTS but this would require a fairly intelligent mechanism for determining vnode placement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4659) Fix consistency ALL parsing in CQL3
Sylvain Lebresne created CASSANDRA-4659: --- Summary: Fix consistency ALL parsing in CQL3 Key: CASSANDRA-4659 URL: https://issues.apache.org/jira/browse/CASSANDRA-4659 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 1.2.0 beta 1 CASSANDRA-4490 made some change to the parsing of ALL for consistency levels (introducing a specific token K_ALL). It's unclear why since that new token is not used (that is, except for the consistency level), probably some left over of a previous version of the patch. In any case, this doesn't work. K_ALL and K_LEVEL being both tokens, the string 'ALL' will always generate K_ALL and never K_LEVEL and thus 'USING CONSISTENCY ALL' doesn't parse anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4658) NTS/RackAwareness doesn't work with vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454159#comment-13454159 ] Nick Bailey commented on CASSANDRA-4658: We could potentially say that rack awareness and vnodes are incompatible. Which will essentially mean that cassandra can't guarantee that losing a single rack won't bring down an entire replica set. That makes the problem slightly easier, but still requires some sort of clear upgrade path for people on NTS with racks. Changing the replication strategy or changing the snitch to report different racks won't cause data to be streamed to any new owners. So we would need to come up with a mechanism for updating without data loss. NTS/RackAwareness doesn't work with vnodes -- Key: CASSANDRA-4658 URL: https://issues.apache.org/jira/browse/CASSANDRA-4658 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Nick Bailey Fix For: 1.2.0 It doesn't look like the current vnode placement strategy will work with people using NTS and multiple racks. For reasons also described on CASSANDRA-3810, using racks and NTS requires tokens to alternate racks around the ring in order to get an even distribution of data. The current solution for upgrading/placing vnodes won't take this into account and will likely generate some hotspots around the ring. Not sure what the best solution is. The two immediately obvious approaches appear to be quite complicated at first. * Fixing NTS to remove the requirement for rack ordering ** No idea how this would be accomplished ** Presents challenges for people upgrading. Would need to deprecate NTS for a new strategy that replaces it, then have a clear upgrade path to that strategy which would need to be in a pre 1.2 release. * Changing vnode placement strategy ** Ordering vnodes would require quite a bit of additional logic. Adding a new node or rack would also need to maintain ordering which could cause enough data movement to remove any benefits vnodes have already. ** We could potentially adjust vnode token placement to offset any imbalances caused by NTS but this would require a fairly intelligent mechanism for determining vnode placement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4659) Fix consistency ALL parsing in CQL3
[ https://issues.apache.org/jira/browse/CASSANDRA-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4659: Attachment: 4659.txt Trivial patch that revert the change from CASSANDRA-4490 since it's not used anyway. Fix consistency ALL parsing in CQL3 --- Key: CASSANDRA-4659 URL: https://issues.apache.org/jira/browse/CASSANDRA-4659 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 1.2.0 beta 1 Attachments: 4659.txt CASSANDRA-4490 made some change to the parsing of ALL for consistency levels (introducing a specific token K_ALL). It's unclear why since that new token is not used (that is, except for the consistency level), probably some left over of a previous version of the patch. In any case, this doesn't work. K_ALL and K_LEVEL being both tokens, the string 'ALL' will always generate K_ALL and never K_LEVEL and thus 'USING CONSISTENCY ALL' doesn't parse anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-4559:
Attachment: (was: 4559.txt)
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-4559:
Attachment: 4559.txt
During token conflict resolution, we were 'protecting' the relocating host by
making it win, however this only occurred when received a normal state from it.
Since under concurrent relocations we have no guarantee of the order we'll
receive messages in, it was possible for the 'loser' to send a normal first,
causing generation comparison which could ultimately make the token disappear
from that host until it restarted. Updated patch addresses this and ignores
messages from the loser.
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Attachments: 4559.txt
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4491) cqlsh needs to use system.local instead of system.Versions
[ https://issues.apache.org/jira/browse/CASSANDRA-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4491: --- Description: Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. While we're at it, let's update the cql3 table structure parsing and the DESCRIBE command for the recent Cassandra changes too. was: Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. cqlsh needs to use system.local instead of system.Versions -- Key: CASSANDRA-4491 URL: https://issues.apache.org/jira/browse/CASSANDRA-4491 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Priority: Minor Labels: cqlsh Fix For: 1.2.0 Apparently the system.Versions table was removed as part of CASSANDRA-4018. cqlsh in 1.2 should use system.local preferentially, and fall back on system.Versions to keep backwards compatibility with older c*. Also changed in 4018: all the system.schema_* CFs now use columns named keyspace_name, columnfamily_name, and column_name instead of keyspace, columnfamily, and column. While we're at it, let's update the cql3 table structure parsing and the DESCRIBE command for the recent Cassandra changes too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4659) Fix consistency ALL parsing in CQL3
[ https://issues.apache.org/jira/browse/CASSANDRA-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4659: --- Reviewer: xedin Fix consistency ALL parsing in CQL3 --- Key: CASSANDRA-4659 URL: https://issues.apache.org/jira/browse/CASSANDRA-4659 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 1.2.0 beta 1 Attachments: 4659.txt CASSANDRA-4490 made some change to the parsing of ALL for consistency levels (introducing a specific token K_ALL). It's unclear why since that new token is not used (that is, except for the consistency level), probably some left over of a previous version of the patch. In any case, this doesn't work. K_ALL and K_LEVEL being both tokens, the string 'ALL' will always generate K_ALL and never K_LEVEL and thus 'USING CONSISTENCY ALL' doesn't parse anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4659) Fix consistency ALL parsing in CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454267#comment-13454267
]
Pavel Yaskevich commented on CASSANDRA-4659:
+1, it was a left behind, grant/revoke commands actually using {full,
no}_access.
Fix consistency ALL parsing in CQL3
---
Key: CASSANDRA-4659
URL: https://issues.apache.org/jira/browse/CASSANDRA-4659
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Trivial
Fix For: 1.2.0 beta 1
Attachments: 4659.txt
CASSANDRA-4490 made some change to the parsing of ALL for consistency levels
(introducing a specific token K_ALL). It's unclear why since that new token
is not used (that is, except for the consistency level), probably some left
over of a previous version of the patch.
In any case, this doesn't work. K_ALL and K_LEVEL being both tokens, the
string 'ALL' will always generate K_ALL and never K_LEVEL and thus 'USING
CONSISTENCY ALL' doesn't parse anymore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Fix parsing of consistency ALL in CQL3
Updated Branches: refs/heads/trunk 1e126dada - 8edf6a619 Fix parsing of consistency ALL in CQL3 patch by slebresne; reviewed by xedin for CASSANDRA-4659 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8edf6a61 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8edf6a61 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8edf6a61 Branch: refs/heads/trunk Commit: 8edf6a6192ca201e5c2ef84452a21b8de2b953df Parents: 1e126da Author: Sylvain Lebresne sylv...@datastax.com Authored: Wed Sep 12 21:20:36 2012 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Wed Sep 12 21:20:36 2012 +0200 -- src/java/org/apache/cassandra/cql3/Cql.g |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/8edf6a61/src/java/org/apache/cassandra/cql3/Cql.g -- diff --git a/src/java/org/apache/cassandra/cql3/Cql.g b/src/java/org/apache/cassandra/cql3/Cql.g index 79c5b9f..01dbafd 100644 --- a/src/java/org/apache/cassandra/cql3/Cql.g +++ b/src/java/org/apache/cassandra/cql3/Cql.g @@ -752,11 +752,10 @@ K_UPDATE: U P D A T E; K_WITH:W I T H; K_LIMIT: L I M I T; K_USING: U S I N G; -K_ALL: A L L; K_CONSISTENCY: C O N S I S T E N C Y; K_LEVEL: ( O N E | Q U O R U M - | K_ALL + | A L L | A N Y | L O C A L '_' Q U O R U M | E A C H '_' Q U O R U M
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454303#comment-13454303
]
Yuki Morishita commented on CASSANDRA-4448:
---
Patch lgtm, +1.
I just note that these two CF params are first ones that only available through
CQL3.
No thrift CfDef definition and no CQL2 CFPropDefs definition.
But this should be fine since CQL3 is going to be default from 1.2.
CQL3: allow to define a per-cf default consistency level
Key: CASSANDRA-4448
URL: https://issues.apache.org/jira/browse/CASSANDRA-4448
Project: Cassandra
Issue Type: New Feature
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0
Attachments: 4448.txt
One of the goal of CQL3 is that client library should not have to parse
queries to provide a good experience. In particular, that means such client
(that don't want to parse queries) won't be able to allow the user to define
a specific default read/write consistency level per-CF, forcing user to
specific the consistency level with every query, which is not very user
friendly.
This ticket suggests the addition of per-cf default read/write consitency
level. Typically the syntax would be:
{noformat}
CREATE TABLE foo (...)
WITH DEFAULT_READ_CONSISTENCY = QUORUM
AND DEFAULT_WRITE_CONSISTENCY = QUORUM
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4627) support inet data type
[ https://issues.apache.org/jira/browse/CASSANDRA-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4627: --- Reviewer: brandon.williams My additional changes committed into the 4627 branch in my github clone: http://github.com/thepaul/cassandra/tree/4627 Notice that this includes an update of the internal CQL lib, so there's a zipfile to add and one to remove. support inet data type -- Key: CASSANDRA-4627 URL: https://issues.apache.org/jira/browse/CASSANDRA-4627 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Assignee: paul cannon Labels: cql, cqlsh Fix For: 1.2.0 beta 1 Attachments: 4627.txt CASSANDRA-4018 introduced a new cassandra data type with a cql name inet, which is not yet supported in cqlsh. Add support for decoding and formatting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4644) Compaction error with Cassandra 1.1.4 and LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454362#comment-13454362 ] Rudolf VanderLeeden commented on CASSANDRA-4644: Maybe, the following debug lines help to find the cause: DEBUG 20:59:47,207 Deleted /mnt/cassandra/data/highscores/leaderboard/highscores-leaderboard-he-18148 DEBUG 20:59:47,207 L0 contains 4422 SSTables (62004030662 bytes) in Manifest@451835319 DEBUG 20:59:47,207 L1 contains 14 SSTables (258039196 bytes) in Manifest@451835319 DEBUG 20:59:47,208 L2 contains 33 SSTables (508660830 bytes) in Manifest@451835319 DEBUG 20:59:47,208 L3 contains 360 SSTables (3536343071 bytes) in Manifest@451835319 DEBUG 20:59:47,209 L4 contains 1813 SSTables (32410447712 bytes) in Manifest@451835319 DEBUG 20:59:47,209 Replacing [leaderboard-18148(L1), ] DEBUG 20:59:47,209 Adding [leaderboard-21505(L-1), ] at L2 ERROR 20:59:47,209 Exception in thread Thread[CompactionExecutor:5,1,RMI Runtime] java.lang.AssertionError Compaction error with Cassandra 1.1.4 and LCS -- Key: CASSANDRA-4644 URL: https://issues.apache.org/jira/browse/CASSANDRA-4644 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.4 Environment: Cassandra 1.1.4, Ubuntu Lucid (2.6.32-346), Amazon EC2 m1.xlarge Reporter: Rudolf VanderLeeden In our 1.1.4 testcluster of 3 nodes with RF=3, KS=1, and CF=5, we are getting an asserting error when running 'nodetool compact highscores leaderboard'. This stops compactions on the 'leaderboard' CF summing up to 11835 pending compactions. This error is seen only one one node. The SSTables have originally been created on a 1.1.2 cluster with STCS and then copied to the testcluster also with 1.1.2. Repair, cleanup, compact were OK with STCS. Next, we changed to LCS and did again repair, cleanup, compact with success. Then we started to use this LCS-based testcluster intensively and created lots of data and also large keys with millions of columns. The assertion error in system.log : INFO [CompactionExecutor:8] 2012-09-11 14:20:45,043 CompactionController.java (line 172) Compacting large row highscores/leaderboard:4c422d64626331353166372d363464612d343235342d396130322d6535616365343337373532332d676c6f62616c2d30 (72589650 bytes) incrementally ERROR [CompactionExecutor:8] 2012-09-11 14:20:50,336 AbstractCassandraDaemon.java (line 135) Exception in thread Thread[CompactionExecutor:8,1,RMI Runtime] java.lang.AssertionError at org.apache.cassandra.db.compaction.LeveledManifest.promote(LeveledManifest.java:214) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.handleNotification(LeveledCompactionStrategy.java:158) at org.apache.cassandra.db.DataTracker.notifySSTablesChanged(DataTracker.java:531) at org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:254) at org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:992) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:200) at org.apache.cassandra.db.compaction.LeveledCompactionTask.execute(LeveledCompactionTask.java:50) at org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:288) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4660) During Streaming, a new connection is created for every sstable we need to transfer.
sankalp kohli created CASSANDRA-4660: Summary: During Streaming, a new connection is created for every sstable we need to transfer. Key: CASSANDRA-4660 URL: https://issues.apache.org/jira/browse/CASSANDRA-4660 Project: Cassandra Issue Type: New Feature Components: Core Reporter: sankalp kohli Priority: Minor We should try to reuse the connection for streaming sstables. This is inefficient when we are bootstrapping a large node with thousands of sstables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4350) cql cassandra version reporting is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna resolved CASSANDRA-4350.
-
Resolution: Cannot Reproduce
I tried to reproduce with cassandra 1.0.10 as the cluster version and tried
cqlsh from 1.0.8, 1.0.9, and 1.0.11. All three when starting reported the
correct version (1.0.10) of the instance it connected to. Resolving this as
cannot reproduce.
cql cassandra version reporting is incorrect
Key: CASSANDRA-4350
URL: https://issues.apache.org/jira/browse/CASSANDRA-4350
Project: Cassandra
Issue Type: Bug
Reporter: Jeremy Hanna
Assignee: paul cannon
Priority: Minor
Labels: cql, cqlsh
It looks like either the docs are wrong or the functionality is wrong. The
docs for show version say:
{quote}
Shows the version and build of the connected Cassandra instance, well as the
versions of the CQL spec and the Thrift protocol that the connected Cassandra
instance understands.
{quote}
On a cassandra node in the ring, I do nodetool -h localhost version and it
outputs the correct version (1.0.8). From a remote node with 1.0.9
installed, I run nodetool -h same_node_in_ring version. It outputs the
correct version. However when I start cqlsh, it shows the remote node's
version (1.0.9). Also when I use the 'show version;' command in cqlsh, it
also prints out 1.0.9.
So either the docs are incorrect and it just outputs the version of the local
build or there's a bug in show version and the startup output and it should
really show the version of the connected node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4661) cassandra-cli: allow Double value type to be inserted to a column
Yuhan Zhang created CASSANDRA-4661:
--
Summary: cassandra-cli: allow Double value type to be inserted to
a column
Key: CASSANDRA-4661
URL: https://issues.apache.org/jira/browse/CASSANDRA-4661
Project: Cassandra
Issue Type: Improvement
Reporter: Yuhan Zhang
as a cassandra-cli user, I'd like to set DoubleType value to cassandra through
the cli tool, such that I could create test data from the cli tool easily.
(similarly, I'd like to Double value available in the assume command: ex:
assume pageCache comparator as double; )
The email related to this issue:
Hi all,
I'm trying to manually adding some double values into a column family. From the
Hector client, there's a DoubleSerializer.
but looks like the cli tool is not providing a way to enter floating point
values. here's the message I got:
[default@video] set cateogry['1']['sport'] = float('0.5');
Function 'float' not found. Available functions: bytes, integer, long, int,
lexicaluuid, timeuuid, utf8, ascii, countercolumn.
Is there a way to insert floating pointer value from the cli tool?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454449#comment-13454449
]
Jonathan Ellis commented on CASSANDRA-4448:
---
Should probably include in CfDef :(
CQL2 doesn't need it though.
CQL3: allow to define a per-cf default consistency level
Key: CASSANDRA-4448
URL: https://issues.apache.org/jira/browse/CASSANDRA-4448
Project: Cassandra
Issue Type: New Feature
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0
Attachments: 4448.txt
One of the goal of CQL3 is that client library should not have to parse
queries to provide a good experience. In particular, that means such client
(that don't want to parse queries) won't be able to allow the user to define
a specific default read/write consistency level per-CF, forcing user to
specific the consistency level with every query, which is not very user
friendly.
This ticket suggests the addition of per-cf default read/write consitency
level. Typically the syntax would be:
{noformat}
CREATE TABLE foo (...)
WITH DEFAULT_READ_CONSISTENCY = QUORUM
AND DEFAULT_WRITE_CONSISTENCY = QUORUM
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4660) During Streaming, a new connection is created for every sstable we need to transfer.
[ https://issues.apache.org/jira/browse/CASSANDRA-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4660: -- Labels: perfomance ponies (was: perfomance) During Streaming, a new connection is created for every sstable we need to transfer. - Key: CASSANDRA-4660 URL: https://issues.apache.org/jira/browse/CASSANDRA-4660 Project: Cassandra Issue Type: New Feature Components: Core Reporter: sankalp kohli Priority: Minor Labels: perfomance, ponies We should try to reuse the connection for streaming sstables. This is inefficient when we are bootstrapping a large node with thousands of sstables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4662) Core support for Thrift SSL integration
Jason Brown created CASSANDRA-4662: -- Summary: Core support for Thrift SSL integration Key: CASSANDRA-4662 URL: https://issues.apache.org/jira/browse/CASSANDRA-4662 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jason Brown Assignee: Jason Brown Fix For: 1.1.6 Ticket to separate out the changes to yaml and cassandra/thrift code for the thrift SSL integration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4662) Core support for Thrift SSL integration
[ https://issues.apache.org/jira/browse/CASSANDRA-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-4662: --- Attachment: 0001-CASSANDRA-4662.-Core-work-of-adding-thrift-ssl-suppo.patch CASSANDRA-4662. Core work of adding thrift ssl support. Includes modification to the yaml and associated config classes. Extended EncryptionOptions with client and server subclasses. Added ThriftSSLFactory to act as the centralized source for getting client and server thrift sockets (much like SSLFactory). Core support for Thrift SSL integration --- Key: CASSANDRA-4662 URL: https://issues.apache.org/jira/browse/CASSANDRA-4662 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jason Brown Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0001-CASSANDRA-4662.-Core-work-of-adding-thrift-ssl-suppo.patch Ticket to separate out the changes to yaml and cassandra/thrift code for the thrift SSL integration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4662) Core support for Thrift SSL integration
[ https://issues.apache.org/jira/browse/CASSANDRA-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454482#comment-13454482 ] Jason Brown edited comment on CASSANDRA-4662 at 9/13/12 10:34 AM: -- Core work of adding thrift ssl support. Includes modification to the yaml and associated config classes. Extended EncryptionOptions with client and server subclasses. Added ThriftSSLFactory to act as the centralized source for getting client and server thrift sockets (much like SSLFactory). was (Author: jasobrown): CASSANDRA-4662. Core work of adding thrift ssl support. Includes modification to the yaml and associated config classes. Extended EncryptionOptions with client and server subclasses. Added ThriftSSLFactory to act as the centralized source for getting client and server thrift sockets (much like SSLFactory). Core support for Thrift SSL integration --- Key: CASSANDRA-4662 URL: https://issues.apache.org/jira/browse/CASSANDRA-4662 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jason Brown Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0001-CASSANDRA-4662.-Core-work-of-adding-thrift-ssl-suppo.patch Ticket to separate out the changes to yaml and cassandra/thrift code for the thrift SSL integration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4608) Add thrift server factory to CassandraDaemon
[ https://issues.apache.org/jira/browse/CASSANDRA-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454484#comment-13454484 ] Jason Brown edited comment on CASSANDRA-4608 at 9/13/12 10:36 AM: -- Add thrift server factory to CassandraDaemon. Created interface IServerFactory (modeled after TransportFactory) and implemented it in each of the custom TServer implementations we have (migrated that code out of CassandarDaemon). CD now calls ThriftFactoryHelper for the TServer instance. Overloaded the constructor for TCustomServerSocket to take a socket instance; I wanted to make sure we get the better TCP settings from TCustomServerSocket onto the socket we get from thrift's SSL support. was (Author: jasobrown): Add thrift server factory to CassandraDaemon. Created interface IServerFactory (modeled after TransportFactory) and implemented it in each of the custom TServer implementations we have (migrated that code out of CassandarDaemon). CD now calls ThriftFactoryHelper for the TServer instance. Overloaded the constructor for TCustomServerSocket to take a socket instance; I wanted to make sure we get the better TCP settings from TCustomServerSocket onto the socket we get from thrift's SSL support. Add thrift server factory to CassandraDaemon Key: CASSANDRA-4608 URL: https://issues.apache.org/jira/browse/CASSANDRA-4608 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0002-CASSANDRA-4608-Add-thrift-server-factory-to-Cassandr.patch Add factory class for CassandraServer Default impl will be the current thrift server types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4608) Add thrift server factory to CassandraDaemon
[ https://issues.apache.org/jira/browse/CASSANDRA-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-4608: --- Attachment: 0002-CASSANDRA-4608-Add-thrift-server-factory-to-Cassandr.patch Add thrift server factory to CassandraDaemon. Created interface IServerFactory (modeled after TransportFactory) and implemented it in each of the custom TServer implementations we have (migrated that code out of CassandarDaemon). CD now calls ThriftFactoryHelper for the TServer instance. Overloaded the constructor for TCustomServerSocket to take a socket instance; I wanted to make sure we get the better TCP settings from TCustomServerSocket onto the socket we get from thrift's SSL support. Add thrift server factory to CassandraDaemon Key: CASSANDRA-4608 URL: https://issues.apache.org/jira/browse/CASSANDRA-4608 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0002-CASSANDRA-4608-Add-thrift-server-factory-to-Cassandr.patch Add factory class for CassandraServer Default impl will be the current thrift server types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-4609: --- Attachment: 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch add thrift transport factory support to cassandra-cli. Modified the client to optionally use the client encryptions (thrift ssl) and to use the new ITransportFactory design. Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454602#comment-13454602
]
Vijay commented on CASSANDRA-4573:
--
Hi Tyler, I am not able to re-produce it so far. I am running 2GB/400MB on AWS
M4XL
[ec2-user@ip-10-82-21-221 ~]$ grep -i ThriftServer.java
/mnt/log/cassandra/system.log
INFO [main] 2012-09-11 21:52:43,702 ThriftServer.java (line 112) Binding
thrift service to localhost/127.0.0.1:9160
INFO [main] 2012-09-11 21:52:43,704 ThriftServer.java (line 121) Using
TFastFramedTransport with a max frame size of 15728640 bytes.
INFO [main] 2012-09-11 21:52:43,710 ThriftServer.java (line 191) Using custom
half-sync/half-async thrift server on localhost/127.0.0.1 : 9160
INFO [Thread-2] 2012-09-11 21:52:43,720 ThriftServer.java (line 200) Listening
for thrift clients...
[ec2-user@ip-10-82-21-221 ~]$
The Timeout happens both in Sync and HSHA servers (randomly and i am not able
to reproduce both cases reliably) and the only thing which i can notice is that
the client (pycassa) runs 100% CPU most of the time... other than that
everything else looks normal.
HSHA doesn't handle large messages gracefully
-
Key: CASSANDRA-4573
URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Vijay
Attachments: repro.py
HSHA doesn't seem to enforce any kind of max message length, and when
messages are too large, it doesn't fail gracefully.
With debug logs enabled, you'll see this:
{{DEBUG 13:13:31,805 Unexpected state 16}}
Which seems to mean that there's a SelectionKey that's valid, but isn't ready
for reading, writing, or accepting.
Client-side, you'll get this thrift error (while trying to read a frame as
part of {{recv_batch_mutate}}):
{{TTransportException: TSocket read 0 bytes}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4661) cassandra-cli: allow Double value type to be inserted to a column
[
https://issues.apache.org/jira/browse/CASSANDRA-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated CASSANDRA-4661:
Attachment: 4661.txt
add double('1.0') parsing
cassandra-cli: allow Double value type to be inserted to a column
-
Key: CASSANDRA-4661
URL: https://issues.apache.org/jira/browse/CASSANDRA-4661
Project: Cassandra
Issue Type: Improvement
Reporter: Yuhan Zhang
Attachments: 4661.txt
as a cassandra-cli user, I'd like to set DoubleType value to cassandra
through the cli tool, such that I could create test data from the cli tool
easily.
(similarly, I'd like to Double value available in the assume command: ex:
assume pageCache comparator as double; )
The email related to this issue:
Hi all,
I'm trying to manually adding some double values into a column family. From
the Hector client, there's a DoubleSerializer.
but looks like the cli tool is not providing a way to enter floating point
values. here's the message I got:
[default@video] set cateogry['1']['sport'] = float('0.5');
Function 'float' not found. Available functions: bytes, integer, long, int,
lexicaluuid, timeuuid, utf8, ascii, countercolumn.
Is there a way to insert floating pointer value from the cli tool?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4661) cassandra-cli: allow Double value type to be inserted to a column
[
https://issues.apache.org/jira/browse/CASSANDRA-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated CASSANDRA-4661:
Attachment: 4661.txt
cassandra-cli: allow Double value type to be inserted to a column
-
Key: CASSANDRA-4661
URL: https://issues.apache.org/jira/browse/CASSANDRA-4661
Project: Cassandra
Issue Type: Improvement
Reporter: Yuhan Zhang
Attachments: 4661.txt
as a cassandra-cli user, I'd like to set DoubleType value to cassandra
through the cli tool, such that I could create test data from the cli tool
easily.
(similarly, I'd like to Double value available in the assume command: ex:
assume pageCache comparator as double; )
The email related to this issue:
Hi all,
I'm trying to manually adding some double values into a column family. From
the Hector client, there's a DoubleSerializer.
but looks like the cli tool is not providing a way to enter floating point
values. here's the message I got:
[default@video] set cateogry['1']['sport'] = float('0.5');
Function 'float' not found. Available functions: bytes, integer, long, int,
lexicaluuid, timeuuid, utf8, ascii, countercolumn.
Is there a way to insert floating pointer value from the cli tool?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4661) cassandra-cli: allow Double value type to be inserted to a column
[
https://issues.apache.org/jira/browse/CASSANDRA-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated CASSANDRA-4661:
Attachment: (was: 4661.txt)
cassandra-cli: allow Double value type to be inserted to a column
-
Key: CASSANDRA-4661
URL: https://issues.apache.org/jira/browse/CASSANDRA-4661
Project: Cassandra
Issue Type: Improvement
Reporter: Yuhan Zhang
Attachments: 4661.txt
as a cassandra-cli user, I'd like to set DoubleType value to cassandra
through the cli tool, such that I could create test data from the cli tool
easily.
(similarly, I'd like to Double value available in the assume command: ex:
assume pageCache comparator as double; )
The email related to this issue:
Hi all,
I'm trying to manually adding some double values into a column family. From
the Hector client, there's a DoubleSerializer.
but looks like the cli tool is not providing a way to enter floating point
values. here's the message I got:
[default@video] set cateogry['1']['sport'] = float('0.5');
Function 'float' not found. Available functions: bytes, integer, long, int,
lexicaluuid, timeuuid, utf8, ascii, countercolumn.
Is there a way to insert floating pointer value from the cli tool?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
