[jira] [Created] (CASSANDRA-10584) reads with EACH_QUORUM on keyspace with SimpleTopologyStrategy throw a ClassCastException
Andy Tolbert created CASSANDRA-10584: Summary: reads with EACH_QUORUM on keyspace with SimpleTopologyStrategy throw a ClassCastException Key: CASSANDRA-10584 URL: https://issues.apache.org/jira/browse/CASSANDRA-10584 Project: Cassandra Issue Type: Bug Reporter: Andy Tolbert Priority: Minor I think this may be a regression introduced w/ [CASSANDRA-9602]. Starting with C* 3.0.0-rc2 an error is returned when querying a keyspace with {{SimpleTopologyStrategy}} using EACH_QUORUM CL: {noformat} cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy', 'replication_factor': 1}; cqlsh> create table test.test (k int PRIMARY KEY, i int); cqlsh> consistency EACH_QUORUM; Consistency level set to EACH_QUORUM. cqlsh> select * from test.test; ServerError: {noformat} The exception yielded in the system logs: {noformat} ERROR [SharedPool-Worker-1] 2015-10-23 13:02:15,405 ErrorMessage.java:336 - Unexpected exception during request java.lang.ClassCastException: org.apache.cassandra.locator.SimpleStrategy cannot be cast to org.apache.cassandra.locator.NetworkTopologyStrategy at org.apache.cassandra.db.ConsistencyLevel.filterForEachQuorum(ConsistencyLevel.java:227) ~[main/:na] at org.apache.cassandra.db.ConsistencyLevel.filterForQuery(ConsistencyLevel.java:188) ~[main/:na] at org.apache.cassandra.db.ConsistencyLevel.filterForQuery(ConsistencyLevel.java:180) ~[main/:na] at org.apache.cassandra.service.StorageProxy$RangeIterator.computeNext(StorageProxy.java:1795) ~[main/:na] at org.apache.cassandra.service.StorageProxy$RangeIterator.computeNext(StorageProxy.java:1762) ~[main/:na] at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) ~[main/:na] at com.google.common.collect.Iterators$PeekingImpl.hasNext(Iterators.java:1149) ~[guava-18.0.jar:na] at org.apache.cassandra.service.StorageProxy$RangeMerger.computeNext(StorageProxy.java:1814) ~[main/:na] at org.apache.cassandra.service.StorageProxy$RangeMerger.computeNext(StorageProxy.java:1799) ~[main/:na] at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) ~[main/:na] at org.apache.cassandra.service.StorageProxy$RangeCommandIterator.computeNext(StorageProxy.java:1925) ~[main/:na] at org.apache.cassandra.service.StorageProxy$RangeCommandIterator.computeNext(StorageProxy.java:1892) ~[main/:na] at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) ~[main/:na] at org.apache.cassandra.db.partitions.WrappingPartitionIterator.hasNext(WrappingPartitionIterator.java:33) ~[main/:na] at org.apache.cassandra.db.partitions.CountingPartitionIterator.hasNext(CountingPartitionIterator.java:49) ~[main/:na] at org.apache.cassandra.db.partitions.WrappingPartitionIterator.hasNext(WrappingPartitionIterator.java:33) ~[main/:na] at org.apache.cassandra.db.partitions.CountingPartitionIterator.hasNext(CountingPartitionIterator.java:49) ~[main/:na] at org.apache.cassandra.service.pager.AbstractQueryPager$PagerIterator.hasNext(AbstractQueryPager.java:99) ~[main/:na] at org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:610) ~[main/:na] at org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:371) ~[main/:na] at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:327) ~[main/:na] at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:213) ~[main/:na] at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76) ~[main/:na] at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:205) ~[main/:na] at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:236) ~[main/:na] at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:221) ~[main/:na] at org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115) ~[main/:na] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507) [main/:na] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401) [main/:na] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) [netty-all-4.0.23.Final.jar:4.0.23.Final]
[jira] [Updated] (CASSANDRA-10583) After bulk loading CQL query on timestamp column returns wrong result
[ https://issues.apache.org/jira/browse/CASSANDRA-10583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs updated CASSANDRA-10583: Reproduced In: 2.1.10 Fix Version/s: 2.2.x 2.1.x 3.x > After bulk loading CQL query on timestamp column returns wrong result > - > > Key: CASSANDRA-10583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10583 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Datastax Community Edition 2.1.10, Windows 2008 R2, Java > x64 1.8.0_60 >Reporter: Kai Wang > Fix For: 3.x, 2.1.x, 2.2.x > > > I have this table: > {noformat} > CREATE TABLE test ( > tag text, > group int, > timestamp timestamp, > value double, > PRIMARY KEY (tag, group, timestamp) > ) WITH CLUSTERING ORDER BY (group ASC, timestamp DESC) > {noformat} > First I used CQLSSTableWriter to bulk load a bunch of sstables. Then I ran > this query: > {noformat} > cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp > ='2004-12-15 16:00:00-0500'; > tag | group | timestamp| value > --+---+--+--- > MSFT | 1 | 2004-12-15 21:00:00+ | 27.11 > MSFT | 1 | 2004-12-16 21:00:00+ | 27.16 > MSFT | 1 | 2004-12-17 21:00:00+ | 26.96 > MSFT | 1 | 2004-12-20 21:00:00+ | 26.95 > MSFT | 1 | 2004-12-21 21:00:00+ | 27.07 > MSFT | 1 | 2004-12-22 21:00:00+ | 26.98 > MSFT | 1 | 2004-12-23 21:00:00+ | 27.01 > MSFT | 1 | 2004-12-27 21:00:00+ | 26.85 > MSFT | 1 | 2004-12-28 21:00:00+ | 26.95 > MSFT | 1 | 2004-12-29 21:00:00+ | 26.9 > MSFT | 1 | 2004-12-30 21:00:00+ | 26.76 > (11 rows) > {noformat} > The result is obviously wrong. > If I run this query: > {noformat} > cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp > ='2004-12-16 16:00:00-0500'; > tag | group | timestamp | value > -+---+---+--- > (0 rows) > {noformat} > In DevCenter I tried to create a similar table and insert a few rows but > couldn't reproduce this. This may have something to do with the bulk loading > process. But still, the fact cqlsh returns data that doesn't match the query > is concerning. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10583) After bulk loading CQL query on timestamp column returns wrong result
[ https://issues.apache.org/jira/browse/CASSANDRA-10583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs updated CASSANDRA-10583: Description: I have this table: {noformat} CREATE TABLE test ( tag text, group int, timestamp timestamp, value double, PRIMARY KEY (tag, group, timestamp) ) WITH CLUSTERING ORDER BY (group ASC, timestamp DESC) {noformat} First I used CQLSSTableWriter to bulk load a bunch of sstables. Then I ran this query: {noformat} cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp ='2004-12-15 16:00:00-0500'; tag | group | timestamp| value --+---+--+--- MSFT | 1 | 2004-12-15 21:00:00+ | 27.11 MSFT | 1 | 2004-12-16 21:00:00+ | 27.16 MSFT | 1 | 2004-12-17 21:00:00+ | 26.96 MSFT | 1 | 2004-12-20 21:00:00+ | 26.95 MSFT | 1 | 2004-12-21 21:00:00+ | 27.07 MSFT | 1 | 2004-12-22 21:00:00+ | 26.98 MSFT | 1 | 2004-12-23 21:00:00+ | 27.01 MSFT | 1 | 2004-12-27 21:00:00+ | 26.85 MSFT | 1 | 2004-12-28 21:00:00+ | 26.95 MSFT | 1 | 2004-12-29 21:00:00+ | 26.9 MSFT | 1 | 2004-12-30 21:00:00+ | 26.76 (11 rows) {noformat} The result is obviously wrong. If I run this query: {noformat} cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp ='2004-12-16 16:00:00-0500'; tag | group | timestamp | value -+---+---+--- (0 rows) {noformat} In DevCenter I tried to create a similar table and insert a few rows but couldn't reproduce this. This may have something to do with the bulk loading process. But still, the fact cqlsh returns data that doesn't match the query is concerning. was: I have this table: CREATE TABLE test ( tag text, group int, timestamp timestamp, value double, PRIMARY KEY (tag, group, timestamp) ) WITH CLUSTERING ORDER BY (group ASC, timestamp DESC) First I used CQLSSTableWriter to bulk load a bunch of sstables. Then I ran this query: cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp ='2004-12-15 16:00:00-0500'; tag | group | timestamp| value --+---+--+--- MSFT | 1 | 2004-12-15 21:00:00+ | 27.11 MSFT | 1 | 2004-12-16 21:00:00+ | 27.16 MSFT | 1 | 2004-12-17 21:00:00+ | 26.96 MSFT | 1 | 2004-12-20 21:00:00+ | 26.95 MSFT | 1 | 2004-12-21 21:00:00+ | 27.07 MSFT | 1 | 2004-12-22 21:00:00+ | 26.98 MSFT | 1 | 2004-12-23 21:00:00+ | 27.01 MSFT | 1 | 2004-12-27 21:00:00+ | 26.85 MSFT | 1 | 2004-12-28 21:00:00+ | 26.95 MSFT | 1 | 2004-12-29 21:00:00+ | 26.9 MSFT | 1 | 2004-12-30 21:00:00+ | 26.76 (11 rows) The result is obviously wrong. If I run this query: cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp ='2004-12-16 16:00:00-0500'; tag | group | timestamp | value -+---+---+--- (0 rows) In DevCenter I tried to create a similar table and insert a few rows but couldn't reproduce this. This may have something to do with the bulk loading process. But still, the fact cqlsh returns data that doesn't match the query is concerning. > After bulk loading CQL query on timestamp column returns wrong result > - > > Key: CASSANDRA-10583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10583 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Datastax Community Edition 2.1.10, Windows 2008 R2, Java > x64 1.8.0_60 >Reporter: Kai Wang > Fix For: 3.x, 2.1.x, 2.2.x > > > I have this table: > {noformat} > CREATE TABLE test ( > tag text, > group int, > timestamp timestamp, > value double, > PRIMARY KEY (tag, group, timestamp) > ) WITH CLUSTERING ORDER BY (group ASC, timestamp DESC) > {noformat} > First I used CQLSSTableWriter to bulk load a bunch of sstables. Then I ran > this query: > {noformat} > cqlsh> select * from test where tag = 'MSFT' and group = 1 and timestamp > ='2004-12-15 16:00:00-0500'; > tag | group | timestamp| value > --+---+--+--- > MSFT | 1 | 2004-12-15 21:00:00+ | 27.11 > MSFT | 1 | 2004-12-16 21:00:00+ | 27.16 > MSFT | 1 | 2004-12-17 21:00:00+ | 26.96 > MSFT | 1 | 2004-12-20 21:00:00+ | 26.95 > MSFT | 1 | 2004-12-21 21:00:00+ | 27.07 > MSFT | 1 | 2004-12-22 21:00:00+ | 26.98 > MSFT | 1 | 2004-12-23 21:00:00+ | 27.01 > MSFT | 1 | 2004-12-27 21:00:00+ | 26.85 > MSFT | 1 | 2004-12-28 21:00:00+ | 26.95 > MSFT | 1 | 2004-12-29 21:00:00+ | 26.9 > MSFT | 1 | 2004-12-30
[jira] [Commented] (CASSANDRA-10444) Create an option to forcibly disable tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971494#comment-14971494 ] Jonathan Ellis commented on CASSANDRA-10444: Really a subset of CASSANDRA-8303 but I suppose we could special case it for old versions. > Create an option to forcibly disable tracing > > > Key: CASSANDRA-10444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10444 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Priority: Minor > Fix For: 2.1.x > > > Sometimes people will experience dropped TRACE messages. Ostensibly, trace > is disabled on the server and we know it's from some client, somewhere. With > an inability to locate exactly where client code is causing this, it would be > useful to just be able to kill it entirely on the server side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: cassandra-10585.patch Description: SSTablePerReadHistogram metric now not considers case when row has been read from row cache. And so, this metric will have big values even almost all requests processed by row cache (and without touching SSTables, of course). So, it seems that correct behavior is to consider that if we read row from row cache then we read zero SSTables by this request. The patch at the attachment. was: SSTablePerReadHistogram metric now not considers case when row has been read from row cache. And so, this metric will have big values even almost all requests processed by row cache (and without touching SSTables, of course). So, it seems that correct behavior is to consider that if we read row from row cache then we read zero SSTables by this request. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x > > Attachments: cassandra-10585.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971574#comment-14971574 ] Sergio Bossa commented on CASSANDRA-9318: - bq. The whole point of this ticket is to avoid the complexity of intra-node backpressure, and instead basing coordinator -> client backpressure on the coordinator's local knowledge. Just to be clear, my proposal _does_ keep the back-pressure decision local to the coordinator, that is, there's no communication between nodes in such regard (which I agree would be a much different matter). The difference in my proposal is that we deal with back-pressure on a per-replica basis and in a fine grained way, rather than with coarse grained global memory limits which would end up flooding replicas before being triggered. > Bound the number of in-flight requests at the coordinator > - > > Key: CASSANDRA-9318 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9318 > Project: Cassandra > Issue Type: Improvement >Reporter: Ariel Weisberg >Assignee: Jacek Lewandowski > Fix For: 2.1.x, 2.2.x > > > It's possible to somewhat bound the amount of load accepted into the cluster > by bounding the number of in-flight requests and request bytes. > An implementation might do something like track the number of outstanding > bytes and requests and if it reaches a high watermark disable read on client > connections until it goes back below some low watermark. > Need to make sure that disabling read on the client connection won't > introduce other issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10285) Compaction running indefinitely on system.hints
[ https://issues.apache.org/jira/browse/CASSANDRA-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970666#comment-14970666 ] Marcus Eriksson commented on CASSANDRA-10285: - ping [~aboudreault] > Compaction running indefinitely on system.hints > > > Key: CASSANDRA-10285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10285 > Project: Cassandra > Issue Type: Bug >Reporter: Alan Boudreault >Assignee: Marcus Eriksson > > During my hints storage benchmarks, I've experienced an issue using C* 2.2. > The hints was never replayed. After a while (more than 24H ...), I noticed > that there were still compactions running on system.hints and that some new > ones was triggered every 10-20 minutes. > To reproduce, we create a cluster of 2 nodes. RF=2 and we generate hints by > shutting down the node2. > {code} > ccm create --install-dir=`pwd` -n 2 local && ccm start > ccm node1 stress -- write n=50M -rate threads=300 -port jmx=7198 -errors > ignore -schema replication\(factor=2\) > # wait 5-6 seconds to get the schema creation propagated on all nodes, then > in another window, stop node 2 > ccm node2 stop > # wait the initial 50M writes are finished, bring back node2 up and write > another 50M keys. > ccm node2 start > ccm node1 stress -- write n=50M -rate threads=300 -port jmx=7198 -errors > ignore -schema replication\(factor=2\) > # You should get the initial compaction finished after 15-20 minutes. You can > set the mb throughput to 0 to get that done faster. > # Monitor the node1. the hints will never be replayed and you should see > compactions happening indefinitely. > {code} > //cc [~krummas] [~yukim] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9363) Expose vnode to directory assignment
[ https://issues.apache.org/jira/browse/CASSANDRA-9363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-9363: --- Fix Version/s: (was: 3.x) > Expose vnode to directory assignment > > > Key: CASSANDRA-9363 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9363 > Project: Cassandra > Issue Type: Improvement >Reporter: Nick Bailey >Assignee: Marcus Eriksson > > CASSANDRA-6696 adds the feature of pinning vnodes to specific disks to > improve things when JBOD is being used. > We also need a way to introspect what vnodes are assigned where. I'm not sure > what the easiest/best way to expose that info is. JMX/manifest file/system > table could all be a valid option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-9363) Expose vnode to directory assignment
[ https://issues.apache.org/jira/browse/CASSANDRA-9363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson resolved CASSANDRA-9363. Resolution: Duplicate Doing this as part of CASSANDRA-10540 (a jmx call will give you a directory to vnode mapping) > Expose vnode to directory assignment > > > Key: CASSANDRA-9363 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9363 > Project: Cassandra > Issue Type: Improvement >Reporter: Nick Bailey >Assignee: Marcus Eriksson > Fix For: 3.x > > > CASSANDRA-6696 adds the feature of pinning vnodes to specific disks to > improve things when JBOD is being used. > We also need a way to introspect what vnodes are assigned where. I'm not sure > what the easiest/best way to expose that info is. JMX/manifest file/system > table could all be a valid option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10497) NPE on removeUnfinishedCompactionLeftovers after sstablesplit
[ https://issues.apache.org/jira/browse/CASSANDRA-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson resolved CASSANDRA-10497. - Resolution: Duplicate Fix Version/s: (was: 2.1.x) this will be fixed by CASSANDRA-10501 > NPE on removeUnfinishedCompactionLeftovers after sstablesplit > - > > Key: CASSANDRA-10497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10497 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools > Environment: Ubuntu 14.04 >Reporter: Robbie Strickland >Assignee: Marcus Eriksson > Attachments: npe_system.log > > > After stopping the node and running {{sstablesplit}} on a single table, > restarting Cassandra results in an NPE: > {noformat} > INFO [SSTableBatchOpen:2] 2015-10-09 13:15:38,745 SSTableReader.java:471 - > Opening > /var/lib/cassandra/xvdd/data/system/schema_keyspaces-b0f2235744583cdb9631c43e59ce3676/system-schema_keyspaces-ka-514 > (175 bytes) > INFO [main] 2015-10-09 13:15:38,747 AutoSavingCache.java:146 - reading saved > cache > /var/lib/cassandra/xvdb/cache/system-schema_keyspaces-b0f2235744583cdb9631c43e59ce3676-KeyCache-b.db > ERROR [main] 2015-10-09 13:15:39,114 CassandraDaemon.java:541 - Exception > encountered during startup > org.apache.cassandra.io.FSReadError: java.lang.NullPointerException > at > org.apache.cassandra.db.ColumnFamilyStore.removeUnfinishedCompactionLeftovers(ColumnFamilyStore.java:641) > ~[apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT] > at > org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:302) > [apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT] > at > org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:524) > [apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT] > at > org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:613) > [apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT] > Caused by: java.lang.NullPointerException: null > at > org.apache.cassandra.db.ColumnFamilyStore.removeUnfinishedCompactionLeftovers(ColumnFamilyStore.java:633) > ~[apache-cassandra-2.1.7-SNAPSHOT.jar:2.1.7-SNAPSHOT] > ... 3 common frames omitted > {noformat} > The node would only come back up after deleting all the files in > compactions_in_progress. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[06/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/013ce885 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/013ce885 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/013ce885 Branch: refs/heads/cassandra-2.2 Commit: 013ce88512af839800597d1adc52689679a725a3 Parents: a5053fd 34b8d8f Author: Joshua McKenzieAuthored: Fri Oct 23 13:58:59 2015 -0400 Committer: Joshua McKenzie Committed: Fri Oct 23 13:58:59 2015 -0400 -- pylib/cqlshlib/test/run_cqlsh.py | 2 +- pylib/cqlshlib/test/test_cqlsh_output.py | 10 +- 2 files changed, 6 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/013ce885/pylib/cqlshlib/test/run_cqlsh.py -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/013ce885/pylib/cqlshlib/test/test_cqlsh_output.py --
[03/10] cassandra git commit: Make cqlsh tests work when authentication is configured
Make cqlsh tests work when authentication is configured Patch by stefania; reviewed by aholmberg for CASSANDRA-10544 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/34b8d8fc Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/34b8d8fc Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/34b8d8fc Branch: refs/heads/cassandra-3.0 Commit: 34b8d8fcbf528f21ac7869685e33214af381265c Parents: 5a1d376 Author: Stefania AlborghettiAuthored: Fri Oct 23 13:58:19 2015 -0400 Committer: Joshua McKenzie Committed: Fri Oct 23 13:58:19 2015 -0400 -- pylib/cqlshlib/test/run_cqlsh.py | 2 +- pylib/cqlshlib/test/test_cqlsh_output.py | 10 +- 2 files changed, 6 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/34b8d8fc/pylib/cqlshlib/test/run_cqlsh.py -- diff --git a/pylib/cqlshlib/test/run_cqlsh.py b/pylib/cqlshlib/test/run_cqlsh.py index 88b0ca6..cc929e1 100644 --- a/pylib/cqlshlib/test/run_cqlsh.py +++ b/pylib/cqlshlib/test/run_cqlsh.py @@ -27,7 +27,7 @@ import math from time import time from . import basecase -DEFAULT_CQLSH_PROMPT = '\ncqlsh(:\S+)?> ' +DEFAULT_CQLSH_PROMPT = os.linesep + '(\S+@)?cqlsh(:\S+)?> ' DEFAULT_CQLSH_TERM = 'xterm' cqlshlog = basecase.cqlshlog http://git-wip-us.apache.org/repos/asf/cassandra/blob/34b8d8fc/pylib/cqlshlib/test/test_cqlsh_output.py -- diff --git a/pylib/cqlshlib/test/test_cqlsh_output.py b/pylib/cqlshlib/test/test_cqlsh_output.py index 64950e2..e3af8e8 100644 --- a/pylib/cqlshlib/test/test_cqlsh_output.py +++ b/pylib/cqlshlib/test/test_cqlsh_output.py @@ -522,26 +522,26 @@ class TestCqlshOutput(BaseTestCase): def test_prompt(self): with testrun_cqlsh(tty=True, keyspace=None, cqlver=cqlsh.DEFAULT_CQLVER) as c: -self.assertEqual(c.output_header.splitlines()[-1], 'cqlsh> ') +self.assertTrue(c.output_header.splitlines()[-1].endswith('cqlsh> ')) c.send('\n') output = c.read_to_next_prompt().replace('\r\n', '\n') -self.assertEqual(output, '\ncqlsh> ') +self.assertTrue(output.endswith('cqlsh> ')) cmd = "USE \"%s\";\n" % get_test_keyspace().replace('"', '""') c.send(cmd) output = c.read_to_next_prompt().replace('\r\n', '\n') -self.assertEqual(output, '%scqlsh:%s> ' % (cmd, get_test_keyspace())) +self.assertTrue(output.endswith('cqlsh:%s> ' % (get_test_keyspace( c.send('use system;\n') output = c.read_to_next_prompt().replace('\r\n', '\n') -self.assertEqual(output, 'use system;\ncqlsh:system> ') +self.assertTrue(output.endswith('cqlsh:system> ')) c.send('use NONEXISTENTKEYSPACE;\n') outputlines = c.read_to_next_prompt().splitlines() self.assertEqual(outputlines[0], 'use NONEXISTENTKEYSPACE;') -self.assertEqual(outputlines[2], 'cqlsh:system> ') +self.assertTrue(outputlines[2].endswith('cqlsh:system> ')) midline = ColoredText(outputlines[1]) self.assertEqual(midline.plain(), 'InvalidRequest: code=2200 [Invalid query] message="Keyspace \'nonexistentkeyspace\' does not exist"')
[07/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/013ce885 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/013ce885 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/013ce885 Branch: refs/heads/trunk Commit: 013ce88512af839800597d1adc52689679a725a3 Parents: a5053fd 34b8d8f Author: Joshua McKenzieAuthored: Fri Oct 23 13:58:59 2015 -0400 Committer: Joshua McKenzie Committed: Fri Oct 23 13:58:59 2015 -0400 -- pylib/cqlshlib/test/run_cqlsh.py | 2 +- pylib/cqlshlib/test/test_cqlsh_output.py | 10 +- 2 files changed, 6 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/013ce885/pylib/cqlshlib/test/run_cqlsh.py -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/013ce885/pylib/cqlshlib/test/test_cqlsh_output.py --
[jira] [Updated] (CASSANDRA-10446) Run repair with down replicas
[ https://issues.apache.org/jira/browse/CASSANDRA-10446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-10446: --- Fix Version/s: 3.x > Run repair with down replicas > - > > Key: CASSANDRA-10446 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10446 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Priority: Minor > Fix For: 3.x > > > We should have an option of running repair when replicas are down. We can > call it -force. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
Ivan Burmistrov created CASSANDRA-10585: --- Summary: SSTablesPerReadHistogram seems wrong when row cache hit happend Key: CASSANDRA-10585 URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 Project: Cassandra Issue Type: Bug Components: Core Reporter: Ivan Burmistrov Priority: Minor Fix For: 2.1.x SSTablePerReadHistogram metric now not considers case when row has been read from row cache. And so, this metric will have big values even almost all requests processed by row cache (and without touching SSTables, of course). So, it seems that correct behavior is to consider that if we read row from row cache then we read zero SSTables by this request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10564) AntiCompactionTest failed on cassandra 2.1.10 due to antiCompactionSizeTest method failed on s390x
[ https://issues.apache.org/jira/browse/CASSANDRA-10564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-10564. --- Resolution: Invalid Fix Version/s: (was: 2.1.10) systemz is unfortunately not an officially supported platform for Cassandra, sorry. Feel free to reopen if you have a patch ready, and we might commit it, assuming it causes no performance degradations on x86. Otherwise, there is simply no way for us to reproduce - we don't have the hardware to. > AntiCompactionTest failed on cassandra 2.1.10 due to antiCompactionSizeTest > method failed on s390x > -- > > Key: CASSANDRA-10564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10564 > Project: Cassandra > Issue Type: Bug > Components: Tests > Environment: s390x - RHEL7 IBM systemz >Reporter: Meerabo Shah >Priority: Blocker > > testlist: > [echo] running test bucket 0 tests > [junit] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 > [junit] Testsuite: org.apache.cassandra.db.compaction.AntiCompactionTest > [junit] Testsuite: org.apache.cassandra.db.compaction.AntiCompactionTest > [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 > sec > [junit] > [junit] Testcase: > org.apache.cassandra.db.compaction.AntiCompactionTest:antiCompactionSizeTest: > Caused an ERROR > [junit] Timeout occurred. Please note the time in the report does not > reflect the time until the timeout. > [junit] junit.framework.AssertionFailedError: Timeout occurred. Please > note the time in the report does not reflect the time until the timeout. > [junit] at java.lang.Thread.run(Thread.java:745) > [junit] > [junit] > [junit] Test org.apache.cassandra.db.compaction.AntiCompactionTest FAILED > (timeout) > [junitreport] Processing > /apache-cassandra-2.1.10-src/build/test/TESTS-TestSuites.xml to > /tmp/null155310269 > [junitreport] Loading stylesheet > jar:file:/apache-ant-1.9.2/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl > [junitreport] Transform time: 1421ms > [junitreport] Deleting: /tmp/null155310269 > BUILD FAILED > /apache-cassandra-2.1.10-src/build.xml:1146: Some test bucket 0 test(s) > failed. > Total time: 1 minute 11 seconds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8586) support millions of sstables by lazily acquiring/caching/dropping filehandles
[ https://issues.apache.org/jira/browse/CASSANDRA-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8586: - Assignee: (was: Aleksey Yeschenko) > support millions of sstables by lazily acquiring/caching/dropping filehandles > - > > Key: CASSANDRA-8586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8586 > Project: Cassandra > Issue Type: New Feature >Reporter: Tupshin Harper > Labels: dense-storage > Fix For: 3.x > > > This might turn into a meta ticket if other obstacles are found in the goal > of supporting a huge number of sstables. > Technically, the only gap that I know of to prevent us from supporting absurd > numbers of sstables is the fact that we hold on to an open filehandle for > every single sstable. > For use cases that are willing to take a hit to read-performance in order to > achieve high densities and low write amplification, a mechanism for only > retaining file handles for recently read sstables could be very valuable. > This will allow for alternate compaction strategies and compaction strategy > tuning that don't try to optimize for read performance as aggresively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9836) Allow comments on CQL table columns
[ https://issues.apache.org/jira/browse/CASSANDRA-9836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9836: - Assignee: (was: Aleksey Yeschenko) > Allow comments on CQL table columns > --- > > Key: CASSANDRA-9836 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9836 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Priority: Minor > Fix For: 3.x > > > We have a _comment_ option for tables. Having such a comment on individual > columns (as many other databases have) would be nice especially when > executing a {{DESCRIBE TABLE foo}}. > Further, we could add comments in the same way for UDTs and UDT fields. > Also for UDFs, UDAs and MVs (maybe not on the MV columns individually). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10576) Thrift CAS on static columns doesn't work as expected
[ https://issues.apache.org/jira/browse/CASSANDRA-10576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971047#comment-14971047 ] Sam Tunnicliffe edited comment on CASSANDRA-10576 at 10/23/15 2:12 PM: --- This wasn't covered by the existing dtest, so I've refactored & extended it to cover static/dynamic/mixed CFs [here|https://github.com/riptano/cassandra-dtest/pull/626] {{thrift_tests:TestMutations.test_cas}} fails against cassandra-3.0/trunk but with the changes in the linked branches, it's now passing. ||3.0||trunk|| |[branch|https://github.com/beobal/cassandra/tree/10576-3.0]|[branch|https://github.com/beobal/cassandra/tree/10576-trunk]| |[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-trunk-testall/]| |[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-3.0-dtest/]|[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-trunk-dtest/]| was (Author: beobal): This wasn't covered by the existing dtest, so I've refactored & extended it to cover static/dynamic/mixed CFs [here:https://github.com/riptano/cassandra-dtest/pull/626] {{thrift_tests:TestMutations.test_cas}} fails against cassandra-3.0/trunk but with the changes in the linked branches, it's now passing. ||3.0||trunk|| |[branch|https://github.com/beobal/cassandra/tree/10576-3.0]|[branch|https://github.com/beobal/cassandra/tree/10576-trunk]| |[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-trunk-testall/]| |[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-3.0-dtest/]|[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10576-trunk-dtest/]| > Thrift CAS on static columns doesn't work as expected > - > > Key: CASSANDRA-10576 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10576 > Project: Cassandra > Issue Type: Bug >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe > Fix For: 3.0.0 > > > Although the thrift cas call works as expected for dynamic column families, > using it on tables with statically defined columns produces unexpected > results. The problem, in {{ThriftCASRequest}}, is that while the {{expected}} > partition contains a static row, the {{current}} partition has been processed > by {{ThriftResultsMerger}} during the read, converting the static columns to > clusterings. If {{expected}} contains only a static row, no further checking > is carried out, {{appliesTo}} erroneously returns true and the conditional > update is performed regardless of the current state of the partition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10059) Test Coverage for AbstractBTreePartition and hierarchy
[ https://issues.apache.org/jira/browse/CASSANDRA-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-10059: - Assignee: (was: Benedict) > Test Coverage for AbstractBTreePartition and hierarchy > -- > > Key: CASSANDRA-10059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10059 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benedict > Fix For: 3.0.x > > > Follow up to CASSANDRA-9932. The test coverage for AbstractBTreePartition and > its hierarchy is entirely indirect. That is not to say it is not covered, but > we may have some unexplored behaviour. Coverage for BTree is also missing > around a couple of edges, and the gaps should be filled in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8956) Deprecate SSTableSimpleWriter, SSTableImport, and SSTableExport in 2.1
[ https://issues.apache.org/jira/browse/CASSANDRA-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8956: - Assignee: (was: Aleksey Yeschenko) > Deprecate SSTableSimpleWriter, SSTableImport, and SSTableExport in 2.1 > -- > > Key: CASSANDRA-8956 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8956 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksey Yeschenko >Priority: Minor > Labels: docs-impacting > Fix For: 2.1.x > > > SSTableSimpleWriter doesn't make much sense in post CASSANDRA-8099 world, and > will be removed in 3.0. > To do that we should deprecate it in 2.1 first, however. > Same goes for both SSTableImport and SSTableExport - we should deprecate them > in 2.1.4, and eventually replace with CASSANDRA-7464 in 3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8589) Reconciliation in presence of tombstone might yield state data
[ https://issues.apache.org/jira/browse/CASSANDRA-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8589: - Fix Version/s: (was: 3.x) 3.1 > Reconciliation in presence of tombstone might yield state data > -- > > Key: CASSANDRA-8589 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8589 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne > Fix For: 3.1 > > > Consider 3 replica A, B, C (so RF=3) and consider that we do the following > sequence of actions at {{QUORUM}} where I indicate the replicas acknowledging > each operation (and let's assume that a replica that don't ack is a replica > that don't get the update): > {noformat} > CREATE TABLE test (k text, t int, v int, PRIMARY KEY (k, t)) > INSERT INTO test(k, t, v) VALUES ('k', 0, 0); // acked by A, B and C > INSERT INTO test(k, t, v) VALUES ('k', 1, 1); // acked by A, B and C > INSERT INTO test(k, t, v) VALUES ('k', 2, 2); // acked by A, B and C > DELETE FROM test WHERE k='k' AND t=1; // acked by A and C > UPDATE test SET v = 3 WHERE k='k' AND t=2;// acked by B and C > SELECT * FROM test WHERE k='k' LIMIT 2; // answered by A and B > {noformat} > Every operation has achieved quorum, but on the last read, A will respond > {{0->0, tombstone 1, 2->2}} and B will respond {{0->0, 1->1}}. As a > consequence we'll answer {{0->0, 2->2}} which is incorrect (we should respond > {{0->0, 2->3}}). > Put another way, if we have a limit, every replica honors that limit but > since tombstones can "suppress" results from other nodes, we may have some > cells for which we actually don't get a quorum of response (even though we > globally have a quorum of replica responses). > In practice, this probably occurs rather rarely and so the "simpler" fix is > probably to do something similar to the "short reads protection": detect when > this could have happen (based on how replica response are reconciled) and do > an additional request in that case. That detection will have potential false > positives but I suspect we can be precise enough that those false positives > will be very very rare (we should nonetheless track how often this code gets > triggered and if we see that it's more often than we think, we could > pro-actively bump user limits internally to reduce those occurrences). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8655) Exception on upgrade to trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8655: - Fix Version/s: (was: 3.x) 3.0.0 > Exception on upgrade to trunk > - > > Key: CASSANDRA-8655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8655 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson > Fix For: 3.0.0 > > > The dtest > upgrade_through_versions_test.TestUpgrade_from_cassandra_2_1_latest_tag_to_trunk_HEAD.upgrade_test_mixed > is failing with the following exception: > {code} > ERROR [Thread-10] 2015-01-20 14:12:44,117 CassandraDaemon.java:170 - > Exception in thread Thread[Thread-10,5,main] > java.lang.NullPointerException: null > at > org.apache.cassandra.db.SliceFromReadCommandSerializer.deserialize(SliceFromReadCommand.java:153) > ~[main/:na] > at > org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:157) > ~[main/:na] > at > org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:131) > ~[main/:na] > at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:168) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:150) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:82) > ~[main/:na] > {code} > It is trying to execute a simple "SELECT k,v FROM cf WHERE k=X" query on a > trunk node after upgrading from 2.1-HEAD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9357) LongSharedExecutorPoolTest.testPromptnessOfExecution fails in 2.1
[ https://issues.apache.org/jira/browse/CASSANDRA-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9357: - Fix Version/s: (was: 2.2.x) (was: 2.1.x) (was: 3.x) 3.1 > LongSharedExecutorPoolTest.testPromptnessOfExecution fails in 2.1 > - > > Key: CASSANDRA-9357 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9357 > Project: Cassandra > Issue Type: Bug > Components: Tests >Reporter: Michael Shuler > Fix For: 3.1 > > Attachments: system.log > > > {noformat} > [junit] Testsuite: > org.apache.cassandra.concurrent.LongSharedExecutorPoolTest > [junit] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: > 1.353 sec > [junit] > [junit] - Standard Output --- > [junit] Completed 0K batches with 0.0M events > [junit] Running for 120s with load multiplier 0.5 > [junit] - --- > [junit] Testcase: > testPromptnessOfExecution(org.apache.cassandra.concurrent.LongSharedExecutorPoolTest): > FAILED > [junit] null > [junit] junit.framework.AssertionFailedError > [junit] at > org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:215) > [junit] at > org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:104) > [junit] > [junit] > [junit] Test org.apache.cassandra.concurrent.LongSharedExecutorPoolTest > FAILED > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10059) Test Coverage for AbstractBTreePartition and hierarchy
[ https://issues.apache.org/jira/browse/CASSANDRA-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10059: -- Issue Type: Test (was: Bug) > Test Coverage for AbstractBTreePartition and hierarchy > -- > > Key: CASSANDRA-10059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10059 > Project: Cassandra > Issue Type: Test > Components: Core >Reporter: Benedict > Fix For: 3.1 > > > Follow up to CASSANDRA-9932. The test coverage for AbstractBTreePartition and > its hierarchy is entirely indirect. That is not to say it is not covered, but > we may have some unexplored behaviour. Coverage for BTree is also missing > around a couple of edges, and the gaps should be filled in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10059) Test Coverage for AbstractBTreePartition and hierarchy
[ https://issues.apache.org/jira/browse/CASSANDRA-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10059: -- Fix Version/s: (was: 3.0.x) 3.1 > Test Coverage for AbstractBTreePartition and hierarchy > -- > > Key: CASSANDRA-10059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10059 > Project: Cassandra > Issue Type: Test > Components: Core >Reporter: Benedict > Fix For: 3.1 > > > Follow up to CASSANDRA-9932. The test coverage for AbstractBTreePartition and > its hierarchy is entirely indirect. That is not to say it is not covered, but > we may have some unexplored behaviour. Coverage for BTree is also missing > around a couple of edges, and the gaps should be filled in. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10134) Always require replace_address to replace existing address
[ https://issues.apache.org/jira/browse/CASSANDRA-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10134: -- Issue Type: Improvement (was: Bug) > Always require replace_address to replace existing address > -- > > Key: CASSANDRA-10134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10134 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Tyler Hobbs >Assignee: Stefania > Fix For: 3.x, 2.1.x, 2.2.x > > > Normally, when a node is started from a clean state with the same address as > an existing down node, it will fail to start with an error like this: > {noformat} > ERROR [main] 2015-08-19 15:07:51,577 CassandraDaemon.java:554 - Exception > encountered during startup > java.lang.RuntimeException: A node with address /127.0.0.3 already exists, > cancelling join. Use cassandra.replace_address if you want to replace this > node. > at > org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:543) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:783) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:720) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.initServer(StorageService.java:611) > ~[main/:na] > at > org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378) > [main/:na] > at > org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:537) > [main/:na] > at > org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:626) > [main/:na] > {noformat} > However, if {{auto_bootstrap}} is set to false or the node is in its own seed > list, it will not throw this error and will start normally. The new node > then takes over the host ID of the old node (even if the tokens are > different), and the only message you will see is a warning in the other > nodes' logs: > {noformat} > logger.warn("Changing {}'s host ID from {} to {}", endpoint, storedId, > hostId); > {noformat} > This could cause an operator to accidentally wipe out the token information > for a down node without replacing it. To fix this, we should check for an > endpoint collision even if {{auto_bootstrap}} is false or the node is a seed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10175) cassandra-stress should be tolerant when a remote node shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10175: -- Issue Type: Improvement (was: Bug) > cassandra-stress should be tolerant when a remote node shutdown > > > Key: CASSANDRA-10175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10175 > Project: Cassandra > Issue Type: Improvement >Reporter: Alan Boudreault > Fix For: 3.x > > > Currently, if we start a stress session with 3 nodes and shutdown one node, > stress will crash. It is caused by the JMX connection lost on the node, which > is use to collect some gc stats IIRC. > backtrace: https://gist.github.com/aboudreault/6cd82bb0acc681992414 > Stress should handle that jmx connection lost in a better way so the session > could continue. Ideally, it should try to *reconnect* to JMX if the node is > back online? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10246) Named values don't work with batches
[ https://issues.apache.org/jira/browse/CASSANDRA-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10246: -- Fix Version/s: (was: 3.0.x) 3.1 > Named values don't work with batches > > > Key: CASSANDRA-10246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10246 > Project: Cassandra > Issue Type: Bug > Components: API >Reporter: Michael Penick > Labels: client-impacting > Fix For: 2.1.x, 2.2.x, 3.1 > > > This is broken at the protocol-level and in the implementation. > At the protocol-level the {{}} component of the batch comes after the > queries. That means the protocol parser would need to read ahead (and back > track) to determine the values encoding and correctly read the values from > the query entries. Also, a batch-level setting for named values forces all > queries to use the same encoding. Should batches force a single, homogenous > query value encoding? (This is confusing) > In the implementation, values are indiscriminately read using > {{CBUtil.readValueList()}}, and the batch flags are never checked (for > {{(Flag.NAMES_FOR_VALUES}}) to see if {{CBUtil.readNameAndValueList()}} > should be called instead: > https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/transport/messages/BatchMessage.java#L64 > Proposed solution: CASSANDRA-10247 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal
[ https://issues.apache.org/jira/browse/CASSANDRA-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10089: -- Fix Version/s: (was: 3.0.x) 3.1 > NullPointerException in Gossip handleStateNormal > > > Key: CASSANDRA-10089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10089 > Project: Cassandra > Issue Type: Bug >Reporter: Stefania >Assignee: Stefania > Fix For: 2.1.x, 2.2.x, 3.1 > > Attachments: node1_debug.log, node2_debug.log, node3_debug.log > > > Whilst comparing dtests for CASSANDRA-9970 I found [this failing > dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/] > in 2.2: > {code} > Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14 > 15:39:57,873 CassandraDaemon.java:183 - Exception in thread > Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat > org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731) > ~[main/:na] \tat > org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804) > ~[main/:na] \tat > org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857) > ~[main/:na] \tat > org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629) > ~[main/:na] \tat > org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312) > ~[main/:na] \tat > org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025) > ~[main/:na] \tat > org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106) > ~[main/:na] \tat > org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49) > ~[main/:na] \tat > org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66) > ~[main/:na] \tat > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > ~[na:1.7.0_80] \tat > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > ~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]'] > {code} > I wasn't able to find it on unpatched branches but it is clearly not related > to CASSANDRA-9970, if anything it could have been a side effect of > CASSANDRA-9871. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10474) Streaming should tolerate secondary index build failure
[ https://issues.apache.org/jira/browse/CASSANDRA-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10474: -- Fix Version/s: (was: 3.0.x) 3.1 > Streaming should tolerate secondary index build failure > --- > > Key: CASSANDRA-10474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10474 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita > Labels: streaming > Fix For: 2.1.x, 2.2.x, 3.1 > > > When streaming failed to build secondary index at the end of streaming (like > in CASSANDRA-10449), streaming session can hang as it throws exception > without catching it. > Streaming should tolerate secondary index build failure, and instead of > failing (hanging) streaming session, it should WARN user and go on. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10422) Avoid anticompaction when doing subrange repair
[ https://issues.apache.org/jira/browse/CASSANDRA-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10422: -- Fix Version/s: (was: 3.x) 3.1 > Avoid anticompaction when doing subrange repair > --- > > Key: CASSANDRA-10422 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10422 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson > Fix For: 2.1.x, 2.2.x, 3.1 > > > If we do split the owned range in say 1000 parts, and then do one repair > each, we could potentially anticompact every sstable 1000 times (ie, we > anticompact the repaired range out 1000 times). We should avoid > anticompacting at all in these cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5261) Remove token generator
[ https://issues.apache.org/jira/browse/CASSANDRA-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5261: - Fix Version/s: (was: 3.x) 3.0.0 > Remove token generator > -- > > Key: CASSANDRA-5261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5261 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jonathan Ellis >Priority: Minor > Labels: triaged > Fix For: 3.0.0 > > > Obsoleted by vnodes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10580) When mutations are dropped, the column family should be printed / have a counter per column family
Anubhav Kale created CASSANDRA-10580: Summary: When mutations are dropped, the column family should be printed / have a counter per column family Key: CASSANDRA-10580 URL: https://issues.apache.org/jira/browse/CASSANDRA-10580 Project: Cassandra Issue Type: New Feature Components: Core Environment: Production Reporter: Anubhav Kale Priority: Minor Fix For: 2.1.x In our production cluster, we are seeing a large number of dropped mutations. It would be really helpful to see which column families are really affected by this (either through logs or through a dedicated counter for every column family). I have made a hack in StorageProxy (below) to help us with this. I am happy to extend this to a better solution (print the CF affected in as logger.debug and then manually grep) if experts agree this additional detail would be helpful in general. Any other suggestions are welcome. private static abstract class LocalMutationRunnable implements Runnable { private final long constructionTime = System.currentTimeMillis(); private IMutation mutation; public final void run() { if (System.currentTimeMillis() > constructionTime + 2000L) { long timeTaken = System.currentTimeMillis() - constructionTime; logger.warn("Anubhav LocalMutationRunnable thread ran after " + timeTaken); try { for(ColumnFamily family : this.mutation.getColumnFamilies()) { if (family.toString().toLowerCase().contains("udsuserdailysnapshot")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.USERDAILY); } else if (family.toString().toLowerCase().contains("udsuserhourlysnapshot")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.USERHOURLY); } else if (family.toString().toLowerCase().contains("udstenantdailysnapshot")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.TENANTDAILY); } else if (family.toString().toLowerCase().contains("udstenanthourlysnapshot")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.TENANTHOURLY); } else if (family.toString().toLowerCase().contains("userdatasetraw")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.USERDSRAW); } else if (family.toString().toLowerCase().contains("tenants")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.TENANTS); } else if (family.toString().toLowerCase().contains("users")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.USERS); } else if (family.toString().toLowerCase().contains("tenantactivity")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.TENANTACTIVITY); } else if (family.getKeySpaceName().toLowerCase().contains("system")) { MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.SYSTEMKS); } else { logger.warn("Anubhav LocalMutationRunnable updating mutations for " + family.toString().toLowerCase()); MessagingService.instance().incrementDroppedMessages(MessagingService.Verb.OTHERTBL); } } } catch (Exception e) { logger.error("Anubhav LocalMutationRunnable Exception ", e); }
[jira] [Updated] (CASSANDRA-10096) SerializationHelper should provide a rewindable in-order tester
[ https://issues.apache.org/jira/browse/CASSANDRA-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10096: -- Issue Type: Improvement (was: Bug) > SerializationHelper should provide a rewindable in-order tester > --- > > Key: CASSANDRA-10096 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10096 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Priority: Minor > Fix For: 3.x > > > When deserializing a row we perform a logarithmic lookup on column name for > every cell. There is also a lot of unnecessary indirection to reach this > method call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9223) ArithmeticException after decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-9223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9223: - Fix Version/s: (was: 3.x) 3.1 > ArithmeticException after decommission > -- > > Key: CASSANDRA-9223 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9223 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Priority: Minor > Fix For: 3.1 > > > Also seen on trunk while working on CASSANDRA-8072: > {noformat} > ERROR 19:21:33 Exception in thread Thread[BatchlogTasks:1,5,main] > java.lang.ArithmeticException: / by zero > at > org.apache.cassandra.db.BatchlogManager.replayAllFailedBatches(BatchlogManager.java:173) > ~[main/:na] > at > org.apache.cassandra.db.BatchlogManager.access$000(BatchlogManager.java:61) > ~[main/:na] > at > org.apache.cassandra.db.BatchlogManager$1.runMayThrow(BatchlogManager.java:91) > ~[main/:na] > at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > ~[main/:na] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:82) > ~[main/:na] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > [na:1.7.0_76] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) > [na:1.7.0_76] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) > [na:1.7.0_76] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > [na:1.7.0_76] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [na:1.7.0_76] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [na:1.7.0_76] > at java.lang.Thread.run(Thread.java:745) [na:1.7.0_76] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10179) Duplicate index should throw AlreadyExistsException
[ https://issues.apache.org/jira/browse/CASSANDRA-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10179: -- Issue Type: Improvement (was: Bug) > Duplicate index should throw AlreadyExistsException > --- > > Key: CASSANDRA-10179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10179 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Assignee: Sam Tunnicliffe >Priority: Minor > Fix For: 3.x > > > If a 2i already exists we currently throw a InvalidQueryException. This > should be a AlreadyExistsException for consistency like trying to create the > same CQL Table twice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10271) ORDER BY should allow skipping equality-restricted clustering columns
[ https://issues.apache.org/jira/browse/CASSANDRA-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10271: -- Issue Type: Improvement (was: Bug) > ORDER BY should allow skipping equality-restricted clustering columns > - > > Key: CASSANDRA-10271 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10271 > Project: Cassandra > Issue Type: Improvement > Components: API, Core >Reporter: Tyler Hobbs >Assignee: Brett Snyder >Priority: Minor > Fix For: 3.x, 2.2.x > > Attachments: cassandra-2.2-10271.txt > > > Given a table like the following: > {noformat} > CREATE TABLE foo (a int, b int, c int, d int, PRIMARY KEY (a, b, c)); > {noformat} > We should support a query like this: > {noformat} > SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY c ASC; > {noformat} > Currently, this results in the following error: > {noformat} > [Invalid query] message="Order by currently only support the ordering of > columns following their declared order in the PRIMARY KEY" > {noformat} > However, since {{b}} is restricted by an equality restriction, we shouldn't > require it to be present in the {{ORDER BY}} clause. > As a workaround, you can use this query instead: > {noformat} > SELECT * FROM foo WHERE a = 0 AND b = 0 ORDER BY b ASC, c ASC; > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10350) cqlsh describe keyspace output no longers keeps indexes in sorted order
[ https://issues.apache.org/jira/browse/CASSANDRA-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971240#comment-14971240 ] Aleksey Yeschenko commented on CASSANDRA-10350: --- [~aholmber] Can we fix this in the driver? > cqlsh describe keyspace output no longers keeps indexes in sorted order > --- > > Key: CASSANDRA-10350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10350 > Project: Cassandra > Issue Type: Bug >Reporter: Andrew Hust >Priority: Minor > Labels: cqlsh > Fix For: 3.1 > > > cqlsh command {{describe keyspace }} no longer keeps indexes in alpha > sorted order. This was caught with a dtest on > [cassci|http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe/]. > Tested on: C* {{b4544846def2bdd00ff841c7e3d9f2559620827b}} > Can be reproduced with the following: > {code} > ccm stop > ccm remove describe_order > ccm create -n 1 -v git:cassandra-2.2 describe_order > ccm start > cat << EOF | ccm node1 cqlsh > CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy', > 'replication_factor': 1}; > USE ks1; > CREATE TABLE ks1.test (id int, col int, val text, val2 text, val3 text, > PRIMARY KEY(id, col)); > CREATE INDEX ix0 ON ks1.test (col); > CREATE INDEX ix3 ON ks1.test (val3); > CREATE INDEX ix2 ON ks1.test (val2); > CREATE INDEX ix1 ON ks1.test (val); > DESCRIBE KEYSPACE ks1; > EOF > ccm stop > ccm setdir -v git:cassandra-3.0 > ccm start > sleep 15 > cat << EOF | ccm node1 cqlsh > DESCRIBE KEYSPACE ks1; > EOF > ccm stop > {code} > Ouput on <= cassandra-2.2: > {code} > CREATE INDEX ix0 ON ks1.test (col); > CREATE INDEX ix1 ON ks1.test (val); > CREATE INDEX ix2 ON ks1.test (val2); > CREATE INDEX ix3 ON ks1.test (val3); > {code} > Output on cassandra-3.0: > {code} > CREATE INDEX ix2 ON ks1.test (val2); > CREATE INDEX ix3 ON ks1.test (val3); > CREATE INDEX ix0 ON ks1.test (col); > CREATE INDEX ix1 ON ks1.test (val); > {code} > //CC [~enigmacurry] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10374) List and Map values incorrectly limited to 64k size
[ https://issues.apache.org/jira/browse/CASSANDRA-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10374: -- Fix Version/s: (was: 3.0.x) 3.1 > List and Map values incorrectly limited to 64k size > --- > > Key: CASSANDRA-10374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10374 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Tyler Hobbs >Assignee: Benjamin Lerer >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.1 > > > With the v3 native protocol, we switched from encoding collection element > sizes with shorts to ints. However, in {{Lists.java}} and {{Maps.java}}, we > still validate that list and map values are smaller than > {{MAX_UNSIGNED_SHORT}}. > Map keys and set elements are stored in the cell name, so they're implicitly > limited to the cell name size limit of 64k. However, for non-frozen > collections, this limitation should not apply, so we probably don't want to > perform this check here for those either. > The fix should include tests where we exceed the 64k limit for frozen and > non-frozen collections. In the case of non-frozen lists and maps, we should > verify that the 64k cell-name size limit is enforced in a friendly way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10405) MV updates should optionally wait for acknowledgement from view replicas
[ https://issues.apache.org/jira/browse/CASSANDRA-10405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-10405: --- Priority: Minor (was: Major) > MV updates should optionally wait for acknowledgement from view replicas > > > Key: CASSANDRA-10405 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10405 > Project: Cassandra > Issue Type: Improvement >Reporter: Carl Yeksigian >Priority: Minor > Labels: materializedviews > Fix For: 3.x > > > MV updates are currently completely asynchronous in order to provide > parallelism of updates trying to acquire the partition lock. For some use > cases, leaving the MV updates asynchronous is exactly what's needed. > However, there are some use cases where knowing that the update has either > succeeded or failed on the view is necessary, especially when trying to allow > read-your-write behavior. In those cases, we would follow the same code path > as asynchronous writes, but at the end wait on the acknowledgements from the > view replicas before acknowledging our write. This option should be for each > MV separately, since MVs which need the synchronous properties might be mixed > with MV which do not need this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10179) Duplicate index should throw AlreadyExistsException
[ https://issues.apache.org/jira/browse/CASSANDRA-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10179: -- Issue Type: Sub-task (was: Improvement) Parent: CASSANDRA-9362 > Duplicate index should throw AlreadyExistsException > --- > > Key: CASSANDRA-10179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10179 > Project: Cassandra > Issue Type: Sub-task >Reporter: T Jake Luciani >Assignee: Sam Tunnicliffe >Priority: Minor > Fix For: 3.x > > > If a 2i already exists we currently throw a InvalidQueryException. This > should be a AlreadyExistsException for consistency like trying to create the > same CQL Table twice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8653) Upgrading to trunk with auth throws exception
[ https://issues.apache.org/jira/browse/CASSANDRA-8653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971286#comment-14971286 ] Sam Tunnicliffe edited comment on CASSANDRA-8653 at 10/23/15 4:23 PM: -- bq. This ticket mentions trunk, but any reason to think 3.0 is immune to that? It's actually the 3.0 that the test upgrades to, or it would be except it's currently skipped (waiting on CASSANDRA-9704, so should be re-enabled). When I run locally I see no auth problems and the test completes as expected. It fails though because of an unexpected ERROR in the log of node1, which is thrown just after the last node is upgraded: {noformat} ERROR [HintsDispatcher:2] 2015-10-23 17:18:53,942 CassandraDaemon.java:195 - Exception in thread Thread[HintsDispatcher:2,1,main] java.lang.RuntimeException: java.nio.file.NoSuchFileException: /home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints at org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55) ~[main/:na] at org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66) ~[main/:na] at org.apache.cassandra.hints.ChecksummedDataInput.open(ChecksummedDataInput.java:63) ~[main/:na] at org.apache.cassandra.hints.HintsReader.open(HintsReader.java:77) ~[main/:na] at org.apache.cassandra.hints.HintsDispatcher.create(HintsDispatcher.java:71) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198) ~[main/:na] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_60] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] Caused by: java.nio.file.NoSuchFileException: /home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) ~[na:1.8.0_60] at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[na:1.8.0_60] at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[na:1.8.0_60] at sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177) ~[na:1.8.0_60] at java.nio.channels.FileChannel.open(FileChannel.java:287) ~[na:1.8.0_60] at java.nio.channels.FileChannel.open(FileChannel.java:335) ~[na:1.8.0_60] at org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:51) ~[main/:na] ... 12 common frames omitted {noformat} was (Author: beobal): b.q This ticket mentions trunk, but any reason to think 3.0 is immune to that? It's actually the 3.0 that the test upgrades to, or it would be except it's currently skipped (waiting on CASSANDRA-9704, so should be re-enabled). When I run locally I see no auth problems and the test completes as expected. It fails though because of an unexpected ERROR in the log of node1, which is thrown just after the last node is upgraded: {noformat} RROR [HintsDispatcher:2] 2015-10-23 17:18:53,942 CassandraDaemon.java:195 - Exception in thread Thread[HintsDispatcher:2,1,main] java.lang.RuntimeException: java.nio.file.NoSuchFileException: /home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints at org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55) ~[main/:na] at org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66) ~[main/:na] at org.apache.cassandra.hints.ChecksummedDataInput.open(ChecksummedDataInput.java:63) ~[main/:na] at org.apache.cassandra.hints.HintsReader.open(HintsReader.java:77) ~[main/:na] at org.apache.cassandra.hints.HintsDispatcher.create(HintsDispatcher.java:71) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198) ~[main/:na] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[jira] [Commented] (CASSANDRA-10258) Counter table written with CQLSSTableWriter generates exceptions and become corrupted at first use
[ https://issues.apache.org/jira/browse/CASSANDRA-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971292#comment-14971292 ] Aleksey Yeschenko commented on CASSANDRA-10258: --- bq. So really, the simplest and imo best solution is to add "you cannot write sstable yourself with CQLSSTableWriter" to the list of counters limitations. Basically, this. > Counter table written with CQLSSTableWriter generates exceptions and become > corrupted at first use > -- > > Key: CASSANDRA-10258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10258 > Project: Cassandra > Issue Type: Bug > Components: API > Environment: Linux Debian Wheezie 7.8 / Oracle Java 1.7.0_67 > Ubuntu 14.04.3 LTS / Oracle Java 1.7.0_75 > Cassandra 2.0.12 2.1.5 2.1.8 >Reporter: Guillaume VIEL >Assignee: Paulo Motta > Fix For: 2.1.x, 2.2.x, 3.0.x > > > We use CQLSStableWriter to produce testing datasets. > Here are the steps to reproduce this issue : > 1) definition of a table with counter > {code} > CREATE TABLE my_counter ( > my_id text, > my_counter counter, > PRIMARY KEY (my_id) > ) > {code} > 2) with CQLSSTableWriter initialize this table (about 2millions entries) with > this insert order (one insert / key only) > {{UPDATE myks.my_counter SET my_counter = my_counter + ? WHERE my_id = ?}} > 3) load the files written by CQLSSTableWriter with sstableloader in your > cassandra cluster (tested on a single node and a 3 nodes cluster) > 4) start a process that updates the counters (we used 3millions entries > distributed on the key my_id) > 5) after a while try to query a key in the my_counter table > {{cqlsh:myks> select * from my_counter where my_id='001';}} > Request did not complete within rpc_timeout. > In the logs of cassandra (2.0.12) : > {code} > ERROR [CompactionExecutor:3] 2015-05-28 15:53:39,491 CassandraDaemon.java > (line 258) Exception in thread Thread[CompactionExecutor:3,1,main] > java.lang.AssertionError: Wrong class type. > at > org.apache.cassandra.db.CounterUpdateColumn.reconcile(CounterUpdateColumn.java:70) > at > org.apache.cassandra.db.ArrayBackedSortedColumns.resolveAgainst(ArrayBackedSortedColumns.java:147) > at > org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:126) > at > org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:121) > at > org.apache.cassandra.db.compaction.PrecompactedRow$1.reduce(PrecompactedRow.java:120) > at > org.apache.cassandra.db.compaction.PrecompactedRow$1.reduce(PrecompactedRow.java:115) > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:112) > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) > at > org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:191) > at > org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:144) > at > org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:103) > at > org.apache.cassandra.db.compaction.PrecompactedRow.(PrecompactedRow.java:85) > at > org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:196) > at > org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:74) > at > org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:55) > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:115) > at > org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98) > at > com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) > at > com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) > at > org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:164) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at > org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60) > at > org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59) > at > org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198) > at >
[jira] [Updated] (CASSANDRA-9181) Improve index versus secondary index selection
[ https://issues.apache.org/jira/browse/CASSANDRA-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9181: - Issue Type: Improvement (was: Bug) > Improve index versus secondary index selection > -- > > Key: CASSANDRA-9181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9181 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremy Hanna > Labels: 2i > Fix For: 3.x > > > There is a special case for secondary indexes if you always supply the > partition key. For example, if you have a family with ID "a456" which has 6 > family members and I have a secondary index on first name. Currently, if I > do a query like this "select * from families where id = 'a456' and firstname > = 'alowishus';" you can see from a query trace, that it will first scan the > entire cluster based on the firstname, then look for the key within that. > If it's not terribly invasive, I think this would be a valid use case to > narrow down the results by key first. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9654) Failure to open sstable after upgrade to trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9654: - Fix Version/s: (was: 3.x) 3.0.0 > Failure to open sstable after upgrade to trunk > -- > > Key: CASSANDRA-9654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9654 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Philip Thompson >Assignee: Branimir Lambov > Fix For: 3.0.0 > > Attachments: node1.log, node2.log, node3.log, sstables.tar.gz > > > After upgrading a 3 node cluster on the path 1.2.19 -> 2.0.16 -> 2.1-head -> > 2.2-head -> trunk > {code} > ERROR [SSTableBatchOpen:1] 2015-06-25 17:16:55,424 SSTableReader.java:435 - > Cannot open /tmp/dtest-Ibi6zm/test/node1/data/upgrade/cf/la-7-big; > partitioner org.apache.cassandra.dht.LocalPartitioner does not match system > partitioner org.apache.cassandra.dht.Murmur3Partitioner. Note that the > default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you > will need to edit that to match your old partitioner if upgrading. > ERROR [SSTableBatchOpen:2] 2015-06-25 17:16:55,425 SSTableReader.java:435 - > Cannot open /tmp/dtest-Ibi6zm/test/node1/data/upgrade/cf/la-10-big; > partitioner org.apache.cassandra.dht.LocalPartitioner does not match system > partitioner org.apache.cassandra.dht.Murmur3Partitioner. Note that the > default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you > will need to edit that to match your old partitioner if upgrading. > {code} > Node logs are attached. > To reproduce, you'll need to run the upgrade dtest as follows: > {{nosetests -sv > upgrade_through_versions_test.py:TestUpgradeThroughVersions.upgrade_test}}. I > don't have CI results for this yet, nor will I soon. To run this, you'll need > both JDK7 and JDK8 installed, for compilation reasons. Set the env vars > JAVA7_HOME and JAVA8_HOME, respectively. I'll work on finding an sstable that > represent the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10050) Secondary Index Performance Dependent on TokenRange Searched in Analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-10050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10050: -- Issue Type: Improvement (was: Bug) > Secondary Index Performance Dependent on TokenRange Searched in Analytics > - > > Key: CASSANDRA-10050 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10050 > Project: Cassandra > Issue Type: Improvement > Components: Core > Environment: Single node, macbook, 2.1.8 >Reporter: Russell Alexander Spitzer > Fix For: 3.x > > > In doing some test work on the Spark Cassandra Connector I saw some odd > performance when pushing down range queries with Secondary Index filters. > When running the queries we see huge amount of time when the C* server is not > doing any work and the query seem to be hanging. This investigation led to > the work in this document > https://docs.google.com/spreadsheets/d/1aJg3KX7nPnY77RJ9ZT-IfaYADgJh0A--nAxItvC6hb4/edit#gid=0 > The Spark Cassandra Connector builds up token range specific queries and > allows the user to pushdown relevant fields to C*. Here we have two indexed > fields (size) and (color) being pushed down to C*. > {code} > SELECT count(*) FROM ks.tab WHERE token("store") > $min AND token("store") <= > $max AND color = 'red' AND size = 'P' ALLOW FILTERING;{code} > These queries will have different token ranges inserted and executed as > separate spark tasks. Spark tasks with token ranges near the Min(token) end > up executing much faster than those near Max(token) which also happen to > through errors. > {code} > Coordinator node timed out waiting for replica nodes' responses] > message="Operation timed out - received only 0 responses." > info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'} > {code} > I took the queries and ran them through CQLSH to see the difference in time. > A linear relationship is seen based on where the tokenRange being queried is > starting with only 2 second for queries near the beginning of the full token > spectrum and over 12 seconds at the end of the spectrum. > The question is, can this behavior be improved? or should we not recommend > using secondary indexes with Analytics workloads? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10341) Streaming does not guarantee cache invalidation
[ https://issues.apache.org/jira/browse/CASSANDRA-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10341: -- Fix Version/s: (was: 3.0.x) 3.1 > Streaming does not guarantee cache invalidation > --- > > Key: CASSANDRA-10341 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10341 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benedict >Assignee: Paulo Motta > Fix For: 2.1.x, 2.2.x, 3.1 > > > Looking at the code, we attempt to invalidate the row cache for any rows we > receive via streaming, however we invalidate them immediately, before the new > data is available. So, if it is requested (which is likely if it is "hot") in > the interval, it will be re-cached and not invalidated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10511) Index summary downsampling prevents mmap access of large files after restart
[ https://issues.apache.org/jira/browse/CASSANDRA-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10511: -- Fix Version/s: (was: 3.0.x) (was: 3.x) 3.1 > Index summary downsampling prevents mmap access of large files after restart > > > Key: CASSANDRA-10511 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10511 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benedict > Fix For: 2.1.x, 2.2.x, 3.1 > > > {{SSTableReader.cloneWithNewSummarySampleLevel}} constructs a > {{SegmentedFile.Builder}} but never populates it with any boundaries. For > files larger than 2Gb, this will result in their being accessed via buffered > io after a restart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-2986) Fix short reads in range (and index?) scans
[ https://issues.apache.org/jira/browse/CASSANDRA-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-2986: - Issue Type: Improvement (was: Bug) > Fix short reads in range (and index?) scans > --- > > Key: CASSANDRA-2986 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2986 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Assignee: Jason Brown >Priority: Minor > Fix For: 3.x > > > See CASSANDRA-2643 for the [multi]get fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8554) Node where gossip is disabled still shows as UP on that node; other nodes show it as DN
[ https://issues.apache.org/jira/browse/CASSANDRA-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-8554. -- Resolution: Cannot Reproduce Fix Version/s: (was: 3.x) > Node where gossip is disabled still shows as UP on that node; other nodes > show it as DN > > > Key: CASSANDRA-8554 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8554 > Project: Cassandra > Issue Type: Bug > Environment: Centos 6.5, DSE4.5.1 tarball install >Reporter: Mark Curtis >Priority: Minor > > When running nodetool drain, the drained node will still show the status of > itself as UP in nodetool status even after the drain has finished. For > example using a 3 node cluster on one of the nodes that is still operating > and not drained we see this: > {code} > $ ./dse-4.5.1/bin/nodetool status > Note: Ownership information does not include topology; for complete > information, specify a keyspace > Datacenter: Central > === > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- AddressLoad Tokens Owns Host ID > Rack > UN 192.168.56.21 210.78 KB 256 32.1% > 82eb2fca-4f57-467b-a972-93096ec5d69f RAC1 > DN 192.168.56.23 2.22 GB256 33.5% > a11bfac1-fad0-440b-bd68-7562a89ce3c7 RAC1 > UN 192.168.56.22 2.22 GB256 34.4% > 4250cb05-97be-4bac-887a-acc307d1bc0c RAC1 > {code} > While on the drained node we see this: > {code} > [datastax@DSE4 ~]$ ./dse-4.5.1/bin/nodetool drain > [datastax@DSE4 ~]$ ./dse-4.5.1/bin/nodetool status > Note: Ownership information does not include topology; for complete > information, specify a keyspace > Datacenter: Central > === > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- AddressLoad Tokens Owns Host ID > Rack > UN 192.168.56.21 210.78 KB 256 32.1% > 82eb2fca-4f57-467b-a972-93096ec5d69f RAC1 > UN 192.168.56.23 2.22 GB256 33.5% > a11bfac1-fad0-440b-bd68-7562a89ce3c7 RAC1 > UN 192.168.56.22 2.22 GB256 34.4% > 4250cb05-97be-4bac-887a-acc307d1bc0c RAC1 > {code} > Netstat shows outgoing connections from the drained node to other nodes as > still established on port 7000 but the node is no longer listening on port > 7000 which I believe is expected. > However the output of nodetool status on the drained node could be > interpreted as misleading. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9222) AssertionError after decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9222: - Fix Version/s: (was: 3.x) 3.1 > AssertionError after decommission > - > > Key: CASSANDRA-9222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9222 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Brandon Williams >Priority: Minor > Fix For: 3.1 > > > Saw this on trunk while working on CASSANDRA-8072, but it may affect earlier > revisions as well: > {noformat} > INFO 17:48:57 MessagingService has terminated the accept() thread > INFO 17:48:58 DECOMMISSIONED > ERROR 17:52:25 Exception in thread Thread[OptionalTasks:1,5,main] > java.lang.AssertionError: -1011553757645129692 not found in > -9212067178699207814, -9200531256183869940, -9166030381776079682, > -9162013024688602642, -9151724494713671168, -9095828490921521759, > -9035494031488373110, -8993765846966048219, -8912013107131353260, > -8909000788978186800, -8879514397454962673, -8868628980500567099, > -8850730903031889070, -8810378752213886595, -8779200870214886308, > -8758215747589442842, -8751091270073031687, -8727034084505556969, > -8665197275159395069, -8656563059526305598, -8468078121019364990, > -8465001791134178844, -8442193507205463429, -8422069069190372219, > -8342133517826612505, -8341643847610190520, -8340770353573450569, > -8337671516798157281, -8299063757464280571, -8294397037816683529, > -8190643358275415766, -8125907580996325958, -8080821167493102683, > -8058428707430264364, -8033777866368709204, -8018079744052327023, > -8005568943124488030, -7911488756902729132, -7831006227012170930, > -7824529182957931950, -7807286997402075771, -7795080548612350344, > -7778629955912441437, -7771701686959718810, -7759250335393772671, > -7745731940317799541, -7703194536911509010, -7694764467260740698, > -7691909270364954632, -7687121918922986909, -7682707339911246942, > -7517133373189921954, -7482800574078120526, -7475897243891441451, > -7334307376946940271, -7326649207653179327, -7258677281263041990, > -7221843646683358238, -7193299656451825680, -7105256682000196035, > -7035269781687029457, -7024278722443497027, -7019197046707993025, > -7015131617238216508, -7003811999522811317, -6980314778696530567, > -6966235125715836473, -691530498397662, -6912703644363131398, > -6881456879008059927, -6861265076865721267, -6850740895102395611, > -6808435504617684311, -6785202117470372844, -6782573711981746574, > -6763604807975420855, -6738443719321921481, -6718513123799422576, > -6711670508127917469, -6709012720615571304, -6645945635050443947, > -6629420613692951932, -6542209628003661283, -6535684002637060628, > -6507671461487774245, -6423206762015678338, -6409843839148310789, > -6404011469157179029, -6381904465334594648, -6311911206861962333, > -6296991709696294898, -6264931794517958640, -6261574198670386500, > -6261382604358802512, -6252257370391459113, -6241897861580419597, > -6227245701986117982, -6199525755295090433, -6180934919369759659, > -6144605078172691818, -6126223305042342065, -6118447361839427651, > -6074679422903704861, -6053157348245110185, -6029489996808528900, > -5984211855143878285, -5976157876053718897, -5960786495011670628, > -5958735514226770035, -5899767639655442330, -5822684184303415148, > -5781417439294763637, -5751460432371890910, -5740166642636309327, > -5695626417612186310, -5640765045723408247, -5617181156049689169, > -5609533985177356591, -5601369236916580549, -5597950494887081576, > -5563417985168606424, -5544827346340456629, -5532661047516804641, > -5522839053491352218, -5515748028172318343, -5503681859719385351, > -5454037971834611841, -5391841126413524561, -5391486446881271229, > -5345799278441821500, -5334673760925625816, -5223383618739305156, > -5221923994481449381, -5201263557535069480, -5146266397250565218, > -5129908985877585855, -5105202808286786842, -5087879514740126453, > -5015647678958926683, -4956601765875516828, -4870012706573251068, > -4843165740363419346, -4785540557423875550, -4769272272470020667, > -4743838345902355963, -4652149714081482841, -4651813505681686208, > -4633498525751156636, -4617489888285113964, -4575171285024168183, > -4426852178336308913, -4426400792698710435, -4389286320937036309, > -4324528033603203034, -4310368852323145495, -4302216608677327172, > -4229528661709148440, -4207740831738287983, -4203528661247313570, > -3948641241721335982, -3946554569612854645, -3931865850800685387, > -3925635355333550077, -3834502440481769685, -3827908348147378297, > -3805680095754927988, -3804947918584815385, -3800995210938487618, > -3783564223836955070, -3775028120786497996, -3711629770355538643, > -3710182799291812403, -3643158926306968005, -3625334149683154824,
[jira] [Updated] (CASSANDRA-10350) cqlsh describe keyspace output no longers keeps indexes in sorted order
[ https://issues.apache.org/jira/browse/CASSANDRA-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10350: -- Fix Version/s: (was: 3.0.x) 3.1 > cqlsh describe keyspace output no longers keeps indexes in sorted order > --- > > Key: CASSANDRA-10350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10350 > Project: Cassandra > Issue Type: Bug >Reporter: Andrew Hust >Priority: Minor > Labels: cqlsh > Fix For: 3.1 > > > cqlsh command {{describe keyspace }} no longer keeps indexes in alpha > sorted order. This was caught with a dtest on > [cassci|http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_describe/]. > Tested on: C* {{b4544846def2bdd00ff841c7e3d9f2559620827b}} > Can be reproduced with the following: > {code} > ccm stop > ccm remove describe_order > ccm create -n 1 -v git:cassandra-2.2 describe_order > ccm start > cat << EOF | ccm node1 cqlsh > CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy', > 'replication_factor': 1}; > USE ks1; > CREATE TABLE ks1.test (id int, col int, val text, val2 text, val3 text, > PRIMARY KEY(id, col)); > CREATE INDEX ix0 ON ks1.test (col); > CREATE INDEX ix3 ON ks1.test (val3); > CREATE INDEX ix2 ON ks1.test (val2); > CREATE INDEX ix1 ON ks1.test (val); > DESCRIBE KEYSPACE ks1; > EOF > ccm stop > ccm setdir -v git:cassandra-3.0 > ccm start > sleep 15 > cat << EOF | ccm node1 cqlsh > DESCRIBE KEYSPACE ks1; > EOF > ccm stop > {code} > Ouput on <= cassandra-2.2: > {code} > CREATE INDEX ix0 ON ks1.test (col); > CREATE INDEX ix1 ON ks1.test (val); > CREATE INDEX ix2 ON ks1.test (val2); > CREATE INDEX ix3 ON ks1.test (val3); > {code} > Output on cassandra-3.0: > {code} > CREATE INDEX ix2 ON ks1.test (val2); > CREATE INDEX ix3 ON ks1.test (val3); > CREATE INDEX ix0 ON ks1.test (col); > CREATE INDEX ix1 ON ks1.test (val); > {code} > //CC [~enigmacurry] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9984) Improve error reporting for malformed schemas in stress profile
[ https://issues.apache.org/jira/browse/CASSANDRA-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9984: - Fix Version/s: (was: 3.x) 3.1 > Improve error reporting for malformed schemas in stress profile > --- > > Key: CASSANDRA-9984 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9984 > Project: Cassandra > Issue Type: Improvement >Reporter: Jim Witschey >Assignee: T Jake Luciani >Priority: Trivial > Fix For: 3.1 > > > See this gist: > https://gist.github.com/mambocab/a78fae8c356223245c63 > for an example of a profile that triggers the bug when used as a stress > profile on trunk. It contains a number of old, now unused, configuration > options in the table schema. The error raised when this schema is executed > isn't propagated because of improper error handling. > To reproduce this error with CCM you can save the file in the gist above as > {{8-columns.yaml}} and run > {code} > ccm create -v git:trunk reproduce-error -n 1 > ccm start --wait-for-binary-proto > ccm stress user profile=8-columns.yaml ops\(insert=1\) n=5K > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10544) Make cqlsh tests work when authentication is configured
[ https://issues.apache.org/jira/browse/CASSANDRA-10544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10544: -- Issue Type: Improvement (was: Bug) > Make cqlsh tests work when authentication is configured > --- > > Key: CASSANDRA-10544 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10544 > Project: Cassandra > Issue Type: Improvement > Components: Tests, Tools >Reporter: Adam Holmberg >Assignee: Stefania >Priority: Trivial > Labels: cqlsh, test > Fix For: 2.1.x, 2.2.x, 3.1 > > > cqlsh tests break if the runner has an authentication section in their > ~/.cassandra/cqlshrc, because cqlsh changes the prompt and the tests scan > output for a prompt. It manifests as read timeouts while waiting for a prompt > in test/run_cqlsh.py. > [This > pattern|https://github.com/mambocab/cassandra/blob/1c27f9be1ba8ea10dbe843d513e23de6238dede8/pylib/cqlshlib/test/run_cqlsh.py#L30] > could be generalized to match the "@cqlsh..." prompt that arises > with this config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9984) Improve error reporting for malformed schemas in stress profile
[ https://issues.apache.org/jira/browse/CASSANDRA-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9984: - Issue Type: Improvement (was: Bug) > Improve error reporting for malformed schemas in stress profile > --- > > Key: CASSANDRA-9984 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9984 > Project: Cassandra > Issue Type: Improvement >Reporter: Jim Witschey >Assignee: T Jake Luciani >Priority: Trivial > Fix For: 3.x > > > See this gist: > https://gist.github.com/mambocab/a78fae8c356223245c63 > for an example of a profile that triggers the bug when used as a stress > profile on trunk. It contains a number of old, now unused, configuration > options in the table schema. The error raised when this schema is executed > isn't propagated because of improper error handling. > To reproduce this error with CCM you can save the file in the gist above as > {{8-columns.yaml}} and run > {code} > ccm create -v git:trunk reproduce-error -n 1 > ccm start --wait-for-binary-proto > ccm stress user profile=8-columns.yaml ops\(insert=1\) n=5K > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10544) Make cqlsh tests work when authentication is configured
[ https://issues.apache.org/jira/browse/CASSANDRA-10544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10544: -- Fix Version/s: (was: 3.0.x) 3.1 > Make cqlsh tests work when authentication is configured > --- > > Key: CASSANDRA-10544 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10544 > Project: Cassandra > Issue Type: Improvement > Components: Tests, Tools >Reporter: Adam Holmberg >Assignee: Stefania >Priority: Trivial > Labels: cqlsh, test > Fix For: 2.1.x, 2.2.x, 3.1 > > > cqlsh tests break if the runner has an authentication section in their > ~/.cassandra/cqlshrc, because cqlsh changes the prompt and the tests scan > output for a prompt. It manifests as read timeouts while waiting for a prompt > in test/run_cqlsh.py. > [This > pattern|https://github.com/mambocab/cassandra/blob/1c27f9be1ba8ea10dbe843d513e23de6238dede8/pylib/cqlshlib/test/run_cqlsh.py#L30] > could be generalized to match the "@cqlsh..." prompt that arises > with this config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8965) Cassandra retains a file handle to the directory its writing to for each writer instance
[ https://issues.apache.org/jira/browse/CASSANDRA-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8965: - Fix Version/s: (was: 3.x) 3.1 > Cassandra retains a file handle to the directory its writing to for each > writer instance > > > Key: CASSANDRA-8965 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8965 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benedict >Priority: Trivial > Fix For: 3.1 > > > We could either share this amongst the CF object, or have a shared > ref-counted cache that opens a reference and shares it amongst all writer > instances, closing it once they all close. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-7324) Strange warnings during pig-test
[ https://issues.apache.org/jira/browse/CASSANDRA-7324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-7324. -- Resolution: Won't Fix Fix Version/s: (was: 2.1.x) > Strange warnings during pig-test > > > Key: CASSANDRA-7324 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7324 > Project: Cassandra > Issue Type: Bug > Components: Tests >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Minor > > Not present in 2.0, we have strange but seemingly harmless warnings when > running pig-test on 2.1: > {noformat} > [junit] 14/05/29 22:21:53 WARN util.MBeans: > Hadoop:service=DataNode,name=FSDatasetState-UndefinedStorageId-1779863485 > [junit] javax.management.InstanceNotFoundException: > Hadoop:service=DataNode,name=FSDatasetState-UndefinedStorageId-1779863485 > [junit] at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > [junit] at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427) > [junit] at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415) > [junit] at > com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546) > [junit] at > org.apache.hadoop.metrics2.util.MBeans.unregister(MBeans.java:71) > [junit] at > org.apache.hadoop.hdfs.server.datanode.FSDataset.shutdown(FSDataset.java:2067) > [junit] at > org.apache.hadoop.hdfs.server.datanode.DataNode.shutdown(DataNode.java:799) > [junit] at > org.apache.hadoop.hdfs.MiniDFSCluster.shutdownDataNodes(MiniDFSCluster.java:566) > [junit] at > org.apache.hadoop.hdfs.MiniDFSCluster.shutdown(MiniDFSCluster.java:550) > [junit] at > org.apache.pig.test.MiniGenericCluster.shutdownMiniDfsClusters(MiniGenericCluster.java:87) > [junit] at > org.apache.pig.test.MiniGenericCluster.shutdownMiniDfsAndMrClusters(MiniGenericCluster.java:77) > [junit] at > org.apache.pig.test.MiniGenericCluster.shutDown(MiniGenericCluster.java:68) > [junit] at > org.apache.cassandra.pig.PigTestBase.oneTimeTearDown(PigTestBase.java:77) > [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [junit] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [junit] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [junit] at java.lang.reflect.Method.invoke(Method.java:606) > [junit] at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > [junit] at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > [junit] at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > [junit] at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:37) > [junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:220) > [junit] at > junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) > [junit] at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518) > [junit] at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052) > [junit] at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) > [junit] 14/05/29 22:21:53 WARN datanode.FSDatasetAsyncDiskService: > AsyncDiskService has already shut down. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10441) Move stress tool into it's own repository and manage dependency on Cassandra externally
[ https://issues.apache.org/jira/browse/CASSANDRA-10441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-10441. Resolution: Won't Fix I hear you, but since stress's primary purpose is to inform C* development, I don't think moving it out of tree makes sense. Among other reasons, we play pretty fast and loose with compatibility and we'd like to keep it that way. > Move stress tool into it's own repository and manage dependency on Cassandra > externally > --- > > Key: CASSANDRA-10441 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10441 > Project: Cassandra > Issue Type: Wish > Components: Tools >Reporter: Nitsan Wakart >Priority: Minor > > This will: > 1. Allow distinct release/maintenance/contribution cycles > 2. Prevent accidental dependencies from Cassandra into the stress tool > 3. Isolate performance changes in Cassandra from changes to stress tool > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10249) Make buffered read size configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10249: -- Fix Version/s: (was: 2.1.x) 2.1.12 > Make buffered read size configurable > > > Key: CASSANDRA-10249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10249 > Project: Cassandra > Issue Type: Improvement >Reporter: Albert P Tobey >Assignee: Albert P Tobey > Fix For: 2.1.12 > > Attachments: Screenshot 2015-09-11 09.32.04.png, Screenshot > 2015-09-11 09.34.10.png, patched-2.1.9-dstat-lvn10.png, > stock-2.1.9-dstat-lvn10.png, yourkit-screenshot.png > > > On read workloads, Cassandra 2.1 reads drastically more data than it emits > over the network. This causes problems throughput the system by wasting disk > IO and causing unnecessary GC. > I have reproduce the issue on clusters and locally with a single instance. > The only requirement to reproduce the issue is enough data to blow through > the page cache. The default schema and data size with cassandra-stress is > sufficient for exposing the issue. > With stock 2.1.9 I regularly observed anywhere from 300:1 to 500 > disk:network ratio. That is to say, for 1MB/s of network IO, Cassandra was > doing 300-500MB/s of disk reads, saturating the drive. > After applying this patch for standard IO mode > https://gist.github.com/tobert/10c307cf3709a585a7cf the ratio fell to around > 100:1 on my local test rig. Latency improved considerably and GC became a lot > less frequent. > I tested with 512 byte reads as well, but got the same performance, which > makes sense since all HDD and SSD made in the last few years have a 4K block > size (many of them lie and say 512). > I'm re-running the numbers now and will post them tomorrow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9912) SizeEstimatesRecorder has assertions after decommission sometimes
[ https://issues.apache.org/jira/browse/CASSANDRA-9912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9912: - Fix Version/s: (was: 2.1.x) 2.1.12 > SizeEstimatesRecorder has assertions after decommission sometimes > - > > Key: CASSANDRA-9912 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9912 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jeremiah Jordan > Fix For: 2.1.12 > > > Doing some testing with 2.1.8 adding and decommissioning nodes. Sometimes > after decommissioning the following starts being thrown by the > SizeEstimatesRecorder. > {noformat} > java.lang.AssertionError: -9223372036854775808 not found in > -9223372036854775798, 10 > at > org.apache.cassandra.locator.TokenMetadata.getPredecessor(TokenMetadata.java:683) > ~[cassandra-all-2.1.8.621.jar:2.1.8.621] > at > org.apache.cassandra.locator.TokenMetadata.getPrimaryRangesFor(TokenMetadata.java:627) > ~[cassandra-all-2.1.8.621.jar:2.1.8.621] > at > org.apache.cassandra.db.SizeEstimatesRecorder.run(SizeEstimatesRecorder.java:68) > ~[cassandra-all-2.1.8.621.jar:2.1.8.621] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118) > ~[cassandra-all-2.1.8.621.jar:2.1.8.621] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_40] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_40] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_40] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_40] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_40] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8653) Upgrading to trunk with auth throws exception
[ https://issues.apache.org/jira/browse/CASSANDRA-8653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971286#comment-14971286 ] Sam Tunnicliffe commented on CASSANDRA-8653: b.q This ticket mentions trunk, but any reason to think 3.0 is immune to that? It's actually the 3.0 that the test upgrades to, or it would be except it's currently skipped (waiting on CASSANDRA-9704, so should be re-enabled). When I run locally I see no auth problems and the test completes as expected. It fails though because of an unexpected ERROR in the log of node1, which is thrown just after the last node is upgraded: {noformat} RROR [HintsDispatcher:2] 2015-10-23 17:18:53,942 CassandraDaemon.java:195 - Exception in thread Thread[HintsDispatcher:2,1,main] java.lang.RuntimeException: java.nio.file.NoSuchFileException: /home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints at org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55) ~[main/:na] at org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66) ~[main/:na] at org.apache.cassandra.hints.ChecksummedDataInput.open(ChecksummedDataInput.java:63) ~[main/:na] at org.apache.cassandra.hints.HintsReader.open(HintsReader.java:77) ~[main/:na] at org.apache.cassandra.hints.HintsDispatcher.create(HintsDispatcher.java:71) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:219) ~[main/:na] at org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:198) ~[main/:na] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_60] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60] Caused by: java.nio.file.NoSuchFileException: /home/sam/.ccm/repository/gitCOLONcassandra-3.0/data/hints/ac459445-1f7f-45f2-b9a8-2b185df34845-1445617063586-1.hints at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) ~[na:1.8.0_60] at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[na:1.8.0_60] at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[na:1.8.0_60] at sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177) ~[na:1.8.0_60] at java.nio.channels.FileChannel.open(FileChannel.java:287) ~[na:1.8.0_60] at java.nio.channels.FileChannel.open(FileChannel.java:335) ~[na:1.8.0_60] at org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:51) ~[main/:na] ... 12 common frames omitted {noformat} > Upgrading to trunk with auth throws exception > - > > Key: CASSANDRA-8653 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8653 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson >Assignee: Sam Tunnicliffe > Fix For: 3.0.0 > > Attachments: node1.log, node2.log, node3.log > > > When running Sam's upgrade_internal_auth_dtest, I am seeing the following > exception (amongst others) in the log file of the second node to be upgraded > to trunk from 2.1: > {code} > ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java:170 - > Exception in thread Thread[GossipStage:1,5,main] > java.lang.NoClassDefFoundError: > org/apache/cassandra/transport/Event$TopologyChange$Change > at > org.apache.cassandra.transport.Server$EventNotifier.onJoinCluster(Server.java:374) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1668) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.onChange(StorageService.java:1384) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1094) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1076) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1034) > ~[main/:na] > at > org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58) > ~[main/:na] > 1554 - Node /127.0.0.1 state jump to normal > ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java > :170 - Exception in thread Thread[GossipStage:1,5,main] > java.lang.NoClassDefFoundError:
[jira] [Updated] (CASSANDRA-8653) Upgrading to trunk with auth throws exception
[ https://issues.apache.org/jira/browse/CASSANDRA-8653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8653: - Fix Version/s: (was: 3.x) 3.0.0 > Upgrading to trunk with auth throws exception > - > > Key: CASSANDRA-8653 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8653 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson >Assignee: Sam Tunnicliffe > Fix For: 3.0.0 > > Attachments: node1.log, node2.log, node3.log > > > When running Sam's upgrade_internal_auth_dtest, I am seeing the following > exception (amongst others) in the log file of the second node to be upgraded > to trunk from 2.1: > {code} > ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java:170 - > Exception in thread Thread[GossipStage:1,5,main] > java.lang.NoClassDefFoundError: > org/apache/cassandra/transport/Event$TopologyChange$Change > at > org.apache.cassandra.transport.Server$EventNotifier.onJoinCluster(Server.java:374) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1668) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.onChange(StorageService.java:1384) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1094) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1076) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1034) > ~[main/:na] > at > org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58) > ~[main/:na] > 1554 - Node /127.0.0.1 state jump to normal > ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java > :170 - Exception in thread Thread[GossipStage:1,5,main] > java.lang.NoClassDefFoundError: org/apache/cassandra/transport/Eve > nt$TopologyChange$Change > at org.apache.cassandra.transport.Server$EventNotifier.onJ > oinCluster(Server.java:374) ~[main/:na] > at org.apache.cassandra.service.StorageService.handleState > Normal(StorageService.java:1668) ~[main/:na] > at org.apache.cassandra.service.StorageService.onChange(St > orageService.java:1384) ~[main/:na] > at org.apache.cassandra.gms.Gossiper.doOnChangeNotificatio > ns(Gossiper.java:1094) ~[main/:na] > at org.apache.cassandra.gms.Gossiper.applyNewStates(Gossip > er.java:1076) ~[main/:na] > at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gos > siper.java:1034) ~[main/:na] > at org.apache.cassandra.gms.GossipDigestAckVerbHandler.doV > erb(GossipDigestAckVerbHandler.java:58) ~[main/:na] > at > org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) > ~[main/:na] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > ~[na:1.7.0_67] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > ~[na:1.7.0_67] > at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_67] > Caused by: java.lang.ClassNotFoundException: > org.apache.cassandra.transport.Event$TopologyChange$Change > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > ~[na:1.7.0_67] > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > ~[na:1.7.0_67] > at java.security.AccessController.doPrivileged(Native Method) > ~[na:1.7.0_67] > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > ~[na:1.7.0_67] > at java.lang.ClassLoader.loadClass(ClassLoader.java:425) > ~[na:1.7.0_67] > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > ~[na:1.7.0_67] > at java.lang.ClassLoader.loadClass(ClassLoader.java:358) > ~[na:1.7.0_67] > ... 11 common frames omitted > WARN [Thread-10] 2015-01-20 13:46:34,500 IncomingTcpConnection.java:91 - > UnknownColumnFamilyException reading from socket; closing > org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find > cfId=5f2fbdad-91f1-3946-bd25-d5da3a5c35ec > at > org.apache.cassandra.db.ColumnFamilySerializer.deserializeCfId(ColumnFamilySerializer.java:164) > ~[main/:na] > at > org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:97) > ~[main/:na] > at > org.apache.cassandra.db.Mutation$MutationSerializer.deserializeOneCf(Mutation.java:322) > ~[main/:na] > at > org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:302) > ~[main/:na] > at > org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:330) > ~[main/:na] > at >
[jira] [Commented] (CASSANDRA-9813) cqlsh column header can be incorrect when no rows are returned
[ https://issues.apache.org/jira/browse/CASSANDRA-9813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971211#comment-14971211 ] Aleksey Yeschenko commented on CASSANDRA-9813: -- [~aholmber] Could you have a look at this? Thanks. > cqlsh column header can be incorrect when no rows are returned > -- > > Key: CASSANDRA-9813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9813 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksey Yeschenko > Labels: cqlsh > Fix For: 3.x, 2.1.x, 2.2.x > > Attachments: Test-for-9813.txt > > > Upon migration, we internally create a pair of surrogate clustering/regular > columns for compact static tables. These shouldn't be exposed to the user. > That is, for the table > {code} > CREATE TABLE bar (k int, c int, PRIMARY KEY (k)) WITH COMPACT STORAGE; > {code} > {{SELECT * FROM bar}} should not be returning this result set: > {code} > cqlsh:test> select * from bar; > c | column1 | k | value > ---+-+---+--- > (0 rows) > {code} > Should only contain the defined {{c}} and {{k}} columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10335) Collect flight recordings of canonical bulk read workload in CI
[ https://issues.apache.org/jira/browse/CASSANDRA-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-10335: --- Assignee: Ryan McGuire > Collect flight recordings of canonical bulk read workload in CI > --- > > Key: CASSANDRA-10335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10335 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Ariel Weisberg >Assignee: Ryan McGuire > Fix For: 3.x > > > Flight recorder to track GC, IO stalls, lock contention, idle threads. Don't > need CPU profiling since that will be covered by flame graphs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9748) Can't see other nodes when using multiple network interfaces
[ https://issues.apache.org/jira/browse/CASSANDRA-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9748: - Issue Type: Improvement (was: Bug) > Can't see other nodes when using multiple network interfaces > > > Key: CASSANDRA-9748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9748 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.0.16; multi-DC configuration >Reporter: Roman Bielik >Assignee: Paulo Motta > Labels: docs-impacting > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: system_node1.log, system_node2.log > > > The idea is to setup a multi-DC environment across 2 different networks based > on the following configuration recommendations: > http://docs.datastax.com/en/cassandra/2.0/cassandra/configuration/configMultiNetworks.html > Each node has 2 network interfaces. One used as a private network (DC1: > 10.0.1.x and DC2: 10.0.2.x). The second one a "public" network where all > nodes can see each other (this one has a higher latency). > Using the following settings in cassandra.yaml: > *seeds:* public IP (same as used in broadcast_address) > *listen_address:* private IP > *broadcast_address:* public IP > *rpc_address:* 0.0.0.0 > *endpoint_snitch:* GossipingPropertyFileSnitch > _(tried different combinations with no luck)_ > No firewall and no SSL/encryption used. > The problem is that nodes do not see each other (a gossip problem I guess). > The nodetool ring/status shows only the local node but not the other ones > (even from the same DC). > When I set listen_address to public IP, then everything works fine, but that > is not the required configuration. > _Note: Not using EC2 cloud!_ > netstat -anp | grep -E "(7199|9160|9042|7000)" > tcp0 0 0.0.0.0:71990.0.0.0:* > LISTEN 3587/java > tcp0 0 10.0.1.1:9160 0.0.0.0:* > LISTEN 3587/java > tcp0 0 10.0.1.1:9042 0.0.0.0:* > LISTEN 3587/java > tcp0 0 10.0.1.1:7000 0.0.0.0:* > LISTEN 3587/java > tcp0 0 127.0.0.1:7199 127.0.0.1:52874 > ESTABLISHED 3587/java > tcp0 0 10.0.1.1:7199 10.0.1.1:39650 > ESTABLISHED 3587/java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10333) Collect SAR metrics from CI jobs running canonical bulk reading workload
[ https://issues.apache.org/jira/browse/CASSANDRA-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-10333: --- Assignee: Ryan McGuire > Collect SAR metrics from CI jobs running canonical bulk reading workload > > > Key: CASSANDRA-10333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10333 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Ariel Weisberg >Assignee: Ryan McGuire > Fix For: 3.x > > > sar to track block device metrics, interrupts, context switches etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10334) Generate flame graphs from canonical bulk reading workload running in CI
[ https://issues.apache.org/jira/browse/CASSANDRA-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-10334: --- Assignee: Ryan McGuire > Generate flame graphs from canonical bulk reading workload running in CI > > > Key: CASSANDRA-10334 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10334 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Ariel Weisberg >Assignee: Ryan McGuire > Fix For: 3.x > > > Flame graphs for CPU utilization. Bonus points if we can get source code > annotated with cache misses or at least total counts of cache misses for the > entire run. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8460) Make it possible to move non-compacting sstables to slow/big storage in DTCS
[ https://issues.apache.org/jira/browse/CASSANDRA-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-8460: -- Reviewer: Blake Eggleston (was: Marcus Eriksson) reassigning review to [~bdeggleston] > Make it possible to move non-compacting sstables to slow/big storage in DTCS > > > Key: CASSANDRA-8460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8460 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Jeff Jirsa > Labels: dtcs > Fix For: 3.x > > > It would be nice if we could configure DTCS to have a set of extra data > directories where we move the sstables once they are older than > max_sstable_age_days. > This would enable users to have a quick, small SSD for hot, new data, and big > spinning disks for data that is rarely read and never compacted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10143) Apparent counter overcount during certain network partitions
[ https://issues.apache.org/jira/browse/CASSANDRA-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10143: -- Fix Version/s: (was: 3.0.x) 3.1 > Apparent counter overcount during certain network partitions > > > Key: CASSANDRA-10143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10143 > Project: Cassandra > Issue Type: Bug >Reporter: Joel Knighton >Assignee: Aleksey Yeschenko > Fix For: 2.1.x, 2.2.x, 3.1 > > > This issue is reproducible in this [Jepsen > Test|https://github.com/riptano/jepsen/blob/f45f5320db608d48de2c02c871aecc4910f4d963/cassandra/test/cassandra/counter_test.clj#L16]. > The test starts a five-node cluster and issues increments by one against a > single counter. It then checks that the counter is in the range [OKed > increments, OKed increments + Write Timeouts] at each read. Increments are > issued at CL.ONE and reads at CL.ALL. Throughout the test, network failures > are induced that create halved network partitions. A halved network partition > splits the cluster into three connected nodes and two connected nodes, > randomly. > This test started failing; bisects showed that it was actually a test change > that caused this failure. When the network partitions are induced in a cycle > of 15s healthy/45s partitioned or 20s healthy/45s partitioned, the test > failes. When network partitions are induced in a cycle of 15s healthy/60s > partitioned, 20s healthy/45s partitioned, or 20s healthy/60s partitioned, the > test passes. > There is nothing unusual in the logs of the nodes for the failed tests. The > results are very reproducible. > One noticeable trend is that more reads seem to get serviced during the > failed tests. > Most testing has been done in 2.1.8 - the same issue appears to be present in > 2.2/3.0/trunk, but I haven't spent as much time reproducing. > Ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10512) We do not save an upsampled index summaries
[ https://issues.apache.org/jira/browse/CASSANDRA-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10512: -- Fix Version/s: (was: 3.0.x) (was: 3.x) 3.1 > We do not save an upsampled index summaries > --- > > Key: CASSANDRA-10512 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10512 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Benedict > Fix For: 2.1.x, 2.2.x, 3.1 > > > If we downsample an index summary, we overwrite the existing summary, despite > downsampling being inexpensive. However on upsampling (which is expensive) we > do not, so that on restart all of our index summaries are the smallest they > have ever been adjusted to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9069) debug-cql broken in trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9069: - Fix Version/s: (was: 3.x) 3.1 > debug-cql broken in trunk > - > > Key: CASSANDRA-9069 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9069 > Project: Cassandra > Issue Type: Bug >Reporter: Robert Stupp >Priority: Minor > Fix For: 3.1 > > > {{debug-cql}} is broken on trunk. > At startup it just says: > {code} > Error: Exception thrown by the agent : java.lang.NullPointerException > {code} > That exception originates from JMX agent (which cannot bind). > It can be reproduced by starting C* locally and starting {{debug-cql}}. > Workaround is to comment out sourcing of {{cassandra-env.sh}}. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10257) InvertedIndex trigger example has not been updated post 8099
[ https://issues.apache.org/jira/browse/CASSANDRA-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10257: -- Reviewer: Aleksey Yeschenko > InvertedIndex trigger example has not been updated post 8099 > > > Key: CASSANDRA-10257 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10257 > Project: Cassandra > Issue Type: Bug > Components: Examples >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Minor > Fix For: 3.0.x > > Attachments: 10257.txt > > > The {{InvertedIndex}} example is still using pre-8099 code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9510) assassinating an unknown endpoint could npe
[ https://issues.apache.org/jira/browse/CASSANDRA-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9510: - Fix Version/s: (was: 3.x) 3.1 > assassinating an unknown endpoint could npe > --- > > Key: CASSANDRA-9510 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9510 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 3.1 > > Attachments: assissinate_unknown.txt > > > If the code assissinates an unknown endpoint, it doesn't generate a 'tokens' > collection, which then does > epState.addApplicationState(ApplicationState.STATUS, > StorageService.instance.valueFactory.left(tokens, computeExpireTime())); > and left(null, time); will npe -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10575) Refactor storage protocol to use Netty instead of BIO
Robert Stupp created CASSANDRA-10575: Summary: Refactor storage protocol to use Netty instead of BIO Key: CASSANDRA-10575 URL: https://issues.apache.org/jira/browse/CASSANDRA-10575 Project: Cassandra Issue Type: Improvement Reporter: Robert Stupp Current storage protocol (everything beneath o.a.c.net) currently uses Java blocking I/O. I.e. {{InboundTcpConnection}} and {{OutboundTcpConnection}} use a dedicated Java thread per connection. Using NIO would reduce the number of threads as many threads can become a problem in bigger clusters. Migrating the code to Netty seems to be a prerequisite for thread-per-core model. The intention of this ticket is not to change the protocol itself as CASSANDRA-8971 would do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6887) LOCAL_ONE read repair only does local repair, in spite of global digest queries
[ https://issues.apache.org/jira/browse/CASSANDRA-6887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-6887: - Assignee: (was: Aleksey Yeschenko) > LOCAL_ONE read repair only does local repair, in spite of global digest > queries > --- > > Key: CASSANDRA-6887 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6887 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Cassandra 2.0.6, x86-64 ubuntu precise >Reporter: Duncan Sands > Fix For: 2.1.x > > Attachments: 6887-2.0.txt > > > I have a cluster spanning two data centres. Almost all of the writing (and a > lot of reading) is done in DC1. DC2 is used for running the occasional > analytics query. Reads in both data centres use LOCAL_ONE. Read repair > settings are set to the defaults on all column families. > I had a long network outage between the data centres; it lasted longer than > the hints window, so after it was over DC2 didn't have the latest > information. Even after reading data many many times in DC2, the returned > data was still out of date: read repair was not correcting it. > I then investigated using cqlsh in DC2, with tracing on. > What I saw was: > - with consistency ONE, after about 10 read requests a digest request would > be sent to many nodes (spanning both data centres), and the data in DC2 would > be repaired. > - with consistency LOCAL_ONE, after about 10 read requests a digest request > would be sent to many nodes (spanning both data centres), but the data in DC2 > would not be repaired. This is in spite of digest requests being sent to > DC1, as shown by the tracing. > So it looks like digest requests are being sent to both data centres, but > replies from outside the local data centre are ignored when using LOCAL_ONE. > The same data is being queried all the time in DC1 with consistency > LOCAL_ONE, but this didn't result in the data in DC2 being read repaired > either. This is a slightly different case to what I described above: in that > case the local node was out of date and the remote node had the latest data, > while here it is the other way round. > It could be argued that you don't want cross data centre read repair when > using LOCAL_ONE. But then why bother sending cross data centre digest > requests? And if only doing local read repair is how it is supposed to work > then it would be good to document this somewhere. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8369) Better error handling in CQLSH for invalid password
[ https://issues.apache.org/jira/browse/CASSANDRA-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8369: - Assignee: (was: Aleksey Yeschenko) > Better error handling in CQLSH for invalid password > --- > > Key: CASSANDRA-8369 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8369 > Project: Cassandra > Issue Type: Improvement >Reporter: Johnny Miller >Priority: Minor > > On C* 2.0.11/Cqlsh 4.1.1 when logging with an invalid password you get back a > stacktrace rather than a more user friendly error. It might be better if this > was more user friendly. > For example - this is what you get back now: > root@cass1:~# cqlsh -u cassandra -p johnny > Traceback (most recent call last): > File "/usr/bin/cqlsh", line 2113, in > main(*read_options(sys.argv[1:], os.environ)) > File "/usr/bin/cqlsh", line 2093, in main > single_statement=options.execute) > File "/usr/bin/cqlsh", line 505, in __init__ > password=password, cql_version=cqlver, transport=transport) > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py", > line 143, in connect > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py", > line 59, in __init__ > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py", > line 157, in establish_connection > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py", > line 465, in login > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py", > line 486, in recv_login > cql.cassandra.ttypes.AuthenticationException: > AuthenticationException(why='Username and/or password are incorrect') -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7715) Add a credentials cache to the PasswordAuthenticator
[ https://issues.apache.org/jira/browse/CASSANDRA-7715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-7715: - Assignee: (was: Aleksey Yeschenko) > Add a credentials cache to the PasswordAuthenticator > > > Key: CASSANDRA-7715 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7715 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Mike Adamson >Priority: Minor > Fix For: 3.x > > > If the PasswordAuthenticator cached credentials for a short time it would > reduce the overhead of user journeys when they need to do multiple > authentications in quick succession. > This cache should work in the same way as the cache in CassandraAuthorizer in > that if it's TTL is set to 0 the cache will be disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8655) Exception on upgrade to trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8655: - Assignee: (was: Aleksey Yeschenko) > Exception on upgrade to trunk > - > > Key: CASSANDRA-8655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8655 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson > Fix For: 3.x > > > The dtest > upgrade_through_versions_test.TestUpgrade_from_cassandra_2_1_latest_tag_to_trunk_HEAD.upgrade_test_mixed > is failing with the following exception: > {code} > ERROR [Thread-10] 2015-01-20 14:12:44,117 CassandraDaemon.java:170 - > Exception in thread Thread[Thread-10,5,main] > java.lang.NullPointerException: null > at > org.apache.cassandra.db.SliceFromReadCommandSerializer.deserialize(SliceFromReadCommand.java:153) > ~[main/:na] > at > org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:157) > ~[main/:na] > at > org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:131) > ~[main/:na] > at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:168) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:150) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:82) > ~[main/:na] > {code} > It is trying to execute a simple "SELECT k,v FROM cf WHERE k=X" query on a > trunk node after upgrading from 2.1-HEAD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10173) Compaction isn't cleaning out tombstones between hint deliveries
[ https://issues.apache.org/jira/browse/CASSANDRA-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10173: -- Assignee: (was: Aleksey Yeschenko) > Compaction isn't cleaning out tombstones between hint deliveries > > > Key: CASSANDRA-10173 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10173 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jonathan Ellis > Fix For: 2.2.x > > Attachments: system (3).log > > > 3 node cluster, 100M writes. Same scenario as 10172: > Test Start: 00:00:00 > Node 1 Killed: 00:05:48 > Node 2 Killed: 00:13:33 > Node 1 Started: 00:24:20 > Node 2 Started: 00:32:23 > Test Done: 00:38:33 > Node 1 hints replay finished: 00:56:16 > Node 2 hints replay finished: 01:00:16 > Node 3 hints replay finished: 02:08:00 > Log attached. Note the tombstone_failure_threshold errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8916) com.datastax.driver.core.exceptions.AlreadyExistsException: Keyspace already exists
[ https://issues.apache.org/jira/browse/CASSANDRA-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8916: - Assignee: (was: Aleksey Yeschenko) > com.datastax.driver.core.exceptions.AlreadyExistsException: Keyspace > already exists > --- > > Key: CASSANDRA-8916 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8916 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Joseph Samuel > Attachments: client.log, system.log.1.node1a, system.log.1.node1b, > system.log.1.node2a, system.log.1.node2b > > > As part of our continuos delivery pipeline, in some environments we drop and > recreate our schema on every build. This occasionally fails with the > following error from the client: > com.datastax.driver.core.exceptions.AlreadyExistsException: Keyspace > already exists > When looking into each node individually after this exception, one node still > contains the keyspace and all other nodes no longer show it. After > restarting all cassandra nodes, none of them have the keyspace. > We have attached the logs we get from our client and the nodes. We have seen > this problem with cassandra 2.0.8 and 2.0.12 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8879) Alter table on compact storage broken
[ https://issues.apache.org/jira/browse/CASSANDRA-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-8879: - Assignee: (was: Aleksey Yeschenko) > Alter table on compact storage broken > - > > Key: CASSANDRA-8879 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8879 > Project: Cassandra > Issue Type: Bug >Reporter: Nick Bailey > Fix For: 2.1.x > > Attachments: 8879-2.0.txt > > > In 2.0 HEAD, alter table on compact storage tables seems to be broken. With > the following table definition, altering the column breaks cqlsh and > generates a stack trace in the log. > {noformat} > CREATE TABLE settings ( > key blob, > column1 blob, > value blob, > PRIMARY KEY ((key), column1) > ) WITH COMPACT STORAGE > {noformat} > {noformat} > cqlsh:OpsCenter> alter table settings ALTER column1 TYPE ascii ; > TSocket read 0 bytes > cqlsh:OpsCenter> DESC TABLE settings; > {noformat} > {noformat} > ERROR [Thrift:7] 2015-02-26 17:20:24,640 CassandraDaemon.java (line 199) > Exception in thread Thread[Thrift:7,5,main] > java.lang.AssertionError > >...at > >org.apache.cassandra.cql3.statements.AlterTableStatement.announceMigration(AlterTableStatement.java:198) > >...at > >org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:79) > >...at > >org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:158) > >...at > >org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:175) > >...at > >org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1958) > >...at > >org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486) > >...at > >org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470) > >...at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) > >...at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) > >...at > >org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:204) > >...at > >java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >...at > >java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >...at java.lang.Thread.run(Thread.java:724) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/2] cassandra git commit: Support encrypted and plain traffic on the same port
Repository: cassandra Updated Branches: refs/heads/trunk e43fbe0a7 -> 71d9dba06 Support encrypted and plain traffic on the same port patch by Norman Maurer; reviewed by Robert Stupp for CASSANDRA-10559 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/535c3ac7 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/535c3ac7 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/535c3ac7 Branch: refs/heads/trunk Commit: 535c3ac759ffd24d2324027bce3d0d6228823ba5 Parents: a639808 Author: Norman MaurerAuthored: Fri Oct 23 14:44:18 2015 +0200 Committer: Robert Stupp Committed: Fri Oct 23 14:44:18 2015 +0200 -- CHANGES.txt | 1 + conf/cassandra.yaml | 2 + .../cassandra/config/EncryptionOptions.java | 1 + .../org/apache/cassandra/transport/Server.java | 75 ++-- .../service/NativeTransportServiceTest.java | 18 + 5 files changed, 90 insertions(+), 7 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 0529dd8..67e06ca 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0 + * Support encrypted and plain traffic on the same port (CASSANDRA-10559) * Fix handling of range tombstones when reading old format sstables (CASSANDRA-10360) * Aggregate with Initial Condition fails with C* 3.0 (CASSANDRA-10367) Merged from 2.2: http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/conf/cassandra.yaml -- diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index bf5149f..fa9ea47 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -884,6 +884,8 @@ server_encryption_options: # enable or disable client/server encryption. client_encryption_options: enabled: false +# If enabled and optional is set to true encrypted and unencrypted connections are handled. +optional: false keystore: conf/.keystore keystore_password: cassandra # require_client_auth: false http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/src/java/org/apache/cassandra/config/EncryptionOptions.java -- diff --git a/src/java/org/apache/cassandra/config/EncryptionOptions.java b/src/java/org/apache/cassandra/config/EncryptionOptions.java index 945a15b..31f8b4a 100644 --- a/src/java/org/apache/cassandra/config/EncryptionOptions.java +++ b/src/java/org/apache/cassandra/config/EncryptionOptions.java @@ -36,6 +36,7 @@ public abstract class EncryptionOptions public static class ClientEncryptionOptions extends EncryptionOptions { public boolean enabled = false; +public boolean optional = false; } public static class ServerEncryptionOptions extends EncryptionOptions http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/src/java/org/apache/cassandra/transport/Server.java -- diff --git a/src/java/org/apache/cassandra/transport/Server.java b/src/java/org/apache/cassandra/transport/Server.java index a3cefcd..b786436 100644 --- a/src/java/org/apache/cassandra/transport/Server.java +++ b/src/java/org/apache/cassandra/transport/Server.java @@ -33,9 +33,11 @@ import org.slf4j.Logger; import org.slf4j.LoggerFactory; import io.netty.bootstrap.ServerBootstrap; +import io.netty.buffer.ByteBuf; import io.netty.channel.*; import io.netty.channel.epoll.EpollEventLoopGroup; import io.netty.channel.epoll.EpollServerSocketChannel; +import io.netty.handler.codec.ByteToMessageDecoder; import io.netty.channel.group.ChannelGroup; import io.netty.channel.group.DefaultChannelGroup; import io.netty.channel.nio.NioEventLoopGroup; @@ -139,8 +141,16 @@ public class Server implements CassandraDaemon.Server final EncryptionOptions.ClientEncryptionOptions clientEnc = DatabaseDescriptor.getClientEncryptionOptions(); if (this.useSSL) { -logger.info("Enabling encrypted CQL connections between client and server"); -bootstrap.childHandler(new SecureInitializer(this, clientEnc)); +if (clientEnc.optional) +{ +logger.info("Enabling optionally encrypted CQL connections between client and server"); +bootstrap.childHandler(new OptionalSecureInitializer(this, clientEnc)); +} +else +{ +logger.info("Enabling encrypted CQL connections between client and server"); +bootstrap.childHandler(new
[jira] [Commented] (CASSANDRA-10544) Make cqlsh tests work when authentication is configured
[ https://issues.apache.org/jira/browse/CASSANDRA-10544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970968#comment-14970968 ] Adam Holmberg commented on CASSANDRA-10544: --- +1 tested with several different usernames, with/without an auth section in the config. > Make cqlsh tests work when authentication is configured > --- > > Key: CASSANDRA-10544 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10544 > Project: Cassandra > Issue Type: Bug > Components: Tests, Tools >Reporter: Adam Holmberg >Assignee: Stefania >Priority: Trivial > Labels: cqlsh, test > Fix For: 2.1.x, 2.2.x, 3.0.x > > > cqlsh tests break if the runner has an authentication section in their > ~/.cassandra/cqlshrc, because cqlsh changes the prompt and the tests scan > output for a prompt. It manifests as read timeouts while waiting for a prompt > in test/run_cqlsh.py. > [This > pattern|https://github.com/mambocab/cassandra/blob/1c27f9be1ba8ea10dbe843d513e23de6238dede8/pylib/cqlshlib/test/run_cqlsh.py#L30] > could be generalized to match the "@cqlsh..." prompt that arises > with this config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8779) Add type code to binary query parameters in QUERY messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-8779: Issue Type: Sub-task (was: Improvement) Parent: CASSANDRA-9362 > Add type code to binary query parameters in QUERY messages > -- > > Key: CASSANDRA-8779 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8779 > Project: Cassandra > Issue Type: Sub-task > Components: API > Environment: Linux Mint 64-bit | ruby-driver 2.1 | java-driver 2.1 | > C* 2.1.2 >Reporter: Kishan Karunaratne >Assignee: Tyler Hobbs > Labels: client-impacting, protocolv5 > Fix For: 3.x > > > If I insert a tuple using an extra pair of ()'s, C* will let me do the > insert, but (incorrectly) creates a nested tuple as the first tuple value. > Upon doing a select statement, the result is jumbled and has weird binary in > it (which I wasn't able to copy into here). > Example using ruby-driver: > {noformat} > session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b > frozen>)") > complete = Cassandra::Tuple.new('foo', 123, true) > session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", arguments: > [complete])# extra ()'s here > result = session.execute("SELECT b FROM mytable WHERE a=0").first > p result['b'] > {noformat} > Output: > {noformat} > # > {noformat} > Bug also confirmed using java-driver. > Example using java-driver: > {noformat} > session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b > frozen >)"); > TupleType t = TupleType.of(DataType.ascii(), DataType.cint(), > DataType.cboolean()); > TupleValue complete = t.newValue("foo", 123, true); > session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", complete); // > extra ()'s here > TupleValue r = session.execute("SELECT b FROM mytable WHERE > a=0").one().getTupleValue("b"); > System.out.println(r); > {noformat} > Output: > {noformat} > ('foo{', null, null) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8655) Exception on upgrade to trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970954#comment-14970954 ] Sylvain Lebresne commented on CASSANDRA-8655: - [~philipthompson] Does that affect 3.0 or just trunk? Is this still a thing? > Exception on upgrade to trunk > - > > Key: CASSANDRA-8655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8655 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson > Fix For: 3.x > > > The dtest > upgrade_through_versions_test.TestUpgrade_from_cassandra_2_1_latest_tag_to_trunk_HEAD.upgrade_test_mixed > is failing with the following exception: > {code} > ERROR [Thread-10] 2015-01-20 14:12:44,117 CassandraDaemon.java:170 - > Exception in thread Thread[Thread-10,5,main] > java.lang.NullPointerException: null > at > org.apache.cassandra.db.SliceFromReadCommandSerializer.deserialize(SliceFromReadCommand.java:153) > ~[main/:na] > at > org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:157) > ~[main/:na] > at > org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:131) > ~[main/:na] > at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:168) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:150) > ~[main/:na] > at > org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:82) > ~[main/:na] > {code} > It is trying to execute a simple "SELECT k,v FROM cf WHERE k=X" query on a > trunk node after upgrading from 2.1-HEAD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8394) Cassandra 3.0 Auth changes
[ https://issues.apache.org/jira/browse/CASSANDRA-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe resolved CASSANDRA-8394. Resolution: Fixed > Cassandra 3.0 Auth changes > -- > > Key: CASSANDRA-8394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8394 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Sam Tunnicliffe > Labels: docs-impacting > Fix For: 3.x > > > This will be the task that will group all the 3.0 Auth changes, of which we > need quite some: > 1. Implement Roles (CASSANDRA-7653) > 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator > SASL-only, and support full SASL capabilities (incl. proxy authentication - > see CASSANDRA-7686, CASSANDRA-8068) > 3. Remove the current simplistic permissions cache with > implementation-specific user/credentials/permissions caches, at least in the > implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194) > 4. Consider adding a way to split superuser-ness and the rights to manage > users (CASSANDRA-7216, CASSANDRA-8650) > 5. Add permissions for types and functions (CASSANDRA-7557) > 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082) > 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8779) Add type code to binary query parameters in QUERY messages
[ https://issues.apache.org/jira/browse/CASSANDRA-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-8779: Labels: client-impacting protocolv5 (was: client-impacting protocolv4) > Add type code to binary query parameters in QUERY messages > -- > > Key: CASSANDRA-8779 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8779 > Project: Cassandra > Issue Type: Improvement > Components: API > Environment: Linux Mint 64-bit | ruby-driver 2.1 | java-driver 2.1 | > C* 2.1.2 >Reporter: Kishan Karunaratne >Assignee: Tyler Hobbs > Labels: client-impacting, protocolv5 > Fix For: 3.x > > > If I insert a tuple using an extra pair of ()'s, C* will let me do the > insert, but (incorrectly) creates a nested tuple as the first tuple value. > Upon doing a select statement, the result is jumbled and has weird binary in > it (which I wasn't able to copy into here). > Example using ruby-driver: > {noformat} > session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b > frozen>)") > complete = Cassandra::Tuple.new('foo', 123, true) > session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", arguments: > [complete])# extra ()'s here > result = session.execute("SELECT b FROM mytable WHERE a=0").first > p result['b'] > {noformat} > Output: > {noformat} > # > {noformat} > Bug also confirmed using java-driver. > Example using java-driver: > {noformat} > session.execute("CREATE TABLE mytable (a int PRIMARY KEY, b > frozen >)"); > TupleType t = TupleType.of(DataType.ascii(), DataType.cint(), > DataType.cboolean()); > TupleValue complete = t.newValue("foo", 123, true); > session.execute("INSERT INTO mytable (a, b) VALUES (0, (?))", complete); // > extra ()'s here > TupleValue r = session.execute("SELECT b FROM mytable WHERE > a=0").one().getTupleValue("b"); > System.out.println(r); > {noformat} > Output: > {noformat} > ('foo{', null, null) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Support encrypted and plain traffic on the same port
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 a63980868 -> 535c3ac75 Support encrypted and plain traffic on the same port patch by Norman Maurer; reviewed by Robert Stupp for CASSANDRA-10559 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/535c3ac7 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/535c3ac7 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/535c3ac7 Branch: refs/heads/cassandra-3.0 Commit: 535c3ac759ffd24d2324027bce3d0d6228823ba5 Parents: a639808 Author: Norman MaurerAuthored: Fri Oct 23 14:44:18 2015 +0200 Committer: Robert Stupp Committed: Fri Oct 23 14:44:18 2015 +0200 -- CHANGES.txt | 1 + conf/cassandra.yaml | 2 + .../cassandra/config/EncryptionOptions.java | 1 + .../org/apache/cassandra/transport/Server.java | 75 ++-- .../service/NativeTransportServiceTest.java | 18 + 5 files changed, 90 insertions(+), 7 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 0529dd8..67e06ca 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0 + * Support encrypted and plain traffic on the same port (CASSANDRA-10559) * Fix handling of range tombstones when reading old format sstables (CASSANDRA-10360) * Aggregate with Initial Condition fails with C* 3.0 (CASSANDRA-10367) Merged from 2.2: http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/conf/cassandra.yaml -- diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index bf5149f..fa9ea47 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -884,6 +884,8 @@ server_encryption_options: # enable or disable client/server encryption. client_encryption_options: enabled: false +# If enabled and optional is set to true encrypted and unencrypted connections are handled. +optional: false keystore: conf/.keystore keystore_password: cassandra # require_client_auth: false http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/src/java/org/apache/cassandra/config/EncryptionOptions.java -- diff --git a/src/java/org/apache/cassandra/config/EncryptionOptions.java b/src/java/org/apache/cassandra/config/EncryptionOptions.java index 945a15b..31f8b4a 100644 --- a/src/java/org/apache/cassandra/config/EncryptionOptions.java +++ b/src/java/org/apache/cassandra/config/EncryptionOptions.java @@ -36,6 +36,7 @@ public abstract class EncryptionOptions public static class ClientEncryptionOptions extends EncryptionOptions { public boolean enabled = false; +public boolean optional = false; } public static class ServerEncryptionOptions extends EncryptionOptions http://git-wip-us.apache.org/repos/asf/cassandra/blob/535c3ac7/src/java/org/apache/cassandra/transport/Server.java -- diff --git a/src/java/org/apache/cassandra/transport/Server.java b/src/java/org/apache/cassandra/transport/Server.java index a3cefcd..b786436 100644 --- a/src/java/org/apache/cassandra/transport/Server.java +++ b/src/java/org/apache/cassandra/transport/Server.java @@ -33,9 +33,11 @@ import org.slf4j.Logger; import org.slf4j.LoggerFactory; import io.netty.bootstrap.ServerBootstrap; +import io.netty.buffer.ByteBuf; import io.netty.channel.*; import io.netty.channel.epoll.EpollEventLoopGroup; import io.netty.channel.epoll.EpollServerSocketChannel; +import io.netty.handler.codec.ByteToMessageDecoder; import io.netty.channel.group.ChannelGroup; import io.netty.channel.group.DefaultChannelGroup; import io.netty.channel.nio.NioEventLoopGroup; @@ -139,8 +141,16 @@ public class Server implements CassandraDaemon.Server final EncryptionOptions.ClientEncryptionOptions clientEnc = DatabaseDescriptor.getClientEncryptionOptions(); if (this.useSSL) { -logger.info("Enabling encrypted CQL connections between client and server"); -bootstrap.childHandler(new SecureInitializer(this, clientEnc)); +if (clientEnc.optional) +{ +logger.info("Enabling optionally encrypted CQL connections between client and server"); +bootstrap.childHandler(new OptionalSecureInitializer(this, clientEnc)); +} +else +{ +logger.info("Enabling encrypted CQL connections between client and server"); +
[jira] [Resolved] (CASSANDRA-7791) Consider re-allowing to refer to UDT outside of their keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-7791. - Resolution: Not A Problem We went with making functions keyspace-scoped in the end, so this is kind of moot. > Consider re-allowing to refer to UDT outside of their keyspace > -- > > Key: CASSANDRA-7791 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7791 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne > Labels: cql > Fix For: 3.x > > > In CASSANDRA-6643 we decided to make UDT inaccessible outside of their > keyspace of definition. Doing so mainly has the advantage that when we drop a > keyspace, we don't have to worry its UDT being used in another keyspace. > However, this directly conflict with functions (UDF) being global: we can't > have functions working on UDT if functions are global and we don't allow UDT > access outside their keyspace. Which, I believe, leave us with the following > possible options: > # we make UDT accessible anywhere (though their fully qualified name). > # we don't support functions on UDT at all. > # we make functions keyspace-scoped, either always, or only if they apply to > UDT. > # we revert CASSANDRA-6438 and make UDT global. > In a perfect world I would lean towards 4: the arguments to make UDT > keyspace-scoped where not wrong per-se but weak in hindsight given the other > options here. It is however basically too late: changing it would be a > breaking change so we can't reasonably change this post-2.1.0, and while it's > not released yet, it's not a change we can make without substantially > delaying the final. > Option 2 feels rather lame in my book. > Option 3 feels pretty messy. Having 2 types of UDF, some keyspace-scoped and > some that are not would be super confusing. Saying that ll UDF are > keyspace-scoped feels limiting, and we would still be somewhat inconsistent > with our existing hard-coded functions that are global. > Which leaves option 1 which might be the most pragmatic. Having to check that > UDTs are not used before allowing keyspace drop don't sound like a huge deal > to me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9304) COPY TO improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970961#comment-14970961 ] Brian Hess commented on CASSANDRA-9304: [~Stefania] have you re-run the benchmark that [~dkua] performed above (or something similar) - specifically, comparing the "old version" to this new version (and to the cassandra-unloader (https://github.com/brianmhess/cassandra-loader))? What performance improvement do we see? > COPY TO improvements > > > Key: CASSANDRA-9304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9304 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Stefania >Priority: Minor > Labels: cqlsh > Fix For: 3.x, 2.1.x, 2.2.x > > > COPY FROM has gotten a lot of love. COPY TO not so much. One obvious > improvement could be to parallelize reading and writing (write one page of > data while fetching the next). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8394) Cassandra 3.0 Auth changes
[ https://issues.apache.org/jira/browse/CASSANDRA-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970978#comment-14970978 ] Sam Tunnicliffe commented on CASSANDRA-8394: sounds reasonable to me > Cassandra 3.0 Auth changes > -- > > Key: CASSANDRA-8394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8394 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Sam Tunnicliffe > Labels: docs-impacting > Fix For: 3.x > > > This will be the task that will group all the 3.0 Auth changes, of which we > need quite some: > 1. Implement Roles (CASSANDRA-7653) > 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator > SASL-only, and support full SASL capabilities (incl. proxy authentication - > see CASSANDRA-7686, CASSANDRA-8068) > 3. Remove the current simplistic permissions cache with > implementation-specific user/credentials/permissions caches, at least in the > implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194) > 4. Consider adding a way to split superuser-ness and the rights to manage > users (CASSANDRA-7216, CASSANDRA-8650) > 5. Add permissions for types and functions (CASSANDRA-7557) > 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082) > 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10576) Thrift CAS on static columns doesn't work as expected
Sam Tunnicliffe created CASSANDRA-10576: --- Summary: Thrift CAS on static columns doesn't work as expected Key: CASSANDRA-10576 URL: https://issues.apache.org/jira/browse/CASSANDRA-10576 Project: Cassandra Issue Type: Bug Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Fix For: 3.0.0 Although the thrift cas call works as expected for dynamic column families, using it on tables with statically defined columns produces unexpected results. The problem, in {{ThriftCASRequest}}, is that while the {{expected}} partition contains a static row, the {{current}} partition has been processed by {{ThriftResultsMerger}} during the read, converting the static columns to clusterings. If {{expected}} contains only a static row, no further checking is carried out, {{appliesTo}} erroneously returns true and the conditional update is performed regardless of the current state of the partition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71d9dba0 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71d9dba0 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71d9dba0 Branch: refs/heads/trunk Commit: 71d9dba063b0e669f12afef9fbb3efcb9cfacdd3 Parents: e43fbe0 535c3ac Author: Robert StuppAuthored: Fri Oct 23 14:44:32 2015 +0200 Committer: Robert Stupp Committed: Fri Oct 23 14:44:32 2015 +0200 -- CHANGES.txt | 1 + conf/cassandra.yaml | 2 + .../cassandra/config/EncryptionOptions.java | 1 + .../org/apache/cassandra/transport/Server.java | 75 ++-- .../service/NativeTransportServiceTest.java | 18 + 5 files changed, 90 insertions(+), 7 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/71d9dba0/CHANGES.txt -- diff --cc CHANGES.txt index 789a9d7,67e06ca..2ecad90 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,5 +1,11 @@@ +3.2 + * Added graphing option to cassandra-stress (CASSANDRA-7918) + * Abort in-progress queries that time out (CASSANDRA-7392) + * Add transparent data encryption core classes (CASSANDRA-9945) + + 3.0 + * Support encrypted and plain traffic on the same port (CASSANDRA-10559) * Fix handling of range tombstones when reading old format sstables (CASSANDRA-10360) * Aggregate with Initial Condition fails with C* 3.0 (CASSANDRA-10367) Merged from 2.2:
[jira] [Commented] (CASSANDRA-8653) Upgrading to trunk with auth throws exception
[ https://issues.apache.org/jira/browse/CASSANDRA-8653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970948#comment-14970948 ] Sylvain Lebresne commented on CASSANDRA-8653: - This ticket mentions trunk, but any reason to think 3.0 is immune to that? If not, we should mark that for 3.0.0 (and figure out if there is a real problem or not). > Upgrading to trunk with auth throws exception > - > > Key: CASSANDRA-8653 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8653 > Project: Cassandra > Issue Type: Bug >Reporter: Philip Thompson >Assignee: Sam Tunnicliffe > Fix For: 3.x > > Attachments: node1.log, node2.log, node3.log > > > When running Sam's upgrade_internal_auth_dtest, I am seeing the following > exception (amongst others) in the log file of the second node to be upgraded > to trunk from 2.1: > {code} > ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java:170 - > Exception in thread Thread[GossipStage:1,5,main] > java.lang.NoClassDefFoundError: > org/apache/cassandra/transport/Event$TopologyChange$Change > at > org.apache.cassandra.transport.Server$EventNotifier.onJoinCluster(Server.java:374) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1668) > ~[main/:na] > at > org.apache.cassandra.service.StorageService.onChange(StorageService.java:1384) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.doOnChangeNotifications(Gossiper.java:1094) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.applyNewStates(Gossiper.java:1076) > ~[main/:na] > at > org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1034) > ~[main/:na] > at > org.apache.cassandra.gms.GossipDigestAckVerbHandler.doVerb(GossipDigestAckVerbHandler.java:58) > ~[main/:na] > 1554 - Node /127.0.0.1 state jump to normal > ERROR [GossipStage:1] 2015-01-20 13:46:21,679 CassandraDaemon.java > :170 - Exception in thread Thread[GossipStage:1,5,main] > java.lang.NoClassDefFoundError: org/apache/cassandra/transport/Eve > nt$TopologyChange$Change > at org.apache.cassandra.transport.Server$EventNotifier.onJ > oinCluster(Server.java:374) ~[main/:na] > at org.apache.cassandra.service.StorageService.handleState > Normal(StorageService.java:1668) ~[main/:na] > at org.apache.cassandra.service.StorageService.onChange(St > orageService.java:1384) ~[main/:na] > at org.apache.cassandra.gms.Gossiper.doOnChangeNotificatio > ns(Gossiper.java:1094) ~[main/:na] > at org.apache.cassandra.gms.Gossiper.applyNewStates(Gossip > er.java:1076) ~[main/:na] > at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gos > siper.java:1034) ~[main/:na] > at org.apache.cassandra.gms.GossipDigestAckVerbHandler.doV > erb(GossipDigestAckVerbHandler.java:58) ~[main/:na] > at > org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) > ~[main/:na] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > ~[na:1.7.0_67] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > ~[na:1.7.0_67] > at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_67] > Caused by: java.lang.ClassNotFoundException: > org.apache.cassandra.transport.Event$TopologyChange$Change > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > ~[na:1.7.0_67] > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > ~[na:1.7.0_67] > at java.security.AccessController.doPrivileged(Native Method) > ~[na:1.7.0_67] > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > ~[na:1.7.0_67] > at java.lang.ClassLoader.loadClass(ClassLoader.java:425) > ~[na:1.7.0_67] > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > ~[na:1.7.0_67] > at java.lang.ClassLoader.loadClass(ClassLoader.java:358) > ~[na:1.7.0_67] > ... 11 common frames omitted > WARN [Thread-10] 2015-01-20 13:46:34,500 IncomingTcpConnection.java:91 - > UnknownColumnFamilyException reading from socket; closing > org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find > cfId=5f2fbdad-91f1-3946-bd25-d5da3a5c35ec > at > org.apache.cassandra.db.ColumnFamilySerializer.deserializeCfId(ColumnFamilySerializer.java:164) > ~[main/:na] > at > org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:97) > ~[main/:na] > at > org.apache.cassandra.db.Mutation$MutationSerializer.deserializeOneCf(Mutation.java:322) > ~[main/:na] > at > org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:302) > ~[main/:na] > at >
[jira] [Created] (CASSANDRA-10577) Fix cqlsh COPY commands that use NULL
Jim Witschey created CASSANDRA-10577: Summary: Fix cqlsh COPY commands that use NULL Key: CASSANDRA-10577 URL: https://issues.apache.org/jira/browse/CASSANDRA-10577 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Assignee: Stefania Fix For: 3.0.0 Looks like this commit: https://github.com/apache/cassandra/commit/806378c8c295fb062f94eb8bf0f719b398d27745 broke some of the behavior of cqlsh COPY: http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/280/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_null_as_null_indicator/history/ http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/280/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_undefined_as_null_indicator/history/ The NULL tests are the only ones that fail, so it doesn't look like any other parts of it are broken: http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/280/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8394) Cassandra 3.0 Auth changes
[ https://issues.apache.org/jira/browse/CASSANDRA-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970942#comment-14970942 ] Sylvain Lebresne commented on CASSANDRA-8394: - All the subtasks for this are closed and the remaining ones from the description are not gonna make 3.0 at this point. Should we just close this (and deal with CASSANDRA-8163 and CASSANDRA-7715 on their own). > Cassandra 3.0 Auth changes > -- > > Key: CASSANDRA-8394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8394 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Sam Tunnicliffe > Labels: docs-impacting > Fix For: 3.x > > > This will be the task that will group all the 3.0 Auth changes, of which we > need quite some: > 1. Implement Roles (CASSANDRA-7653) > 2. Merge ISaslAwareAuthenticator and IAuthenticator, making IAuthenticator > SASL-only, and support full SASL capabilities (incl. proxy authentication - > see CASSANDRA-7686, CASSANDRA-8068) > 3. Remove the current simplistic permissions cache with > implementation-specific user/credentials/permissions caches, at least in the > implementation we ship with C* (CASSANDRA-7715, CASSANDRA-8194) > 4. Consider adding a way to split superuser-ness and the rights to manage > users (CASSANDRA-7216, CASSANDRA-8650) > 5. Add permissions for types and functions (CASSANDRA-7557) > 6. Consider re-introducing the TRUNCATE permission (CASSANDRA-8082) > 7. Re-introduce the DESCRIBE permission (CASSANDRA-8163) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8959) More efficient frozen UDT, tuple and collection serialization format
[ https://issues.apache.org/jira/browse/CASSANDRA-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-8959: Summary: More efficient frozen UDT, tuple and collection serialization format (was: More efficient frozen UDT and tuple serialization format) > More efficient frozen UDT, tuple and collection serialization format > > > Key: CASSANDRA-8959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8959 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko > Labels: performance > Fix For: 3.x > > > The current serialization format for UDTs has a fixed overhead of 4 bytes per > defined field (encoding the size of the field). > It is inefficient for sparse UDTs - ones with many defined fields, but few of > them present. We could keep a bitset to indicate the missing fields, if any. > It's sub-optimal for encoding UDTs with all the values present as well. We > could use varint encoding for the field sizes of blob/text fields and encode > 'fixed' sized types directly, without the 4-bytes size prologue. > That or something more brilliant. Any improvement right now is lhf. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10344) Optimize ReadResponse
[ https://issues.apache.org/jira/browse/CASSANDRA-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-10344. -- Resolution: Later While we'll want to continue looking at optimizing ReadResponse, the method proposed by this ticket/patch doesn't clearly show a benefit (at least not on some basic workload) and it implies changes to inter-node serialization format, which makes it harder to do in some minor release. So for now, closing as "later". > Optimize ReadResponse > - > > Key: CASSANDRA-10344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10344 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 3.x > > > The handling of {{ReadResponse}} has quite a bit of inefficiencies. The way > it works is based on constraints from early version of CASSANDRA-8099, but > this doesn't make sense anymore. This is particularly true for local response > where we fully serialize the response in memory to deserialize it a short > time later. But > # serialization/deserialization takes times, more than necessary in that case > # we serialize in a {{DataInputBuffer}} with a default initial size, which > for largish response might require a few somewhat costly resizing. > So, since we're materializing the full result in memory anyway, it should > quite a lot more efficient to materialize it in a simple list of > {{ImmutableBTreePartition}} in that case. > To a lesser extend, the serialization of {{ReadResponse}} that go over the > wire is probably not ideal either. Due to current assumptions of > {{MessagingService}}, we need to know the full serialized size of every > response upfront, which means we do have to materialize results in memory in > this case too. Currently, we do so by serialializing the full response in > memory first, and then writing that result. Here again, the serialization in > memory might require some resizing/copying, and we're fundamentally copying > things twice (this could be especially costly with largish user values). So > here too I suggest to materialize the result in a list of > {{ImmutableBTreePartition}}, compute the serialized size from it and then > serialize it. This also allow to do better sizing of our data structures on > the receiving side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)