[jira] [Comment Edited] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1
[
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071415#comment-14071415
]
Marcus Eriksson edited comment on CASSANDRA-7593 at 7/23/14 6:32 AM:
-
The code around the first AE has not changed in 2.1, so I guess the problem is
when we collect the max/min col names, either during compaction or flushing
was (Author: krummas):
Hmm, could you post datamodel and queries? And (full) logs from the node.
The code around the first AE has not changed in 2.1, so I guess the problem is
when we collect the max/min col names, either during compaction or flushing
> Errors when upgrading through several versions to 2.1
> -
>
> Key: CASSANDRA-7593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
> Project: Cassandra
> Issue Type: Bug
> Environment: java 1.7
>Reporter: Russ Hatch
>
> I'm seeing two different errors cropping up in the dtest which upgrades a
> cluster through several versions.
> This is the more common error:
> {noformat}
> ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 -
> Exception in thread Thread[GossipStage:10,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
> ~[main/:na]
> at
> org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
> ~[main/:na]
> at
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
> ~[main/:na]
> at
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345)
> ~[main/:na]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
> ~[main/:na]
> at
> org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
> ~[main/:na]
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.(OutboundTcpConnectionPool.java:51)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
> ~[main/:na]
> at
> org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40)
> ~[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_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> {noformat}
> The same test sometimes fails with this exception instead:
> {noformat}
> ERROR [CompactionExecutor:4] 2014-07-22 16:18:21,008 CassandraDaemon.java:168
> - Exception in thread Thread[CompactionExecutor:4,1,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@7059d3e9
> rejected from
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@108f1504[Terminated,
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 95]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoo
[jira] [Commented] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1
[
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071415#comment-14071415
]
Marcus Eriksson commented on CASSANDRA-7593:
Hmm, could you post datamodel and queries? And (full) logs from the node.
The code around the first AE has not changed in 2.1, so I guess the problem is
when we collect the max/min col names, either during compaction or flushing
> Errors when upgrading through several versions to 2.1
> -
>
> Key: CASSANDRA-7593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
> Project: Cassandra
> Issue Type: Bug
> Environment: java 1.7
>Reporter: Russ Hatch
>
> I'm seeing two different errors cropping up in the dtest which upgrades a
> cluster through several versions.
> This is the more common error:
> {noformat}
> ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 -
> Exception in thread Thread[GossipStage:10,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
> ~[main/:na]
> at
> org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
> ~[main/:na]
> at
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
> ~[main/:na]
> at
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
> ~[main/:na]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345)
> ~[main/:na]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
> ~[main/:na]
> at
> org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
> ~[main/:na]
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.(OutboundTcpConnectionPool.java:51)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
> ~[main/:na]
> at
> org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40)
> ~[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_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> {noformat}
> The same test sometimes fails with this exception instead:
> {noformat}
> ERROR [CompactionExecutor:4] 2014-07-22 16:18:21,008 CassandraDaemon.java:168
> - Exception in thread Thread[CompactionExecutor:4,1,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@7059d3e9
> rejected from
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@108f1504[Terminated,
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 95]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530)
> ~[na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619)
> ~[na:1.7.0_60]
> at
> org.apache.c
[jira] [Commented] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
[
https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071330#comment-14071330
]
graham sanderson commented on CASSANDRA-7546:
-
Note w.r.t. deletioninfo... I'm a bit confused about who owns what.
On 2.1 (And I'm not 100% sure of the exact semantics of when you need to use
HeapAllocator.instance vs pure heap allocation, since I haven't looked at the
2.1 code much)
{code}
if (inputDeletionInfoCopy == null)
inputDeletionInfoCopy =
cm.deletionInfo().copy(HeapAllocator.instance);
deletionInfo =
current.deletionInfo.copy().add(inputDeletionInfoCopy);
updater.allocated(deletionInfo.unsharedHeapSize() -
current.deletionInfo.unsharedHeapSize());
{code}
However, current.deletionInfo.copy() is not done with the HeapAllocator, and
the passed inputDeletionInfoCopy's ranges are RE-copied (without using
HeapAllocator.instance) on some code paths inside the .add() method but not
others
> AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
> -
>
> Key: CASSANDRA-7546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7546
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: graham sanderson
>Assignee: graham sanderson
> Attachments: 7546.20.txt, 7546.20_2.txt, 7546.20_3.txt,
> 7546.20_alt.txt, suggestion1.txt, suggestion1_21.txt
>
>
> In order to preserve atomicity, this code attempts to read, clone/update,
> then CAS the state of the partition.
> Under heavy contention for updating a single partition this can cause some
> fairly staggering memory growth (the more cores on your machine the worst it
> gets).
> Whilst many usage patterns don't do highly concurrent updates to the same
> partition, hinting today, does, and in this case wild (order(s) of magnitude
> more than expected) memory allocation rates can be seen (especially when the
> updates being hinted are small updates to different partitions which can
> happen very fast on their own) - see CASSANDRA-7545
> It would be best to eliminate/reduce/limit the spinning memory allocation
> whilst not slowing down the very common un-contended case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
[
https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071171#comment-14071171
]
graham sanderson commented on CASSANDRA-7546:
-
In case anyone is reading them, here is the latest output - note with the
current wasted work limit of 100, we actually kick in later except under the
higher contention loads, but doing a one time flip, actually do less work
overall...
{code}
[junit] --
[junit] 1 THREAD; ELEMENT SIZE 64
[junit]
[junit] Threads = 1 elements = 10 (of size 64) partitions = 1
[junit] original code:
[junit] Duration = 996ms maxConcurrency = 1
[junit] GC for PS Scavenge: 36 ms for 3 collections
[junit] Approx allocation = 563MB vs 8MB; ratio to raw data size =
70.37447428571429
[junit] loopRatio (closest to 1 best) 1.0 raw 10/10 counted 0/0
sync 0/0 up 0 down 0
[junit]
[junit] modified code:
[junit] Duration = 765ms maxConcurrency = 1
[junit] GC for PS Scavenge: 38 ms for 3 collections
[junit] Approx allocation = 590MB vs 8MB; ratio to raw data size =
73.67167714285715
[junit] loopRatio (closest to 1 best) 1.0 raw 10/10 counted 0/0
sync 0/0 up 0 down 0
[junit]
[junit]
[junit] Threads = 1 elements = 10 (of size 64) partitions = 16
[junit] original code:
[junit] Duration = 496ms maxConcurrency = 1
[junit] GC for PS Scavenge: 20 ms for 2 collections
[junit] Approx allocation = 448MB vs 8MB; ratio to raw data size =
55.95978857142857
[junit] loopRatio (closest to 1 best) 1.0 raw 10/10 counted 0/0
sync 0/0 up 0 down 0
[junit]
[junit] modified code:
[junit] Duration = 574ms maxConcurrency = 1
[junit] GC for PS Scavenge: 27 ms for 2 collections
[junit] Approx allocation = 485MB vs 8MB; ratio to raw data size =
60.56426285714286
[junit] loopRatio (closest to 1 best) 1.0 raw 10/10 counted 0/0
sync 0/0 up 0 down 0
[junit]
[junit]
[junit] Threads = 1 elements = 10 (of size 64) partitions = 256
[junit] original code:
[junit] Duration = 662ms maxConcurrency = 1
[junit] GC for PS Scavenge: 12 ms for 1 collections
[junit] Approx allocation = 333MB vs 8MB; ratio to raw data size =
41.59998095238095
[junit] loopRatio (closest to 1 best) 1.0 raw 10/10 counted 0/0
sync 0/0 up 0 down 0
[junit]
[junit] modified code:
[junit] Duration = 241ms maxConcurrency = 1
[junit] GC for PS Scavenge: 9 ms for 1 collections
[junit] Approx allocation = 349MB vs 8MB; ratio to raw data size =
43.65317619047619
[junit] loopRatio (closest to 1 best) 1.0 raw 10/10 counted 0/0
sync 0/0 up 0 down 0
[junit]
[junit]
[junit] Threads = 1 elements = 10 (of size 64) partitions = 1024
[junit] original code:
[junit] Duration = 222ms maxConcurrency = 1
[junit] GC for PS Scavenge: 11 ms for 1 collections
[junit] Approx allocation = 273MB vs 8MB; ratio to raw data size =
34.18085428571428
[junit] loopRatio (closest to 1 best) 1.0 raw 10/10 counted 0/0
sync 0/0 up 0 down 0
[junit]
[junit] modified code:
[junit] Duration = 234ms maxConcurrency = 1
[junit] GC for PS Scavenge: 10 ms for 1 collections
[junit] Approx allocation = 286MB vs 8MB; ratio to raw data size =
35.7883064
[junit] loopRatio (closest to 1 best) 1.0 raw 10/10 counted 0/0
sync 0/0 up 0 down 0
[junit]
[junit]
[junit] --
[junit] 100 THREADS; ELEMENT SIZE 64
[junit]
[junit] Threads = 100 elements = 10 (of size 64) partitions = 1
[junit] original code:
[junit] Duration = 1383ms maxConcurrency = 100
[junit] GC for PS Scavenge: 108 ms for 29 collections
[junit] Approx allocation = 9525MB vs 8MB; ratio to raw data size =
1189.0213895238096
[junit] loopRatio (closest to 1 best) 16.74471 raw 10/1674471 counted
0/0 sync 0/0 up 0 down 0
[junit]
[junit] modified code:
[junit] Duration = 1728ms maxConcurrency = 100
[junit] GC for PS Scavenge: 14 ms for 1 collections
[junit] Approx allocation = 572MB vs 8MB; ratio to raw data size =
71.49758761904762
[junit] loopRatio (closest to 1 best) 1.00011 raw 144/154 counted 0/0
sync 99856/99857 up 0 down 0
[junit]
[junit]
[junit] Threads = 100 elements = 10 (of size 64) partitions = 16
[junit] original code:
[junit] Duration = 223ms maxConcurrency = 100
[junit] GC for PS Scavenge: 24 ms for 2 collections
[junit] Approx allocation = 760MB vs 8MB; ratio to raw data size =
94.87286476190476
[junit] loopRatio (closest to 1 best) 1.88353 raw 10/188353 counted
0/0 syn
[jira] [Updated] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
[ https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] graham sanderson updated CASSANDRA-7546: Attachment: 7546.20_3.txt I made a new patch 7546.20_3.txt that seems to work quite well Open questions - Any need to expose the wasted work limit as config - Would it be nice to update a CF metric (presumably at flush time) with the fraction of rows which had "flipped" for the flushing memtable - What to do about deletion info - that is really a separate question > AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory > - > > Key: CASSANDRA-7546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7546 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: graham sanderson >Assignee: graham sanderson > Attachments: 7546.20.txt, 7546.20_2.txt, 7546.20_3.txt, > 7546.20_alt.txt, suggestion1.txt, suggestion1_21.txt > > > In order to preserve atomicity, this code attempts to read, clone/update, > then CAS the state of the partition. > Under heavy contention for updating a single partition this can cause some > fairly staggering memory growth (the more cores on your machine the worst it > gets). > Whilst many usage patterns don't do highly concurrent updates to the same > partition, hinting today, does, and in this case wild (order(s) of magnitude > more than expected) memory allocation rates can be seen (especially when the > updates being hinted are small updates to different partitions which can > happen very fast on their own) - see CASSANDRA-7545 > It would be best to eliminate/reduce/limit the spinning memory allocation > whilst not slowing down the very common un-contended case. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7582) 2.1 multi-dc upgrade errors
[
https://issues.apache.org/jira/browse/CASSANDRA-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071099#comment-14071099
]
Brandon Williams commented on CASSANDRA-7582:
-
Seems like anything in the system ks is fair game to silently ignore.
> 2.1 multi-dc upgrade errors
> ---
>
> Key: CASSANDRA-7582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7582
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Ryan McGuire
>Assignee: Russ Hatch
>Priority: Critical
> Fix For: 2.1.0
>
>
> Multi-dc upgrade [was working from 2.0 -> 2.1 fairly
> recently|http://cassci.datastax.com/job/cassandra_upgrade_dtest/55/testReport/upgrade_through_versions_test/TestUpgrade_from_cassandra_2_0_latest_tag_to_cassandra_2_1_HEAD/],
> but is currently failing.
> Running
> upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_0_HEAD_to_cassandra_2_1_HEAD.bootstrap_multidc_test
> I get the following errors when starting 2.1 upgraded from 2.0:
> {code}
> ERROR [main] 2014-07-21 23:54:20,862 CommitLog.java:143 - Commit log replay
> failed due to replaying a mutation for a missing table. This error can be
> ignored by providing -Dcassandra.commitlog.stop_on_missing_tables=false on
> the command line
> ERROR [main] 2014-07-21 23:54:20,869 CassandraDaemon.java:474 - Exception
> encountered during startup
> java.lang.RuntimeException:
> org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find
> cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
> [main/:na]
> Caused by: org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't
> find cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004
> 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:353)
> ~[main/:na]
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:333)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:365)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:98)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:137)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:115)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7592) Ownership changes can violate consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-7592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071095#comment-14071095 ] Brandon Williams commented on CASSANDRA-7592: - bq. This could be solved by continuing writes to the old replica for some time (maybe ring delay) after the ownership changes. That seems reasonable. We could also make the 'joined' announcement both active (rpc) and passive (gossip) like schema to narrow the window quite a bit. > Ownership changes can violate consistency > - > > Key: CASSANDRA-7592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7592 > Project: Cassandra > Issue Type: Improvement >Reporter: Richard Low > > CASSANDRA-2434 goes a long way to avoiding consistency violations when > growing a cluster. However, there is still a window when consistency can be > violated when switching ownership of a range. > Suppose you have replication factor 3 and all reads and writes at quorum. The > first part of the ring looks like this: > Z: 0 > A: 100 > B: 200 > C: 300 > Choose two random coordinators, C1 and C2. Then you bootstrap node X at token > 50. > Consider the token range 0-50. Before bootstrap, this is stored on A, B, C. > During bootstrap, writes go to X, A, B, C (and must succeed on 3) and reads > choose two from A, B, C. After bootstrap, the range is on X, A, B. > When the bootstrap completes, suppose C1 processes the ownership change at t1 > and C2 at t4. Then the following can give an inconsistency: > t1: C1 switches ownership. > t2: C1 performs write, so sends write to X, A, B. A is busy and drops the > write, but it succeeds because X and B return. > t3: C2 performs a read. It hasn’t done the switch and chooses A and C. > Neither got the write at t2 so null is returned. > t4: C2 switches ownership. > This could be solved by continuing writes to the old replica for some time > (maybe ring delay) after the ownership changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7593) Errors when upgrading through several versions to 2.1
[
https://issues.apache.org/jira/browse/CASSANDRA-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russ Hatch updated CASSANDRA-7593:
--
Description:
I'm seeing two different errors cropping up in the dtest which upgrades a
cluster through several versions.
This is the more common error:
{noformat}
ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 -
Exception in thread Thread[GossipStage:10,5,main]
java.lang.AssertionError: null
at
org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
~[main/:na]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
~[main/:na]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
~[main/:na]
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345)
~[main/:na]
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
~[main/:na]
at
org.apache.cassandra.net.OutboundTcpConnectionPool.(OutboundTcpConnectionPool.java:51)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
~[main/:na]
at
org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40)
~[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_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_60]
at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
{noformat}
The same test sometimes fails with this exception instead:
{noformat}
ERROR [CompactionExecutor:4] 2014-07-22 16:18:21,008 CassandraDaemon.java:168 -
Exception in thread Thread[CompactionExecutor:4,1,RMI Runtime]
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@7059d3e9
rejected from
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@108f1504[Terminated,
pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 95]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
~[na:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619)
~[na:1.7.0_60]
at
org.apache.cassandra.io.sstable.SSTableReader.scheduleTidy(SSTableReader.java:628)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableReader.tidy(SSTableReader.java:609)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableReader.releaseReference(SSTableReader.java:1596)
~[main/:na]
at
org.apache.cassandra.db.DataTracker.replaceReaders(DataTracker.java:354)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableRewriter.abort(SSTableRewriter.java:200)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:192)
~[main/:na]
at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
~[main/:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
~[main/:na]
at
org.apach
[jira] [Created] (CASSANDRA-7593) Errors when upgrading RandomPartitioner clusters to 2.1
Russ Hatch created CASSANDRA-7593:
-
Summary: Errors when upgrading RandomPartitioner clusters to 2.1
Key: CASSANDRA-7593
URL: https://issues.apache.org/jira/browse/CASSANDRA-7593
Project: Cassandra
Issue Type: Bug
Environment: java 1.7
Reporter: Russ Hatch
I'm seeing two different errors cropping up in the dtest which upgrades a
cluster using RandomPartitioner through several versions.
This is the more common error:
{noformat}
ERROR [GossipStage:10] 2014-07-22 13:14:30,028 CassandraDaemon.java:168 -
Exception in thread Thread[GossipStage:10,5,main]
java.lang.AssertionError: null
at
org.apache.cassandra.db.filter.SliceQueryFilter.shouldInclude(SliceQueryFilter.java:347)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.shouldInclude(QueryFilter.java:249)
~[main/:na]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:249)
~[main/:na]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:60)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
~[main/:na]
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:345)
~[main/:na]
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:293)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:302)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:60)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:263)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:514)
~[main/:na]
at
org.apache.cassandra.net.OutboundTcpConnectionPool.(OutboundTcpConnectionPool.java:51)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:522)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:536)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:689)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:663)
~[main/:na]
at
org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40)
~[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_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_60]
at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
{noformat}
The same test sometimes fails with this exception instead:
{noformat}
ERROR [CompactionExecutor:4] 2014-07-22 16:18:21,008 CassandraDaemon.java:168 -
Exception in thread Thread[CompactionExecutor:4,1,RMI Runtime]
java.util.concurrent.RejectedExecutionException: Task
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@7059d3e9
rejected from
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@108f1504[Terminated,
pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 95]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
~[na:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530)
~[na:1.7.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619)
~[na:1.7.0_60]
at
org.apache.cassandra.io.sstable.SSTableReader.scheduleTidy(SSTableReader.java:628)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableReader.tidy(SSTableReader.java:609)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableReader.releaseReference(SSTableReader.java:1596)
~[main/:na]
at
org.apache.cassandra.db.DataTracker.replaceReaders(DataTracker.java:354)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableRewriter.abort(SSTableRewriter.java:200)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:192)
~[main/:na]
at
org.apache.cassandra.io.ut
[jira] [Updated] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7590:
Fix Version/s: (was: 2.1.1)
2.1.0
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
>Assignee: Robert Stupp
>Priority: Minor
> Labels: cql
> Fix For: 2.1.0
>
> Attachments: 7590-drop-index-npe-assert.txt
>
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7590:
Reviewer: Tyler Hobbs
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
>Assignee: Robert Stupp
>Priority: Minor
> Labels: cql
> Fix For: 2.1.0
>
> Attachments: 7590-drop-index-npe-assert.txt
>
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7592) Ownership changes can violate consistency
Richard Low created CASSANDRA-7592: -- Summary: Ownership changes can violate consistency Key: CASSANDRA-7592 URL: https://issues.apache.org/jira/browse/CASSANDRA-7592 Project: Cassandra Issue Type: Improvement Reporter: Richard Low CASSANDRA-2434 goes a long way to avoiding consistency violations when growing a cluster. However, there is still a window when consistency can be violated when switching ownership of a range. Suppose you have replication factor 3 and all reads and writes at quorum. The first part of the ring looks like this: Z: 0 A: 100 B: 200 C: 300 Choose two random coordinators, C1 and C2. Then you bootstrap node X at token 50. Consider the token range 0-50. Before bootstrap, this is stored on A, B, C. During bootstrap, writes go to X, A, B, C (and must succeed on 3) and reads choose two from A, B, C. After bootstrap, the range is on X, A, B. When the bootstrap completes, suppose C1 processes the ownership change at t1 and C2 at t4. Then the following can give an inconsistency: t1: C1 switches ownership. t2: C1 performs write, so sends write to X, A, B. A is busy and drops the write, but it succeeds because X and B return. t3: C2 performs a read. It hasn’t done the switch and chooses A and C. Neither got the write at t2 so null is returned. t4: C2 switches ownership. This could be solved by continuing writes to the old replica for some time (maybe ring delay) after the ownership changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-5901) Bootstrap should also make the data consistent on the new node
[ https://issues.apache.org/jira/browse/CASSANDRA-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070988#comment-14070988 ] Richard Low commented on CASSANDRA-5901: In particular, host replacement can violate consistency, even with CASSANDRA-2434. For example, if you always do quorum reads and writes and have replicas A, B, C, you'll always read the latest value, even if any one replica has missed a write. Suppose A did miss a write and then B fails and is replaced by D. D chooses where to stream from - there is no 'right' answer - so it can stream from A. Now A and D have old values and only C has the latest value. A quorum read that chooses A and D will give back stale data and violate expected consistency. If a repair was run on A and C after B had failed but before it was replaced with D, the consistency problem is eliminated. > Bootstrap should also make the data consistent on the new node > -- > > Key: CASSANDRA-5901 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5901 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: sankalp kohli >Priority: Minor > > Currently when we are bootstrapping a new node, it might bootstrap from a > node which does not have most upto date data. Because of this, we need to run > a repair after that. > Most people will always run the repair so it would help if we can provide a > parameter to bootstrap to run the repair once the bootstrap has finished. > It can also stop the node from responding to reads till repair has finished. > This could be another param as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7384) Collect metrics on queries by consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070960#comment-14070960 ] Richard Low commented on CASSANDRA-7384: Having relative counts per consistency level helps clients to check rates are as they expect. Also having the relative latencies would help to estimate the cost/benefit of changing consistency levels. I think it would be helpful. > Collect metrics on queries by consistency level > --- > > Key: CASSANDRA-7384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7384 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Vishy Kasar >Assignee: sankalp kohli >Priority: Minor > > We had cases where cassandra client users thought that they were doing > queries at one consistency level but turned out to be not correct. It will be > good to collect metrics on number of queries done at various consistency > level on the server. See the equivalent JIRA on java driver: > https://datastax-oss.atlassian.net/browse/JAVA-354 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7591) Add per consistency level read and write metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070941#comment-14070941 ] Richard Low commented on CASSANDRA-7591: And I've just found CASSANDRA-7384. Sorry for the noise. > Add per consistency level read and write metrics > > > Key: CASSANDRA-7591 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7591 > Project: Cassandra > Issue Type: Improvement >Reporter: Richard Low > > It would be helpful to have read and write metrics for each consistency level > to help clients track query rates per consistency level. It's quite common to > forget to set e.g. a config param in the client and use the wrong consistency > level. Right now the only way to find out from Cassandra is to use tracing. > It would also be helpful to track latencies for different consistency levels > to estimate the cost of e.g. switching from LOCAL_QUORUM to QUORUM reads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CASSANDRA-7591) Add per consistency level read and write metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Low resolved CASSANDRA-7591. Resolution: Duplicate Dupe of CASSANDRA-7384. > Add per consistency level read and write metrics > > > Key: CASSANDRA-7591 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7591 > Project: Cassandra > Issue Type: Improvement >Reporter: Richard Low > > It would be helpful to have read and write metrics for each consistency level > to help clients track query rates per consistency level. It's quite common to > forget to set e.g. a config param in the client and use the wrong consistency > level. Right now the only way to find out from Cassandra is to use tracing. > It would also be helpful to track latencies for different consistency levels > to estimate the cost of e.g. switching from LOCAL_QUORUM to QUORUM reads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7591) Add read and write metrics for each consistency level
Richard Low created CASSANDRA-7591: -- Summary: Add read and write metrics for each consistency level Key: CASSANDRA-7591 URL: https://issues.apache.org/jira/browse/CASSANDRA-7591 Project: Cassandra Issue Type: Improvement Reporter: Richard Low It would be helpful to have read and write metrics for each consistency level to help clients track query rates per consistency level. It's quite common to forget to set e.g. a config param in the client and use the wrong consistency level. Right now the only way to find out from Cassandra is to use tracing. It would also be helpful to track latencies for different consistency levels to estimate the cost of e.g. switching from LOCAL_QUORUM to QUORUM reads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7591) Add per consistency level read and write metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Low updated CASSANDRA-7591: --- Summary: Add per consistency level read and write metrics (was: Add read and write metrics for each consistency level) > Add per consistency level read and write metrics > > > Key: CASSANDRA-7591 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7591 > Project: Cassandra > Issue Type: Improvement >Reporter: Richard Low > > It would be helpful to have read and write metrics for each consistency level > to help clients track query rates per consistency level. It's quite common to > forget to set e.g. a config param in the client and use the wrong consistency > level. Right now the only way to find out from Cassandra is to use tracing. > It would also be helpful to track latencies for different consistency levels > to estimate the cost of e.g. switching from LOCAL_QUORUM to QUORUM reads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CASSANDRA-6596) Split out outgoing stream throughput within a DC and inter-DC
[ https://issues.apache.org/jira/browse/CASSANDRA-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita resolved CASSANDRA-6596. --- Resolution: Fixed 2.1.0 and above has fix for sstableloader so I back ported it also to cassandra-2.0 branch (ef894c2aad85fbb980be20f5c42f735966871d47). > Split out outgoing stream throughput within a DC and inter-DC > - > > Key: CASSANDRA-6596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6596 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremy Hanna >Assignee: Vijay >Priority: Minor > Fix For: 2.0.10, 2.1 beta1 > > Attachments: 0001-CASSANDRA-6596.patch > > > Currently the outgoing stream throughput setting doesn't differentiate > between when it goes to another node in the same DC and when it goes to > another DC across a potentially bandwidth limited link. It would be nice to > have that split out so that it could be tuned for each type of link. -- This message was sent by Atlassian JIRA (v6.2#6252)
[02/10] git commit: Follow up on CASSANDRA-6596
Follow up on CASSANDRA-6596 Add null check for sstableloader Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef894c2a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef894c2a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef894c2a Branch: refs/heads/cassandra-2.1.0 Commit: ef894c2aad85fbb980be20f5c42f735966871d47 Parents: 9906a4e Author: Yuki Morishita Authored: Tue Jul 22 16:14:14 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:14:14 2014 -0500 -- src/java/org/apache/cassandra/streaming/StreamManager.java | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef894c2a/src/java/org/apache/cassandra/streaming/StreamManager.java -- diff --git a/src/java/org/apache/cassandra/streaming/StreamManager.java b/src/java/org/apache/cassandra/streaming/StreamManager.java index 366f3ff..b5b1c7f 100644 --- a/src/java/org/apache/cassandra/streaming/StreamManager.java +++ b/src/java/org/apache/cassandra/streaming/StreamManager.java @@ -76,8 +76,11 @@ public class StreamManager implements StreamManagerMBean double interDCThroughput = ((double) DatabaseDescriptor.getInterDCStreamThroughputOutboundMegabitsPerSec()) * ONE_MEGA_BIT; mayUpdateThroughput(interDCThroughput, interDCLimiter); -isLocalDC = DatabaseDescriptor.getLocalDataCenter().equals( - DatabaseDescriptor.getEndpointSnitch().getDatacenter(peer)); +if (DatabaseDescriptor.getLocalDataCenter() != null && DatabaseDescriptor.getEndpointSnitch() != null) +isLocalDC = DatabaseDescriptor.getLocalDataCenter().equals( + DatabaseDescriptor.getEndpointSnitch().getDatacenter(peer)); +else +isLocalDC = true; } private void mayUpdateThroughput(double limit, RateLimiter rateLimiter)
[jira] [Commented] (CASSANDRA-7582) 2.1 multi-dc upgrade errors
[
https://issues.apache.org/jira/browse/CASSANDRA-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070913#comment-14070913
]
Benedict commented on CASSANDRA-7582:
-
We've dropped system.NodeIdInfo, but drain on 2.0 is a little bit broken and so
we don't end up with the clean CL we should do, and we barf when we see
mutations for this table. We should probably create a whitelist of cfIds we'll
accept being missing, as this will no doubt crop up in future as well.
> 2.1 multi-dc upgrade errors
> ---
>
> Key: CASSANDRA-7582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7582
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Ryan McGuire
>Assignee: Russ Hatch
>Priority: Critical
> Fix For: 2.1.0
>
>
> Multi-dc upgrade [was working from 2.0 -> 2.1 fairly
> recently|http://cassci.datastax.com/job/cassandra_upgrade_dtest/55/testReport/upgrade_through_versions_test/TestUpgrade_from_cassandra_2_0_latest_tag_to_cassandra_2_1_HEAD/],
> but is currently failing.
> Running
> upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_0_HEAD_to_cassandra_2_1_HEAD.bootstrap_multidc_test
> I get the following errors when starting 2.1 upgraded from 2.0:
> {code}
> ERROR [main] 2014-07-21 23:54:20,862 CommitLog.java:143 - Commit log replay
> failed due to replaying a mutation for a missing table. This error can be
> ignored by providing -Dcassandra.commitlog.stop_on_missing_tables=false on
> the command line
> ERROR [main] 2014-07-21 23:54:20,869 CassandraDaemon.java:474 - Exception
> encountered during startup
> java.lang.RuntimeException:
> org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find
> cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
> [main/:na]
> Caused by: org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't
> find cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004
> 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:353)
> ~[main/:na]
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:333)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:365)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:98)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:137)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:115)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[08/10] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e19431af Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e19431af Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e19431af Branch: refs/heads/trunk Commit: e19431afc8e69d28eadef6c8b346c6cf7bf4f580 Parents: 992a27e 3c05563 Author: Yuki Morishita Authored: Tue Jul 22 16:17:20 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:17:20 2014 -0500 -- --
[04/10] git commit: Follow up on CASSANDRA-6596
Follow up on CASSANDRA-6596 Add null check for sstableloader Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef894c2a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef894c2a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef894c2a Branch: refs/heads/trunk Commit: ef894c2aad85fbb980be20f5c42f735966871d47 Parents: 9906a4e Author: Yuki Morishita Authored: Tue Jul 22 16:14:14 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:14:14 2014 -0500 -- src/java/org/apache/cassandra/streaming/StreamManager.java | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef894c2a/src/java/org/apache/cassandra/streaming/StreamManager.java -- diff --git a/src/java/org/apache/cassandra/streaming/StreamManager.java b/src/java/org/apache/cassandra/streaming/StreamManager.java index 366f3ff..b5b1c7f 100644 --- a/src/java/org/apache/cassandra/streaming/StreamManager.java +++ b/src/java/org/apache/cassandra/streaming/StreamManager.java @@ -76,8 +76,11 @@ public class StreamManager implements StreamManagerMBean double interDCThroughput = ((double) DatabaseDescriptor.getInterDCStreamThroughputOutboundMegabitsPerSec()) * ONE_MEGA_BIT; mayUpdateThroughput(interDCThroughput, interDCLimiter); -isLocalDC = DatabaseDescriptor.getLocalDataCenter().equals( - DatabaseDescriptor.getEndpointSnitch().getDatacenter(peer)); +if (DatabaseDescriptor.getLocalDataCenter() != null && DatabaseDescriptor.getEndpointSnitch() != null) +isLocalDC = DatabaseDescriptor.getLocalDataCenter().equals( + DatabaseDescriptor.getEndpointSnitch().getDatacenter(peer)); +else +isLocalDC = true; } private void mayUpdateThroughput(double limit, RateLimiter rateLimiter)
[09/10] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e19431af Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e19431af Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e19431af Branch: refs/heads/cassandra-2.1 Commit: e19431afc8e69d28eadef6c8b346c6cf7bf4f580 Parents: 992a27e 3c05563 Author: Yuki Morishita Authored: Tue Jul 22 16:17:20 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:17:20 2014 -0500 -- --
[07/10] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3c055631 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3c055631 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3c055631 Branch: refs/heads/trunk Commit: 3c0556316b878e4ad69eee0587d99ca5e0b37495 Parents: e740c29 ef894c2 Author: Yuki Morishita Authored: Tue Jul 22 16:16:56 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:16:56 2014 -0500 -- --
[03/10] git commit: Follow up on CASSANDRA-6596
Follow up on CASSANDRA-6596 Add null check for sstableloader Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef894c2a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef894c2a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef894c2a Branch: refs/heads/cassandra-2.1 Commit: ef894c2aad85fbb980be20f5c42f735966871d47 Parents: 9906a4e Author: Yuki Morishita Authored: Tue Jul 22 16:14:14 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:14:14 2014 -0500 -- src/java/org/apache/cassandra/streaming/StreamManager.java | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef894c2a/src/java/org/apache/cassandra/streaming/StreamManager.java -- diff --git a/src/java/org/apache/cassandra/streaming/StreamManager.java b/src/java/org/apache/cassandra/streaming/StreamManager.java index 366f3ff..b5b1c7f 100644 --- a/src/java/org/apache/cassandra/streaming/StreamManager.java +++ b/src/java/org/apache/cassandra/streaming/StreamManager.java @@ -76,8 +76,11 @@ public class StreamManager implements StreamManagerMBean double interDCThroughput = ((double) DatabaseDescriptor.getInterDCStreamThroughputOutboundMegabitsPerSec()) * ONE_MEGA_BIT; mayUpdateThroughput(interDCThroughput, interDCLimiter); -isLocalDC = DatabaseDescriptor.getLocalDataCenter().equals( - DatabaseDescriptor.getEndpointSnitch().getDatacenter(peer)); +if (DatabaseDescriptor.getLocalDataCenter() != null && DatabaseDescriptor.getEndpointSnitch() != null) +isLocalDC = DatabaseDescriptor.getLocalDataCenter().equals( + DatabaseDescriptor.getEndpointSnitch().getDatacenter(peer)); +else +isLocalDC = true; } private void mayUpdateThroughput(double limit, RateLimiter rateLimiter)
[06/10] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3c055631 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3c055631 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3c055631 Branch: refs/heads/cassandra-2.1.0 Commit: 3c0556316b878e4ad69eee0587d99ca5e0b37495 Parents: e740c29 ef894c2 Author: Yuki Morishita Authored: Tue Jul 22 16:16:56 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:16:56 2014 -0500 -- --
[05/10] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3c055631 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3c055631 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3c055631 Branch: refs/heads/cassandra-2.1 Commit: 3c0556316b878e4ad69eee0587d99ca5e0b37495 Parents: e740c29 ef894c2 Author: Yuki Morishita Authored: Tue Jul 22 16:16:56 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:16:56 2014 -0500 -- --
[10/10] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6bc7f765 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6bc7f765 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6bc7f765 Branch: refs/heads/trunk Commit: 6bc7f76510c498d5570d99be01a169d2207a08a3 Parents: 5b8a6b6 e19431a Author: Yuki Morishita Authored: Tue Jul 22 16:17:40 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:17:40 2014 -0500 -- --
[01/10] git commit: Follow up on CASSANDRA-6596
Repository: cassandra Updated Branches: refs/heads/cassandra-2.0 9906a4e5d -> ef894c2aa refs/heads/cassandra-2.1 992a27e03 -> e19431afc refs/heads/cassandra-2.1.0 e740c2979 -> 3c0556316 refs/heads/trunk 5b8a6b63d -> 6bc7f7651 Follow up on CASSANDRA-6596 Add null check for sstableloader Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef894c2a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef894c2a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef894c2a Branch: refs/heads/cassandra-2.0 Commit: ef894c2aad85fbb980be20f5c42f735966871d47 Parents: 9906a4e Author: Yuki Morishita Authored: Tue Jul 22 16:14:14 2014 -0500 Committer: Yuki Morishita Committed: Tue Jul 22 16:14:14 2014 -0500 -- src/java/org/apache/cassandra/streaming/StreamManager.java | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef894c2a/src/java/org/apache/cassandra/streaming/StreamManager.java -- diff --git a/src/java/org/apache/cassandra/streaming/StreamManager.java b/src/java/org/apache/cassandra/streaming/StreamManager.java index 366f3ff..b5b1c7f 100644 --- a/src/java/org/apache/cassandra/streaming/StreamManager.java +++ b/src/java/org/apache/cassandra/streaming/StreamManager.java @@ -76,8 +76,11 @@ public class StreamManager implements StreamManagerMBean double interDCThroughput = ((double) DatabaseDescriptor.getInterDCStreamThroughputOutboundMegabitsPerSec()) * ONE_MEGA_BIT; mayUpdateThroughput(interDCThroughput, interDCLimiter); -isLocalDC = DatabaseDescriptor.getLocalDataCenter().equals( - DatabaseDescriptor.getEndpointSnitch().getDatacenter(peer)); +if (DatabaseDescriptor.getLocalDataCenter() != null && DatabaseDescriptor.getEndpointSnitch() != null) +isLocalDC = DatabaseDescriptor.getLocalDataCenter().equals( + DatabaseDescriptor.getEndpointSnitch().getDatacenter(peer)); +else +isLocalDC = true; } private void mayUpdateThroughput(double limit, RateLimiter rateLimiter)
[jira] [Updated] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-7590:
--
Priority: Minor (was: Major)
Fix Version/s: (was: 2.1.0)
2.1.1
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
>Assignee: Robert Stupp
>Priority: Minor
> Labels: cql
> Fix For: 2.1.1
>
> Attachments: 7590-drop-index-npe-assert.txt
>
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-6596) Split out outgoing stream throughput within a DC and inter-DC
[ https://issues.apache.org/jira/browse/CASSANDRA-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070899#comment-14070899 ] Jonathan Ellis commented on CASSANDRA-6596: --- Let's open a new ticket? > Split out outgoing stream throughput within a DC and inter-DC > - > > Key: CASSANDRA-6596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6596 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremy Hanna >Assignee: Vijay >Priority: Minor > Fix For: 2.0.10, 2.1 beta1 > > Attachments: 0001-CASSANDRA-6596.patch > > > Currently the outgoing stream throughput setting doesn't differentiate > between when it goes to another node in the same DC and when it goes to > another DC across a potentially bandwidth limited link. It would be nice to > have that split out so that it could be tuned for each type of link. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7527) Bump CQL version and update doc for 2.1
[ https://issues.apache.org/jira/browse/CASSANDRA-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070890#comment-14070890 ] Kristine Hahn commented on CASSANDRA-7527: -- Hi Jack, It's my understanding that https://cassandra.apache.org/doc/cql3/CQL.html is the official CQL doc. The C* team calls it "the spec". That doc is installed in textile format with Cassandra source in the docs/cql directory. But I don't find any links to that web page on the Apache Cassandra site - I don't know who updates that Apache site. I don't think DataStax has anything to do with it. I'd send criticisms to Jonathan. Maybe you could send criticisms to the Apache site webmaster, but I wouldn't say anything about the link to the Datastax doc (don't want anybody open source maniac removing it!) Yes, the 2.1 docs will be released when 2.1 is released (on July 28 I heard). Kris On Tue, Jul 22, 2014 at 1:08 PM, Jack Krupansky (JIRA) wrote: > Bump CQL version and update doc for 2.1 > --- > > Key: CASSANDRA-7527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7527 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Tyler Hobbs > Fix For: 2.1.0 > > Attachments: 7527-v2.txt, 7527.txt > > > It appears we forgot to bump the CQL version for new 2.1 features (UDT, tuple > type, collection indexing), nor did we update the textile doc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CASSANDRA-6596) Split out outgoing stream throughput within a DC and inter-DC
[ https://issues.apache.org/jira/browse/CASSANDRA-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita reopened CASSANDRA-6596: --- Reopening this because it breaks sstableloader. Since sstableloader does not load cassandra.yaml, StreamRateLimiter throws NPE when accessing DatabaseDescriptor. > Split out outgoing stream throughput within a DC and inter-DC > - > > Key: CASSANDRA-6596 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6596 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremy Hanna >Assignee: Vijay >Priority: Minor > Fix For: 2.0.10, 2.1 beta1 > > Attachments: 0001-CASSANDRA-6596.patch > > > Currently the outgoing stream throughput setting doesn't differentiate > between when it goes to another node in the same DC and when it goes to > another DC across a potentially bandwidth limited link. It would be nice to > have that split out so that it could be tuned for each type of link. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7590:
Attachment: 7590-drop-index-npe-assert.txt
Patch for both NPE on {{DROP INDEX}} on non-existing KS and AE on {{DROP INDEX
IF EXISTS}} on non-existing index.
Now it just does not send a schema change result message, if the index does not
exist.
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
>Assignee: Robert Stupp
> Labels: cql
> Fix For: 2.1.0
>
> Attachments: 7590-drop-index-npe-assert.txt
>
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070871#comment-14070871
]
Robert Stupp commented on CASSANDRA-7590:
-
[~brandon.williams] for review?
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
>Assignee: Robert Stupp
> Labels: cql
> Fix For: 2.1.0
>
> Attachments: 7590-drop-index-npe-assert.txt
>
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070844#comment-14070844
]
Robert Stupp commented on CASSANDRA-7590:
-
Eh - even worse - DROP INDEX on a non-existing KS produces NPE...
{noformat}
cqlsh> DROP INDEX IF EXISTS test.fake_index;
{noformat}
Fix is simple - some minutes until patch :)
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
> Labels: cql
> Fix For: 2.1.0
>
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp reassigned CASSANDRA-7590:
---
Assignee: Robert Stupp
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
>Assignee: Robert Stupp
> Labels: cql
> Fix For: 2.1.0
>
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7527) Bump CQL version and update doc for 2.1
[
https://issues.apache.org/jira/browse/CASSANDRA-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070795#comment-14070795
]
Jack Krupansky commented on CASSANDRA-7527:
---
What is the official Apache landing place for the CQL doc? If I google
"cassandra cql3", I find:
https://cassandra.apache.org/doc/cql3/CQL.html
But I don't find any links to that web page on the Apache Cassandra site - just
links to the DataStax doc.
Also if I look in the doc/CQL3 directory on the Apache site I see the following
{code}
CQL-1.2.html2014-03-19 16:47 81K
CQL-2.0.html2014-06-30 09:09 92K
CQL.css 2012-07-13 09:15 2.0K
CQL.html2014-06-30 09:09 92K
{code}
Will there be a CQL-2.1.html for the c\* 2.1 doc CQL, or will CQL-2.0.html be
overwritten?
And again I was unable to find any links to CQL-2.0.html or CQL-1.2.html on the
Apache site. I mean, it would be nice to have a clean web link to consult 2.0
doc even when 2.1 goes GA. I tried to google "Cassandra 2.0 cql doc", but it
doesn't find that CQL-2.0.html page or find the 1.2 page when I search for 1.2.
Finally, will this official Apache C\* 2.1 CQL doc be available on the web real
soon, or only at 2.1 GA?
> Bump CQL version and update doc for 2.1
> ---
>
> Key: CASSANDRA-7527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7527
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Tyler Hobbs
> Fix For: 2.1.0
>
> Attachments: 7527-v2.txt, 7527.txt
>
>
> It appears we forgot to bump the CQL version for new 2.1 features (UDT, tuple
> type, collection indexing), nor did we update the textile doc
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dan jatnieks updated CASSANDRA-7588:
Description:
This worked in 2.1 RC1
{noformat}
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native protocol
v3]
Use HELP for help.
cqlsh> use k1;
cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS 'hdtv';
id| description
---+-
29412 |32-inch LED HDTV (black)
34134 | 120-inch 1080p 3D plasma TV
(2 rows)
{noformat}
But fails on 2.1:
{noformat}
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native protocol
v3]
Use HELP for help.
cqlsh> use k1;
cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS 'hdtv';
list index out of range
cqlsh:k1>
{noformat}
This is using the example from the blog post
http://www.datastax.com/dev/blog/cql-in-2-1
A more complete repro:
{noformat}
cqlsh:k1>
cqlsh:k1> CREATE KEYSPACE cat_index_test
... WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
1};
cqlsh:k1> USE cat_index_test;
cqlsh:cat_index_test>
cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
... id int PRIMARY KEY,
... description text,
... price int,
... categories set,
... features map
... );
cqlsh:cat_index_test>
cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
products(categories);
cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
products(features);
cqlsh:cat_index_test>
cqlsh:cat_index_test> INSERT INTO products(id, description, price,
categories, features)
...VALUES (34134,
...'120-inch 1080p 3D plasma TV',
...,
...{'tv', '3D', 'hdtv'},
...{'screen' : '120-inch', 'refresh-rate' :
'400hz', 'techno' : 'plasma'});
cqlsh:cat_index_test>
cqlsh:cat_index_test> INSERT INTO products(id, description, price,
categories, features)
...VALUES (29412,
...'32-inch LED HDTV (black)',
...929,
...{'tv', 'hdtv'},
...{'screen' : '32-inch', 'techno' : 'LED'});
cqlsh:cat_index_test>
cqlsh:cat_index_test> INSERT INTO products(id, description, price,
categories, features)
...VALUES (38471,
...'32-inch LCD TV',
...110,
...{'tv', 'used'},
...{'screen' : '32-inch', 'techno' : 'LCD'});
cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
CONTAINS 'hdtv';
list index out of range
cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
CONTAINS '32-inch';
list index out of range
cqlsh:cat_index_test> DROP INDEX feat_index;
cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
cqlsh:cat_index_test>
cqlsh:cat_index_test> SELECT id, description
... FROM products
... WHERE features CONTAINS KEY 'refresh-rate';
list index out of range
{noformat}
This appears to be a cqlsh issue, since these queries still work when executed
using DevCenter.
was:
This worked in 2.1 RC1
{noformat}
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native protocol
v3]
Use HELP for help.
cqlsh> use k1;
cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS 'hdtv';
id| description
---+-
29412 |32-inch LED HDTV (black)
34134 | 120-inch 1080p 3D plasma TV
(2 rows)
{noformat}
But fails with RC4:
{noformat}
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native protocol
v3]
Use HELP for help.
cqlsh> use k1;
cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS 'hdtv';
list index out of range
cqlsh:k1>
{noformat}
This is using the example from the blog post
http://www.datastax.com/dev/blog/cql-in-2-1
A more complete repro:
{noformat}
cqlsh:k1>
cqlsh:k1> CREATE KEYSPACE cat_index_test
... WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
1};
cqlsh:k1> USE cat_index_test;
cqlsh:cat_index_test>
cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
... id int PRIMARY KEY,
... description text,
... price int,
... categories set,
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070789#comment-14070789
]
dan jatnieks commented on CASSANDRA-7588:
-
[~brandon.williams] You're right, I was on cassandra-2.1, and I was going by
what cqlsh reported. Sorry for the confusion. And, yes, I tagged as rc3 because
I didn't find rc4.
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
>Assignee: Robert Stupp
> Labels: cqlsh
> Fix For: 2.1.1
>
> Attachments: 7588-cqlsh-6910-contains-allow-filtering.txt
>
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (CASSANDRA-5901) Bootstrap should also make the data consistent on the new node
[ https://issues.apache.org/jira/browse/CASSANDRA-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli reopened CASSANDRA-5901: -- Reopening as we can hit this for normal host replacement which is not fixed in CASSANDRA-2434 > Bootstrap should also make the data consistent on the new node > -- > > Key: CASSANDRA-5901 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5901 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: sankalp kohli >Priority: Minor > > Currently when we are bootstrapping a new node, it might bootstrap from a > node which does not have most upto date data. Because of this, we need to run > a repair after that. > Most people will always run the repair so it would help if we can provide a > parameter to bootstrap to run the repair once the bootstrap has finished. > It can also stop the node from responding to reads till repair has finished. > This could be another param as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7590:
Fix Version/s: 2.1.0
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
> Labels: cql
> Fix For: 2.1.0
>
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070733#comment-14070733
]
Brandon Williams commented on CASSANDRA-7590:
-
Since I was just on 2.1, here you go:
{noformat}
ERROR 19:15:35 Unexpected exception during request
java.lang.AssertionError: null
at
org.apache.cassandra.cql3.statements.DropIndexStatement.columnFamily(DropIndexStatement.java:117)
~[main/:na]
at
org.apache.cassandra.cql3.statements.DropIndexStatement.changeEvent(DropIndexStatement.java:63)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:73)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:187)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:206)
~[main/:na]
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:118)
~[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:421)
[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:318)
[main/:na]
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:103)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:31)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:323)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[na:1.7.0_60]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:162)
[main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
{noformat}
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
> Labels: cql
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[2/3] git commit: Add ALLOW FILTERING and CONTAINS to cqlsh post-6910
Add ALLOW FILTERING and CONTAINS to cqlsh post-6910
Patch by Robert Stupp, reviewed by brandonwilliams for CASSANDRA-7588
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/992a27e0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/992a27e0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/992a27e0
Branch: refs/heads/trunk
Commit: 992a27e03fd96c785f0fdf40e78a19de8fc4c759
Parents: e0b8887
Author: Brandon Williams
Authored: Tue Jul 22 14:09:04 2014 -0500
Committer: Brandon Williams
Committed: Tue Jul 22 14:09:04 2014 -0500
--
pylib/cqlshlib/cql3handling.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/992a27e0/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 3d489d3..a676319 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -595,13 +595,14 @@ syntax_rules += r'''
( "WHERE" )?
( "ORDER" "BY" ( ","
)* )?
( "LIMIT" limit= )?
+ ( "ALLOW" "FILTERING" )?
;
::= ( "AND" )*
;
- ::= [rel_lhs]= ( "=" | "<" | ">" | "<=" | ">=" )
+ ::= [rel_lhs]= ( "=" | "<" | ">" | "<=" | ">=" | "CONTAINS"
)
| token="TOKEN" "(" [rel_tokname]=
( "," [rel_tokname]= )*
- ")" ("=" | "<" | ">" | "<=" | ">=")
+ ")" ("=" | "<" | ">" | "<=" | ">=" | "CONTAINS")
| [rel_lhs]= "IN" "(" ( "," )* ")"
;
::= "DISTINCT"? ("AS" )? (","
("AS" )?)*
[jira] [Resolved] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-7588.
-
Resolution: Fixed
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
>Assignee: Robert Stupp
> Labels: cqlsh
> Fix For: 2.1.1
>
> Attachments: 7588-cqlsh-6910-contains-allow-filtering.txt
>
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7588:
Reviewer: Brandon Williams
Since Version: (was: 2.1 rc4)
Fix Version/s: 2.1.1
Assignee: Robert Stupp
Alright, committed this. Please open a new ticket if you actually can repro
this on rc4.
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
>Assignee: Robert Stupp
> Labels: cqlsh
> Fix For: 2.1.1
>
> Attachments: 7588-cqlsh-6910-contains-allow-filtering.txt
>
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CASSANDRA-6905) commitlog archive replay should attempt to replay all mutations
[ https://issues.apache.org/jira/browse/CASSANDRA-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ala' Alkhaldi reassigned CASSANDRA-6905: Assignee: Ala' Alkhaldi > commitlog archive replay should attempt to replay all mutations > --- > > Key: CASSANDRA-6905 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6905 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Ala' Alkhaldi >Priority: Minor > Fix For: 2.0.10 > > > Currently when you do a point-in-time recovery using archived commitlogs, the > replay stops when the time is encountered, but since timestamps are supplied > by the client we can't guarantee the segment is ordered by timestamp, so some > mutations can be lost. Instead we could continue past the given timestamp, > and just filter out any mutations greater than it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
[
https://issues.apache.org/jira/browse/CASSANDRA-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070723#comment-14070723
]
Robert Stupp commented on CASSANDRA-7590:
-
[~hddn] : Can you have a stacktrace from the server log file?
> java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
> --
>
> Key: CASSANDRA-7590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Hanh Dang
> Labels: cql
>
> To reproduce:
> cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
> 'replication_factor':1};
> cqlsh> USE test;
> cqlsh:test> DROP INDEX IF EXISTS fake_index;
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[3/3] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5b8a6b63 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5b8a6b63 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5b8a6b63 Branch: refs/heads/trunk Commit: 5b8a6b63d9376ac47c0bcec40e52ad05560594bc Parents: dc84af4 992a27e Author: Brandon Williams Authored: Tue Jul 22 14:09:53 2014 -0500 Committer: Brandon Williams Committed: Tue Jul 22 14:09:53 2014 -0500 -- pylib/cqlshlib/cql3handling.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --
[1/3] git commit: Add ALLOW FILTERING and CONTAINS to cqlsh post-6910
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 e0b88878c -> 992a27e03
refs/heads/trunk dc84af47c -> 5b8a6b63d
Add ALLOW FILTERING and CONTAINS to cqlsh post-6910
Patch by Robert Stupp, reviewed by brandonwilliams for CASSANDRA-7588
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/992a27e0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/992a27e0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/992a27e0
Branch: refs/heads/cassandra-2.1
Commit: 992a27e03fd96c785f0fdf40e78a19de8fc4c759
Parents: e0b8887
Author: Brandon Williams
Authored: Tue Jul 22 14:09:04 2014 -0500
Committer: Brandon Williams
Committed: Tue Jul 22 14:09:04 2014 -0500
--
pylib/cqlshlib/cql3handling.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/992a27e0/pylib/cqlshlib/cql3handling.py
--
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index 3d489d3..a676319 100644
--- a/pylib/cqlshlib/cql3handling.py
+++ b/pylib/cqlshlib/cql3handling.py
@@ -595,13 +595,14 @@ syntax_rules += r'''
( "WHERE" )?
( "ORDER" "BY" ( ","
)* )?
( "LIMIT" limit= )?
+ ( "ALLOW" "FILTERING" )?
;
::= ( "AND" )*
;
- ::= [rel_lhs]= ( "=" | "<" | ">" | "<=" | ">=" )
+ ::= [rel_lhs]= ( "=" | "<" | ">" | "<=" | ">=" | "CONTAINS"
)
| token="TOKEN" "(" [rel_tokname]=
( "," [rel_tokname]= )*
- ")" ("=" | "<" | ">" | "<=" | ">=")
+ ")" ("=" | "<" | ">" | "<=" | ">=" | "CONTAINS")
| [rel_lhs]= "IN" "(" ( "," )* ")"
;
::= "DISTINCT"? ("AS" )? (","
("AS" )?)*
[jira] [Created] (CASSANDRA-7590) java.lang.AssertionError when using DROP INDEX IF EXISTS on non-existing index
Hanh Dang created CASSANDRA-7590:
Summary: java.lang.AssertionError when using DROP INDEX IF EXISTS
on non-existing index
Key: CASSANDRA-7590
URL: https://issues.apache.org/jira/browse/CASSANDRA-7590
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Hanh Dang
To reproduce:
cqlsh> CREATE KEYSPACE test WITH REPLICATION = {'class':'SimpleStrategy',
'replication_factor':1};
cqlsh> USE test;
cqlsh:test> DROP INDEX IF EXISTS fake_index;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7588:
Attachment: (was: 7588-cqlsh-6910-contains.txt)
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
> Attachments: 7588-cqlsh-6910-contains-allow-filtering.txt
>
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070719#comment-14070719
]
Brandon Williams commented on CASSANDRA-7588:
-
That LGTM, but [~djatnieks] did you mistag the sincever on this? I know I
changed it to rc4, but that was because you tagged it rc3 and I noticed rc4
hadn't been created/released in jira yet, so I did that and changed it.
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
> Attachments: 7588-cqlsh-6910-contains-allow-filtering.txt
>
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7588:
Attachment: 7588-cqlsh-6910-contains-allow-filtering.txt
{{ALLOW FILTERING}} was also missing - combined patch attached
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
> Attachments: 7588-cqlsh-6910-contains-allow-filtering.txt
>
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070710#comment-14070710
]
Robert Stupp commented on CASSANDRA-7588:
-
Note: traceback with {{cqlsh --debug}} is:
{noformat}
cqlsh> SELECT id, description FROM cat_index_test.products WHERE features
CONTAINS '32-inch';
Traceback (most recent call last):
File "bin/cqlsh", line 822, in onecmd
self.handle_statement(st, statementtext)
File "bin/cqlsh", line 862, in handle_statement
return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
File "bin/cqlsh", line 871, in handle_parse_error
return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
File "bin/cqlsh", line 895, in perform_statement
with_default_limit=with_default_limit)
File "bin/cqlsh", line 919, in perform_simple_statement
parsed = cqlruleset.cql_parse(statement.query_string)[1]
IndexError: list index out of range
{noformat}
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
> Attachments: 7588-cqlsh-6910-contains.txt
>
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS
[jira] [Updated] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7588:
Attachment: 7588-cqlsh-6910-contains.txt
Patch attached (add {{CONTAINS}} to comparators in cql3handling.py)
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
> Attachments: 7588-cqlsh-6910-contains.txt
>
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070701#comment-14070701
]
Robert Stupp commented on CASSANDRA-7588:
-
Yup - I'm 99.9% sure it's 6910.
Not reproducible with 2.1.0-rc4
Not reproducible on branch cassandra-2.1.0
Reproducible on branch cassandra-2.1
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070670#comment-14070670
]
Brandon Williams commented on CASSANDRA-7588:
-
CASSANDRA-6910 is not in rc4, though.
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070678#comment-14070678
]
Robert Stupp commented on CASSANDRA-7588:
-
Yes - 6910 went into 2.1 branch - not in 2.1.0 branch.
I'll try if a similar fix works for this - need 15 minutes...
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7582) 2.1 multi-dc upgrade errors
[
https://issues.apache.org/jira/browse/CASSANDRA-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070668#comment-14070668
]
Benedict commented on CASSANDRA-7582:
-
Well, sort of. We knew that was broken already - whether or not it's the same
root cause I'm not convinced. That failure is because we never fixed the tests
after deciding we weren't going to 'fix' behaviour in CASSANDRA-6694 (related
to CASSANDRA-5202)
> 2.1 multi-dc upgrade errors
> ---
>
> Key: CASSANDRA-7582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7582
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Ryan McGuire
>Assignee: Russ Hatch
>Priority: Critical
> Fix For: 2.1.0
>
>
> Multi-dc upgrade [was working from 2.0 -> 2.1 fairly
> recently|http://cassci.datastax.com/job/cassandra_upgrade_dtest/55/testReport/upgrade_through_versions_test/TestUpgrade_from_cassandra_2_0_latest_tag_to_cassandra_2_1_HEAD/],
> but is currently failing.
> Running
> upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_0_HEAD_to_cassandra_2_1_HEAD.bootstrap_multidc_test
> I get the following errors when starting 2.1 upgraded from 2.0:
> {code}
> ERROR [main] 2014-07-21 23:54:20,862 CommitLog.java:143 - Commit log replay
> failed due to replaying a mutation for a missing table. This error can be
> ignored by providing -Dcassandra.commitlog.stop_on_missing_tables=false on
> the command line
> ERROR [main] 2014-07-21 23:54:20,869 CassandraDaemon.java:474 - Exception
> encountered during startup
> java.lang.RuntimeException:
> org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find
> cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
> [main/:na]
> Caused by: org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't
> find cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004
> 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:353)
> ~[main/:na]
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:333)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:365)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:98)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:137)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:115)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7581) Stop read requests for partitions which don't belong to a node
[ https://issues.apache.org/jira/browse/CASSANDRA-7581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070662#comment-14070662 ] sankalp kohli commented on CASSANDRA-7581: -- We should also put such restriction for CAS operations. > Stop read requests for partitions which don't belong to a node > -- > > Key: CASSANDRA-7581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7581 > Project: Cassandra > Issue Type: Bug >Reporter: sankalp kohli >Priority: Minor > > A C* instance will serve CF level reads with null values or old values to a > co-ordinator even if the instance is not responsible for the data. > This is bad if co-ordinator has a wrong view of the ring and will return > wrong results back to the client. > A solution to this problem could be to not respond or return error to such > read requests. > Tricky part here is to respond to read requests when the instance has just > lost ownership for a few ring delay. > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7582) 2.1 multi-dc upgrade errors
[
https://issues.apache.org/jira/browse/CASSANDRA-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070655#comment-14070655
]
Ryan McGuire commented on CASSANDRA-7582:
-
This also affects the snapshot_test.TestArchiveCommitlog tests.
> 2.1 multi-dc upgrade errors
> ---
>
> Key: CASSANDRA-7582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7582
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Ryan McGuire
>Assignee: Russ Hatch
>Priority: Critical
> Fix For: 2.1.0
>
>
> Multi-dc upgrade [was working from 2.0 -> 2.1 fairly
> recently|http://cassci.datastax.com/job/cassandra_upgrade_dtest/55/testReport/upgrade_through_versions_test/TestUpgrade_from_cassandra_2_0_latest_tag_to_cassandra_2_1_HEAD/],
> but is currently failing.
> Running
> upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_0_HEAD_to_cassandra_2_1_HEAD.bootstrap_multidc_test
> I get the following errors when starting 2.1 upgraded from 2.0:
> {code}
> ERROR [main] 2014-07-21 23:54:20,862 CommitLog.java:143 - Commit log replay
> failed due to replaying a mutation for a missing table. This error can be
> ignored by providing -Dcassandra.commitlog.stop_on_missing_tables=false on
> the command line
> ERROR [main] 2014-07-21 23:54:20,869 CassandraDaemon.java:474 - Exception
> encountered during startup
> java.lang.RuntimeException:
> org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find
> cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
> [main/:na]
> Caused by: org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't
> find cfId=a1b676f3-0c5d-3276-bfd5-07cf43397004
> 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:353)
> ~[main/:na]
> at
> org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:333)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:365)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:98)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:137)
> ~[main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:115)
> ~[main/:na]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070649#comment-14070649
]
Robert Stupp edited comment on CASSANDRA-7588 at 7/22/14 6:33 PM:
--
This is a regression of CASSANDRA-6910.
Suggestion: revert commit for CASSANDRA-6910 and implement CASSANDRA-6910
properly in 2.1.1
I had a similar failure (_list index out of range_) with UDFs ({{::}}
notation). Reason is that cqlsh does not "recognize" the {{::}} notation in its
grammar - same for this issue: cqlsh does not know about {{contains}}.
EDIT: "properly" means to check every {{SELECT}} statement variant with cqlsh.
was (Author: snazy):
This is a regression of CASSANDRA-6910.
Suggestion: revert commit for CASSANDRA-6910 and implement CASSANDRA-6910
properly in 2.1.1
I had a similar failure (_list index out of range_) with UDFs ({{::}}
notation). Reason is that cqlsh does not "recognize" the {{::}} notation in its
grammar - same for this issue: cqlsh does not know about {{contains}}.
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
>
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070649#comment-14070649
]
Robert Stupp commented on CASSANDRA-7588:
-
This is a regression of CASSANDRA-6910.
Suggestion: revert commit for CASSANDRA-6910 and implement CASSANDRA-6910
properly in 2.1.1
I had a similar failure (_list index out of range_) with UDFs ({{::}}
notation). Reason is that cqlsh does not "recognize" the {{::}} notation in its
grammar - same for this issue: cqlsh does not know about {{contains}}.
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-6454) Pig support for hadoop CqlInputFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Liu updated CASSANDRA-6454: Attachment: 6454-v4-2.0-branch.txt 6454-v4-2.1-branch.txt V4 rollback cassandra_pig.yaml > Pig support for hadoop CqlInputFormat > - > > Key: CASSANDRA-6454 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6454 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Alex Liu >Assignee: Alex Liu > Fix For: 2.0.10 > > Attachments: 6454-2.0-branch.txt, 6454-v2-2.0-branch.txt, > 6454-v3-2.0-branch.txt, 6454-v3-2.1-branch.txt, 6454-v4-2.0-branch.txt, > 6454-v4-2.1-branch.txt > > > CASSANDRA-6311 adds new CqlInputFormat, we need add the Pig support for it -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7527) Bump CQL version and update doc for 2.1
[ https://issues.apache.org/jira/browse/CASSANDRA-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070591#comment-14070591 ] Kristine Hahn commented on CASSANDRA-7527: -- @tyler, shouldn't the dot be next to the table name (after ON), not next to the name of the index? CREATE CUSTOM INDEX IF NOT EXISTS index_name ON keyspace_name.table_name ( KEYS ( column_name ) ) (USING class_name) (WITH OPTIONS = map) The tab completion doesn't show that you can preface an index name with a keyspace name using the dot notation. > Bump CQL version and update doc for 2.1 > --- > > Key: CASSANDRA-7527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7527 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Tyler Hobbs > Fix For: 2.1.0 > > Attachments: 7527-v2.txt, 7527.txt > > > It appears we forgot to bump the CQL version for new 2.1 features (UDT, tuple > type, collection indexing), nor did we update the textile doc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7588:
Since Version: 2.1 rc4
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7587) sstablekeys does not work with default configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7587:
Reproduced In: 2.1 rc4
> sstablekeys does not work with default configuration
>
>
> Key: CASSANDRA-7587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Kristine Hahn
>Assignee: Tyler Hobbs
>Priority: Minor
>
> The directory I tried to use with the sstablekeys tool is
> /apache-cassandra-2.1.0-rc4/data/data/music/playlists-e80c033011bd11e49269bb45d4dd025b/music-playlists-ka-1-Data.db
> Results of attempting to use the command:
> {quote}
> sstablekeys
> 2.1rc4/apache-cassandra-2.1.0-rc4/data/data/music/playlists-e80c033011bd11e49269bb45d4dd025b/music-playlists-ka-1-Data.db
> ERROR 16:54:57 Fatal configuration error
> org.apache.cassandra.exceptions.ConfigurationException: commitlog_directory
> is missing and -Dcassandra.storagedir is not set
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:447)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:129)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:406)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> commitlog_directory is missing and -Dcassandra.storagedir is not set
> Fatal configuration error; unable to start. See log for stacktrace.
> {quote}
> The system log says:
> {quote}
> ERROR [main] 2014-07-22 09:27:26,145 CassandraDaemon.java:203 - Directory
> ./../data/data doesn't exist
> ERROR [main] 2014-07-22 09:27:26,154 CassandraDaemon.java:203 - Directory
> ./../data/commitlog doesn't exist
> ERROR [main] 2014-07-22 09:27:26,154 CassandraDaemon.java:203 - Directory
> ./../data/saved_caches doesn't exist
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CASSANDRA-7587) sstablekeys does not work with default configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-7587:
---
Assignee: Tyler Hobbs
Similar to CASSANDRA-7508, at least in error.
> sstablekeys does not work with default configuration
>
>
> Key: CASSANDRA-7587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Kristine Hahn
>Assignee: Tyler Hobbs
>Priority: Minor
>
> The directory I tried to use with the sstablekeys tool is
> /apache-cassandra-2.1.0-rc4/data/data/music/playlists-e80c033011bd11e49269bb45d4dd025b/music-playlists-ka-1-Data.db
> Results of attempting to use the command:
> {quote}
> sstablekeys
> 2.1rc4/apache-cassandra-2.1.0-rc4/data/data/music/playlists-e80c033011bd11e49269bb45d4dd025b/music-playlists-ka-1-Data.db
> ERROR 16:54:57 Fatal configuration error
> org.apache.cassandra.exceptions.ConfigurationException: commitlog_directory
> is missing and -Dcassandra.storagedir is not set
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:447)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:129)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:406)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> commitlog_directory is missing and -Dcassandra.storagedir is not set
> Fatal configuration error; unable to start. See log for stacktrace.
> {quote}
> The system log says:
> {quote}
> ERROR [main] 2014-07-22 09:27:26,145 CassandraDaemon.java:203 - Directory
> ./../data/data doesn't exist
> ERROR [main] 2014-07-22 09:27:26,154 CassandraDaemon.java:203 - Directory
> ./../data/commitlog doesn't exist
> ERROR [main] 2014-07-22 09:27:26,154 CassandraDaemon.java:203 - Directory
> ./../data/saved_caches doesn't exist
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7587) sstablekeys does not work with default configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7587:
Reproduced In: (was: 2.1 rc3)
> sstablekeys does not work with default configuration
>
>
> Key: CASSANDRA-7587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7587
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Kristine Hahn
>Assignee: Tyler Hobbs
>Priority: Minor
>
> The directory I tried to use with the sstablekeys tool is
> /apache-cassandra-2.1.0-rc4/data/data/music/playlists-e80c033011bd11e49269bb45d4dd025b/music-playlists-ka-1-Data.db
> Results of attempting to use the command:
> {quote}
> sstablekeys
> 2.1rc4/apache-cassandra-2.1.0-rc4/data/data/music/playlists-e80c033011bd11e49269bb45d4dd025b/music-playlists-ka-1-Data.db
> ERROR 16:54:57 Fatal configuration error
> org.apache.cassandra.exceptions.ConfigurationException: commitlog_directory
> is missing and -Dcassandra.storagedir is not set
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:447)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:129)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:406)
> ~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
> commitlog_directory is missing and -Dcassandra.storagedir is not set
> Fatal configuration error; unable to start. See log for stacktrace.
> {quote}
> The system log says:
> {quote}
> ERROR [main] 2014-07-22 09:27:26,145 CassandraDaemon.java:203 - Directory
> ./../data/data doesn't exist
> ERROR [main] 2014-07-22 09:27:26,154 CassandraDaemon.java:203 - Directory
> ./../data/commitlog doesn't exist
> ERROR [main] 2014-07-22 09:27:26,154 CassandraDaemon.java:203 - Directory
> ./../data/saved_caches doesn't exist
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070569#comment-14070569
]
Brandon Williams commented on CASSANDRA-7588:
-
Try cqlsh with --debug
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070568#comment-14070568
]
Brandon Williams commented on CASSANDRA-7588:
-
Works fine for me:
{noformat}
cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
CONTAINS 'hdtv';
id| description
---+-
29411 |32-inch LED HDTV (black)
34134 | 120-inch 1080p 3D plasma TV
(2 rows)
{noformat}
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
[
https://issues.apache.org/jira/browse/CASSANDRA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-7588:
Since Version: (was: 2.1 rc3)
> cqlsh error for query against collection index - list index out of range
>
>
> Key: CASSANDRA-7588
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: dan jatnieks
> Labels: cqlsh
>
> This worked in 2.1 RC1
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> id| description
> ---+-
> 29412 |32-inch LED HDTV (black)
> 34134 | 120-inch 1080p 3D plasma TV
> (2 rows)
> {noformat}
> But fails with RC4:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native
> protocol v3]
> Use HELP for help.
> cqlsh> use k1;
> cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS
> 'hdtv';
> list index out of range
> cqlsh:k1>
> {noformat}
> This is using the example from the blog post
> http://www.datastax.com/dev/blog/cql-in-2-1
> A more complete repro:
> {noformat}
> cqlsh:k1>
> cqlsh:k1> CREATE KEYSPACE cat_index_test
> ... WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh:k1> USE cat_index_test;
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
> ... id int PRIMARY KEY,
> ... description text,
> ... price int,
> ... categories set,
> ... features map
> ... );
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
> products(categories);
> cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
> products(features);
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (34134,
> ...'120-inch 1080p 3D plasma TV',
> ...,
> ...{'tv', '3D', 'hdtv'},
> ...{'screen' : '120-inch', 'refresh-rate' :
> '400hz', 'techno' : 'plasma'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (29412,
> ...'32-inch LED HDTV (black)',
> ...929,
> ...{'tv', 'hdtv'},
> ...{'screen' : '32-inch', 'techno' :
> 'LED'});
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> INSERT INTO products(id, description, price,
> categories, features)
> ...VALUES (38471,
> ...'32-inch LCD TV',
> ...110,
> ...{'tv', 'used'},
> ...{'screen' : '32-inch', 'techno' :
> 'LCD'});
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
> CONTAINS 'hdtv';
> list index out of range
> cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
> CONTAINS '32-inch';
> list index out of range
> cqlsh:cat_index_test> DROP INDEX feat_index;
> cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
> cqlsh:cat_index_test>
> cqlsh:cat_index_test> SELECT id, description
> ... FROM products
> ... WHERE features CONTAINS KEY 'refresh-rate';
> list index out of range
> {noformat}
> This appears to be a cqlsh issue, since these queries still work when
> executed using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7589) Option to disable min timestamp check for TTL compaction enhancements
Matt Stump created CASSANDRA-7589: - Summary: Option to disable min timestamp check for TTL compaction enhancements Key: CASSANDRA-7589 URL: https://issues.apache.org/jira/browse/CASSANDRA-7589 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Matt Stump Priority: Minor As part of CASSANDRA-5228 we added an enhancement to unlink SSTables for TTL use cases if certain checks are met. One of those checks is that for an SSTable to be deleted the maximum timestamp must not be less than the minimum timestamp for all other SSTables. This makes sense for use cases where GC grace is >= the TTL, or use case where deletes are performed by the application. For use cases where GC grace is less than the TTL, and where deletes are only performed via TTL then these checks result in SSTables that could be safely deleted sticking around for some time. In practice the TTL related enhancements kick in very infrequently and most SSTables go through the normal compaction process. What I propose is a CF level setting that disables the check, so that an SSTable can be unlinked once time() >= max TTL. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
[ https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070533#comment-14070533 ] graham sanderson edited comment on CASSANDRA-7546 at 7/22/14 5:27 PM: -- Well that makes sense, I hadn't checked if there was a limit on mutator threads - we didn't change it... this probably explains the hard upper bound in my synthetic test (which incidentally does not to the transformation) I agree with you on SnapTreeMap, once I see the "essentially" free clone operation has to acquire a lock (or at least wait for no mutations)... I surmised there were probably dragons there that might cause all kinds of nastyness whether it be pain on concurrent updates to horribly unbalancing updates to the tree, or dragging huge amounts of stale data (garbage to be) with it due to overly lazy copy on write (again I didn't look too closely). BTree looks much better (and probably does less rebalancing since it has wider nodes I think), though as discussed it doesn't prevent the underlying race we also want to avoid So, I'll see if I have time to work on this later today, but the plan is... for 2.0.x (just checking) a) move the transformation.apply out of the loop or do it at most once (I prefer the former since it makes the race window smaller) b) do a one way flip flag per AtomicSortedColumns instance, which is flipped when a cost reaches a certain value. I was going to calculate the delta in each mutator thread (probably adding a log-like measure e.g. using Integer.numberOfLeadingZeros(tree.size()) per failing CAS), though looking ugh at SnapTreeMap again, it seems that tree.size() is not a good method to call in the presence of mutations, so I guess Holder can just track the tree size itself. Note the new total cost is CASed in as part of the holder c) given this is possibly a temporary solution, is it worth exposing the "cut-off" value even un-documented such that it could be overridden in cassandra.yaml? Note the default should be such that most AtomicSortedColumns instance never get cut-off since they are not heavily contended and large (indicating contended inserts not updates) We can re-circle the wagons for 2.1 which needs to be a separate patch anyway was (Author: graham sanderson): Well that makes sense, I hadn't checked if there was a limit on mutator threads - we didn't change it... this probably explains the hard upper bound in my synthetic test (which incidentally does not to the transformation) I agree with you on SnapTreeMap, once I see the "essentially" free clone operation has to acquire a lock (or at least wait for no mutations)... I surmised there were probably dragons there that might cause all kinds of nastyness whether it be pain on concurrent updates to horribly unbalancing updates to the tree, or dragging huge amounts of stale data (garbage to be) with it due to overly lazy copy on write (again I didn't look too closely). BTree looks much better (and probably does less rebalancing since it has wider nodes I think), though as discussed it doesn't prevent the underlying race we also want to avoid So, I'll see if I have time to work on this later today, but the plan is... for 2.0.x (just checking) a) move the transformation.apply out of the loop or do it at most once (I prefer the former since it makes the race window smaller) b) do a one way flip flag per AtomicSortedColumns instance, which is flipped when a cost reaches a certain value. I was going to calculate the delta in each mutator thread (probably adding a log-like measure e.g. using Integer.numberOfLeadingZeros(tree.size()) per failing CAS), though looking ugh at SnapTreeMap again, it seems that tree.size() is not a good method to call in the presence of mutations, so I guess Holder can just track the tree size itself c) given this is possibly a temporary solution, is it worth exposing the "cut-off" value even un-documented such that it could be overridden in cassandra.yaml? Note the default should be such that most AtomicSortedColumns instance never get cut-off since they are not heavily contended and large (indicating contended inserts not updates) We can re-circle the wagons for 2.1 which needs to be a separate patch anyway > AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory > - > > Key: CASSANDRA-7546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7546 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: graham sanderson >Assignee: graham sanderson > Attachments: 7546.20.txt, 7546.20_2.txt, 7546.20_alt.txt, > suggestion1.txt, suggestion1_21.txt > > > In order to preserve atomicity, this code attempts to read, clone/
[jira] [Comment Edited] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
[ https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070533#comment-14070533 ] graham sanderson edited comment on CASSANDRA-7546 at 7/22/14 5:25 PM: -- Well that makes sense, I hadn't checked if there was a limit on mutator threads - we didn't change it... this probably explains the hard upper bound in my synthetic test (which incidentally does not to the transformation) I agree with you on SnapTreeMap, once I see the "essentially" free clone operation has to acquire a lock (or at least wait for no mutations)... I surmised there were probably dragons there that might cause all kinds of nastyness whether it be pain on concurrent updates to horribly unbalancing updates to the tree, or dragging huge amounts of stale data (garbage to be) with it due to overly lazy copy on write (again I didn't look too closely). BTree looks much better (and probably does less rebalancing since it has wider nodes I think), though as discussed it doesn't prevent the underlying race we also want to avoid So, I'll see if I have time to work on this later today, but the plan is... for 2.0.x (just checking) a) move the transformation.apply out of the loop or do it at most once (I prefer the former since it makes the race window smaller) b) do a one way flip flag per AtomicSortedColumns instance, which is flipped when a cost reaches a certain value. I was going to calculate the delta in each mutator thread (probably adding a log-like measure e.g. using Integer.numberOfLeadingZeros(tree.size()) per failing CAS), though looking ugh at SnapTreeMap again, it seems that tree.size() is not a good method to call in the presence of mutations, so I guess Holder can just track the tree size itself c) given this is possibly a temporary solution, is it worth exposing the "cut-off" value even un-documented such that it could be overridden in cassandra.yaml? Note the default should be such that most AtomicSortedColumns instance never get cut-off since they are not heavily contended and large (indicating contended inserts not updates) We can re-circle the wagons for 2.1 which needs to be a separate patch anyway was (Author: graham sanderson): Well that makes sense, I hadn't checked if there was a limit on mutator threads - we didn't change it... this probably explains the hard upper bound in my synthetic test (which incidentally does not to the transformation) I agree with you on SnapTreeMap, once I see the "essentially" free clone operation has to acquire a lock (or at least wait for no mutations)... I surmised there were probably dragons there that might cause all kinds of nastyness whether it be pain on concurrent updates to a horribly unbalanced tree, or dragging huge amounts of garbage with it due to overly lazy copy on write (again I didn't look too closely). BTree looks much better (and probably does less rebalancing since it has wider nodes I think), though as discussed it doesn't prevent the underlying race. So, I'll see if I have time to work on this later today, but the plan is... for 2.0.x (just checking) a) move the transformation.apply out of the loop and do it once b) do a one way flip flag per AtomicSortedColumns instance, which is flipped when a cost reaches a certain value. I was going to calculate the delta in each mutator thread (probably adding a log-like measure e.g. using Integer.numberOfLeadingZeros(tree.size()) per failing CAS), though looking ugh at SnapTreeMap again, it seems that tree.size() is not a good method to call in the presence of mutations, so I guess Holder can just track the tree size itself c) given this is possibly a temporary solution, is it worth exposing the "cut-off" value even un-documented such that it could be overridden in cassandra.yaml? Note the default should be such that most AtomicSortedColumns instance never get cut-off since they are not heavily contended and large (indicating contended inserts not updates) > AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory > - > > Key: CASSANDRA-7546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7546 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: graham sanderson >Assignee: graham sanderson > Attachments: 7546.20.txt, 7546.20_2.txt, 7546.20_alt.txt, > suggestion1.txt, suggestion1_21.txt > > > In order to preserve atomicity, this code attempts to read, clone/update, > then CAS the state of the partition. > Under heavy contention for updating a single partition this can cause some > fairly staggering memory growth (the more cores on your machine the worst it > gets). > Whilst many usage patterns don't do highly con
[jira] [Created] (CASSANDRA-7587) sstablekeys does not work with default configuration
Kristine Hahn created CASSANDRA-7587:
Summary: sstablekeys does not work with default configuration
Key: CASSANDRA-7587
URL: https://issues.apache.org/jira/browse/CASSANDRA-7587
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Kristine Hahn
Priority: Minor
The directory I tried to use with the sstablekeys tool is
/apache-cassandra-2.1.0-rc4/data/data/music/playlists-e80c033011bd11e49269bb45d4dd025b/music-playlists-ka-1-Data.db
Results of attempting to use the command:
{quote}
sstablekeys
2.1rc4/apache-cassandra-2.1.0-rc4/data/data/music/playlists-e80c033011bd11e49269bb45d4dd025b/music-playlists-ka-1-Data.db
ERROR 16:54:57 Fatal configuration error
org.apache.cassandra.exceptions.ConfigurationException: commitlog_directory is
missing and -Dcassandra.storagedir is not set
at
org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:447)
~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
at
org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:129)
~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
at
org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:406)
~[apache-cassandra-2.1.0-rc4.jar:2.1.0-rc4]
commitlog_directory is missing and -Dcassandra.storagedir is not set
Fatal configuration error; unable to start. See log for stacktrace.
{quote}
The system log says:
{quote}
ERROR [main] 2014-07-22 09:27:26,145 CassandraDaemon.java:203 - Directory
./../data/data doesn't exist
ERROR [main] 2014-07-22 09:27:26,154 CassandraDaemon.java:203 - Directory
./../data/commitlog doesn't exist
ERROR [main] 2014-07-22 09:27:26,154 CassandraDaemon.java:203 - Directory
./../data/saved_caches doesn't exist
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7588) cqlsh error for query against collection index - list index out of range
dan jatnieks created CASSANDRA-7588:
---
Summary: cqlsh error for query against collection index - list
index out of range
Key: CASSANDRA-7588
URL: https://issues.apache.org/jira/browse/CASSANDRA-7588
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: dan jatnieks
This worked in 2.1 RC1
{noformat}
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.0-rc1-SNAPSHOT | CQL spec 3.1.7 | Native protocol
v3]
Use HELP for help.
cqlsh> use k1;
cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS 'hdtv';
id| description
---+-
29412 |32-inch LED HDTV (black)
34134 | 120-inch 1080p 3D plasma TV
(2 rows)
{noformat}
But fails with RC4:
{noformat}
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.0-rc4-SNAPSHOT | CQL spec 3.2.0 | Native protocol
v3]
Use HELP for help.
cqlsh> use k1;
cqlsh:k1> SELECT id, description FROM products WHERE categories CONTAINS 'hdtv';
list index out of range
cqlsh:k1>
{noformat}
This is using the example from the blog post
http://www.datastax.com/dev/blog/cql-in-2-1
A more complete repro:
{noformat}
cqlsh:k1>
cqlsh:k1> CREATE KEYSPACE cat_index_test
... WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
1};
cqlsh:k1> USE cat_index_test;
cqlsh:cat_index_test>
cqlsh:cat_index_test> CREATE TABLE IF NOT EXISTS products (
... id int PRIMARY KEY,
... description text,
... price int,
... categories set,
... features map
... );
cqlsh:cat_index_test>
cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS cat_index ON
products(categories);
cqlsh:cat_index_test> CREATE INDEX IF NOT EXISTS feat_index ON
products(features);
cqlsh:cat_index_test>
cqlsh:cat_index_test> INSERT INTO products(id, description, price,
categories, features)
...VALUES (34134,
...'120-inch 1080p 3D plasma TV',
...,
...{'tv', '3D', 'hdtv'},
...{'screen' : '120-inch', 'refresh-rate' :
'400hz', 'techno' : 'plasma'});
cqlsh:cat_index_test>
cqlsh:cat_index_test> INSERT INTO products(id, description, price,
categories, features)
...VALUES (29412,
...'32-inch LED HDTV (black)',
...929,
...{'tv', 'hdtv'},
...{'screen' : '32-inch', 'techno' : 'LED'});
cqlsh:cat_index_test>
cqlsh:cat_index_test> INSERT INTO products(id, description, price,
categories, features)
...VALUES (38471,
...'32-inch LCD TV',
...110,
...{'tv', 'used'},
...{'screen' : '32-inch', 'techno' : 'LCD'});
cqlsh:cat_index_test> SELECT id, description FROM products WHERE categories
CONTAINS 'hdtv';
list index out of range
cqlsh:cat_index_test> SELECT id, description FROM products WHERE features
CONTAINS '32-inch';
list index out of range
cqlsh:cat_index_test> DROP INDEX feat_index;
cqlsh:cat_index_test> CREATE INDEX feat_key_index ON products(KEYS(features));
cqlsh:cat_index_test>
cqlsh:cat_index_test> SELECT id, description
... FROM products
... WHERE features CONTAINS KEY 'refresh-rate';
list index out of range
{noformat}
This appears to be a cqlsh issue, since these queries still work when executed
using DevCenter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7527) Bump CQL version and update doc for 2.1
[ https://issues.apache.org/jira/browse/CASSANDRA-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070537#comment-14070537 ] Tyler Hobbs commented on CASSANDRA-7527: bq. Is misplaced here? I don't think so, but maybe I'm missing something obvious? > Bump CQL version and update doc for 2.1 > --- > > Key: CASSANDRA-7527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7527 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Tyler Hobbs > Fix For: 2.1.0 > > Attachments: 7527-v2.txt, 7527.txt > > > It appears we forgot to bump the CQL version for new 2.1 features (UDT, tuple > type, collection indexing), nor did we update the textile doc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
[ https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070533#comment-14070533 ] graham sanderson commented on CASSANDRA-7546: - Well that makes sense, I hadn't checked if there was a limit on mutator threads - we didn't change it... this probably explains the hard upper bound in my synthetic test (which incidentally does not to the transformation) I agree with you on SnapTreeMap, once I see the "essentially" free clone operation has to acquire a lock (or at least wait for no mutations)... I surmised there were probably dragons there that might cause all kinds of nastyness whether it be pain on concurrent updates to a horribly unbalanced tree, or dragging huge amounts of garbage with it due to overly lazy copy on write (again I didn't look too closely). BTree looks much better (and probably does less rebalancing since it has wider nodes I think), though as discussed it doesn't prevent the underlying race. So, I'll see if I have time to work on this later today, but the plan is... for 2.0.x (just checking) a) move the transformation.apply out of the loop and do it once b) do a one way flip flag per AtomicSortedColumns instance, which is flipped when a cost reaches a certain value. I was going to calculate the delta in each mutator thread (probably adding a log-like measure e.g. using Integer.numberOfLeadingZeros(tree.size()) per failing CAS), though looking ugh at SnapTreeMap again, it seems that tree.size() is not a good method to call in the presence of mutations, so I guess Holder can just track the tree size itself c) given this is possibly a temporary solution, is it worth exposing the "cut-off" value even un-documented such that it could be overridden in cassandra.yaml? Note the default should be such that most AtomicSortedColumns instance never get cut-off since they are not heavily contended and large (indicating contended inserts not updates) > AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory > - > > Key: CASSANDRA-7546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7546 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: graham sanderson >Assignee: graham sanderson > Attachments: 7546.20.txt, 7546.20_2.txt, 7546.20_alt.txt, > suggestion1.txt, suggestion1_21.txt > > > In order to preserve atomicity, this code attempts to read, clone/update, > then CAS the state of the partition. > Under heavy contention for updating a single partition this can cause some > fairly staggering memory growth (the more cores on your machine the worst it > gets). > Whilst many usage patterns don't do highly concurrent updates to the same > partition, hinting today, does, and in this case wild (order(s) of magnitude > more than expected) memory allocation rates can be seen (especially when the > updates being hinted are small updates to different partitions which can > happen very fast on their own) - see CASSANDRA-7545 > It would be best to eliminate/reduce/limit the spinning memory allocation > whilst not slowing down the very common un-contended case. -- This message was sent by Atlassian JIRA (v6.2#6252)
svn commit: r1612612 - /cassandra/site/publish/doc/cql/CQL.html
Author: tylerhobbs Date: Tue Jul 22 17:10:08 2014 New Revision: 1612612 URL: http://svn.apache.org/r1612612 Log: Add note about CQL2 removal to CQL2 docs Modified: cassandra/site/publish/doc/cql/CQL.html Modified: cassandra/site/publish/doc/cql/CQL.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/doc/cql/CQL.html?rev=1612612&r1=1612611&r2=1612612&view=diff == --- cassandra/site/publish/doc/cql/CQL.html (original) +++ cassandra/site/publish/doc/cql/CQL.html Tue Jul 22 17:10:08 2014 @@ -1,4 +1,4 @@ -http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>http://www.w3.org/1999/xhtml";>CQLCassandra Query Language (CQL) v2.0Table of ContentsCassandra Query Language (CQL) v2.0Table of ContentsSyntax conventionsOverall syn taxData Storage TypesWorking with datesUSESELECTSpecifying ColumnsColumn FamilyConsistency LevelFiltering rowsLimitsINSERTUPDATEColumn FamilyConsistency LevelTimestampTTLSpecifying Columns and RowUpdating Counter ColumnsDELETESpecifying ColumnsColumn FamilyConsistency LevelSpecifying RowsTRUNCATEBATCHCREATE KEYSPACECREATE COLUMNFAMILYSpecifying Key TypeSpecifying Column Types (optional)Column Family Options (optional)CREATE INDEXDROP KEYSPACEDROP COLUMNFAMILYDROP INDEXALTER COLUMNFAMILYChanging the type of a typed columnAdding a typed columnDropping a typed columnCommon IdiomsSpecifying ConsistencyVersioningChangesSyntax conventionsTo aid in specifying the CQL syntax, we will use the following conventions in this document:Language rules will be given in a BNF-like notation, looking like this:::= * +http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>http://www.w3.org/1999/xhtml";>CQLCassandra Query Language (CQL) v2.0NOTICE: CQL 2 has been deprecated since Cassandra 2.0, and will be removed in Cassandra 3.0. It is recommended that you upgrade to CQL 3, which has much better driver support and many new features. For further reading, see the http://cassandra.apache.org/doc/cql3/CQL.html";>CQL 3 documentation and the http://wiki.a pache.org/cassandra/ClientOptions">CQL 3 drivers.Table of ContentsCassandra Query Language (CQL) v2.0Table of ContentsSyntax conventionsOverall syntaxData Storage TypesWorking with datesUSESELECTSpecifying ColumnsColumn FamilyConsistency LevelFiltering rowsLimitsINSERTUPDATEColumn FamilyConsistency LevelTimestampTTLSpecifying Columns and RowUpdating Counter ColumnsDELETESpecifying ColumnsColumn FamilyConsistency LevelSpecifying RowsTRUNCATEBATCHCREAT E KEYSPACECREATE COLUMNFAMILYSpecifying Key TypeSpecifying Column Types (optional)Column Family Options (optional)CREATE INDEXDROP KEYSPACEDROP COLUMNFAMILYDROP INDEXALTER COLUMNFAMILYChanging the type of a typed columnAdding a typed columnDropping a typed columnModifying column fami ly propertiesCommon IdiomsSpecifying ConsistencyVersioningChangesSyntax conventionsTo aid in specifying the CQL syntax, we will use the following conventions in this document:Language rules will be given in a BNF-like notation, looking like this: ::= * ; Nonterminal symbols in syntax rules will have .Terminal symbols will be shown in "single quotes".As an additional shortcut notation to BNF, optional symbols (that can occur zero or one times) will be followed by a ? marker. Optional symbols that can occur zero or any number of times will be followed by a * marker. Multiple symbols may be grouped together in (parentheses) to signify that they are all optional or repeatable together.In a few cases where meaning is more easily conveyed through prose, we explain a symbol and its expansion without BNF.Sample code will also be shown in a code block:SELECT sample_usage FROM cql; References to keywords or pieces of CQL code in running text will be shown in a fixed-width font.Overall syntaxCQL consists of statements. As in SQL, some statements directly make changes to data, some look up data, and some change the way data is stored.All statements end with a semicolon. ::= ";" @@ -175,16 +175,14 @@ CREATE KEYSPACE Excalibur WITH strategy_ The CREATE KEYSPACE statement creates a new top-level namespace (aka “keyspace”). Valid names are any string constructed of alphanumeric characters and underscores. Names which do not work as valid identifiers or integers should be quoted as string literals. Properties such as replication strategy and count are specified during creation using the following accepted keyword arguments:keywordrequireddescriptionstrategy_classyesThe name of the replication strategy class which should be used for the new keyspace. Some often-used classes are SimpleStrategy and NetworkTopologyStrategy.strategy_optionsnoMost strategies require additional arguments which can be supplied by appending the option name to the strategy_options keyword, separated by a c
[2/4] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e740c297 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e740c297 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e740c297 Branch: refs/heads/trunk Commit: e740c297951603947f6aa293a8ffa4c372ed3aef Parents: df7bd7f 9906a4e Author: Tyler Hobbs Authored: Tue Jul 22 12:04:34 2014 -0500 Committer: Tyler Hobbs Committed: Tue Jul 22 12:04:34 2014 -0500 -- doc/cql/CQL.textile | 2 ++ 1 file changed, 2 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e740c297/doc/cql/CQL.textile --
[4/4] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Conflicts: doc/cql/CQL.textile Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/dc84af47 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/dc84af47 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/dc84af47 Branch: refs/heads/trunk Commit: dc84af47c34260f62e413c2334111fa91b746dec Parents: 3a7242e e0b8887 Author: Tyler Hobbs Authored: Tue Jul 22 12:07:00 2014 -0500 Committer: Tyler Hobbs Committed: Tue Jul 22 12:07:00 2014 -0500 -- --
[3/4] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e0b88878 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e0b88878 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e0b88878 Branch: refs/heads/trunk Commit: e0b88878c52b6692d2391b398372d5f5f2a83aff Parents: f9af6ab e740c29 Author: Tyler Hobbs Authored: Tue Jul 22 12:06:11 2014 -0500 Committer: Tyler Hobbs Committed: Tue Jul 22 12:06:11 2014 -0500 -- doc/cql/CQL.textile | 2 ++ 1 file changed, 2 insertions(+) --
[1/4] git commit: Ninja: add note about CQL2 removal to CQL2 docs
Repository: cassandra
Updated Branches:
refs/heads/trunk 3a7242eca -> dc84af47c
Ninja: add note about CQL2 removal to CQL2 docs
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9906a4e5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9906a4e5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9906a4e5
Branch: refs/heads/trunk
Commit: 9906a4e5de083b3d23d4e2b68c2bf1736405d878
Parents: ff211a4
Author: Tyler Hobbs
Authored: Tue Jul 22 11:59:53 2014 -0500
Committer: Tyler Hobbs
Committed: Tue Jul 22 12:00:24 2014 -0500
--
doc/cql/CQL.textile | 2 ++
1 file changed, 2 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9906a4e5/doc/cql/CQL.textile
--
diff --git a/doc/cql/CQL.textile b/doc/cql/CQL.textile
index 1cfe883..a874a29 100644
--- a/doc/cql/CQL.textile
+++ b/doc/cql/CQL.textile
@@ -2,6 +2,8 @@
h1. Cassandra Query Language (CQL) v2.0
+%{color:red}NOTICE%: CQL 2 has been deprecated since Cassandra 2.0, and
will be removed in Cassandra 3.0. It is recommended that you upgrade to CQL 3,
which has much better driver support and many new features. For further
reading, see the "CQL 3
documentation":http://cassandra.apache.org/doc/cql3/CQL.html and the "CQL 3
drivers":http://wiki.apache.org/cassandra/ClientOptions.
+
h2. Table of Contents
{toc}
[1/3] git commit: Ninja: add note about CQL2 removal to CQL2 docs
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 f9af6ab58 -> e0b88878c
Ninja: add note about CQL2 removal to CQL2 docs
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9906a4e5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9906a4e5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9906a4e5
Branch: refs/heads/cassandra-2.1
Commit: 9906a4e5de083b3d23d4e2b68c2bf1736405d878
Parents: ff211a4
Author: Tyler Hobbs
Authored: Tue Jul 22 11:59:53 2014 -0500
Committer: Tyler Hobbs
Committed: Tue Jul 22 12:00:24 2014 -0500
--
doc/cql/CQL.textile | 2 ++
1 file changed, 2 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9906a4e5/doc/cql/CQL.textile
--
diff --git a/doc/cql/CQL.textile b/doc/cql/CQL.textile
index 1cfe883..a874a29 100644
--- a/doc/cql/CQL.textile
+++ b/doc/cql/CQL.textile
@@ -2,6 +2,8 @@
h1. Cassandra Query Language (CQL) v2.0
+%{color:red}NOTICE%: CQL 2 has been deprecated since Cassandra 2.0, and
will be removed in Cassandra 3.0. It is recommended that you upgrade to CQL 3,
which has much better driver support and many new features. For further
reading, see the "CQL 3
documentation":http://cassandra.apache.org/doc/cql3/CQL.html and the "CQL 3
drivers":http://wiki.apache.org/cassandra/ClientOptions.
+
h2. Table of Contents
{toc}
[2/3] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e740c297 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e740c297 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e740c297 Branch: refs/heads/cassandra-2.1 Commit: e740c297951603947f6aa293a8ffa4c372ed3aef Parents: df7bd7f 9906a4e Author: Tyler Hobbs Authored: Tue Jul 22 12:04:34 2014 -0500 Committer: Tyler Hobbs Committed: Tue Jul 22 12:04:34 2014 -0500 -- doc/cql/CQL.textile | 2 ++ 1 file changed, 2 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e740c297/doc/cql/CQL.textile --
[3/3] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e0b88878 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e0b88878 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e0b88878 Branch: refs/heads/cassandra-2.1 Commit: e0b88878c52b6692d2391b398372d5f5f2a83aff Parents: f9af6ab e740c29 Author: Tyler Hobbs Authored: Tue Jul 22 12:06:11 2014 -0500 Committer: Tyler Hobbs Committed: Tue Jul 22 12:06:11 2014 -0500 -- doc/cql/CQL.textile | 2 ++ 1 file changed, 2 insertions(+) --
[1/3] git commit: Fix ReversedType(DateType) mapping to native protocol
Repository: cassandra Updated Branches: refs/heads/cassandra-2.1.0 df7bd7f72 -> e740c2979 Fix ReversedType(DateType) mapping to native protocol patch by Ben Hood; reviewed by Aleksey Yeschenko for CASSANDRA-7576 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ff211a4c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ff211a4c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ff211a4c Branch: refs/heads/cassandra-2.1.0 Commit: ff211a4c445cd74859aabf00f3ec81a5e69473f2 Parents: 8754809 Author: Aleksey Yeschenko Authored: Tue Jul 22 01:42:24 2014 +0300 Committer: Aleksey Yeschenko Committed: Tue Jul 22 01:42:24 2014 +0300 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/transport/DataType.java | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ff211a4c/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index d339309..9909760 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 2.0.10 + * Fix ReversedType(DateType) mapping to native protocol (CASSANDRA-7576) * (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541) * Fix range merging when DES scores are zero (CASSANDRA-7535) * Warn when SSL certificates have expired (CASSANDRA-7528) http://git-wip-us.apache.org/repos/asf/cassandra/blob/ff211a4c/src/java/org/apache/cassandra/transport/DataType.java -- diff --git a/src/java/org/apache/cassandra/transport/DataType.java b/src/java/org/apache/cassandra/transport/DataType.java index 1656d24..8cd7194 100644 --- a/src/java/org/apache/cassandra/transport/DataType.java +++ b/src/java/org/apache/cassandra/transport/DataType.java @@ -146,8 +146,9 @@ public enum DataType implements OptionCodec.Codecable // shouldn't have to care about it. if (type instanceof ReversedType) type = ((ReversedType)type).baseType; + // For compatibility sake, we still return DateType as the timestamp type in resultSet metadata (#5723) -else if (type instanceof DateType) +if (type instanceof DateType) type = TimestampType.instance; DataType dt = dataTypeMap.get(type);
[2/3] git commit: Ninja: add note about CQL2 removal to CQL2 docs
Ninja: add note about CQL2 removal to CQL2 docs
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9906a4e5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9906a4e5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9906a4e5
Branch: refs/heads/cassandra-2.1.0
Commit: 9906a4e5de083b3d23d4e2b68c2bf1736405d878
Parents: ff211a4
Author: Tyler Hobbs
Authored: Tue Jul 22 11:59:53 2014 -0500
Committer: Tyler Hobbs
Committed: Tue Jul 22 12:00:24 2014 -0500
--
doc/cql/CQL.textile | 2 ++
1 file changed, 2 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9906a4e5/doc/cql/CQL.textile
--
diff --git a/doc/cql/CQL.textile b/doc/cql/CQL.textile
index 1cfe883..a874a29 100644
--- a/doc/cql/CQL.textile
+++ b/doc/cql/CQL.textile
@@ -2,6 +2,8 @@
h1. Cassandra Query Language (CQL) v2.0
+%{color:red}NOTICE%: CQL 2 has been deprecated since Cassandra 2.0, and
will be removed in Cassandra 3.0. It is recommended that you upgrade to CQL 3,
which has much better driver support and many new features. For further
reading, see the "CQL 3
documentation":http://cassandra.apache.org/doc/cql3/CQL.html and the "CQL 3
drivers":http://wiki.apache.org/cassandra/ClientOptions.
+
h2. Table of Contents
{toc}
[3/3] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Conflicts: CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e740c297 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e740c297 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e740c297 Branch: refs/heads/cassandra-2.1.0 Commit: e740c297951603947f6aa293a8ffa4c372ed3aef Parents: df7bd7f 9906a4e Author: Tyler Hobbs Authored: Tue Jul 22 12:04:34 2014 -0500 Committer: Tyler Hobbs Committed: Tue Jul 22 12:04:34 2014 -0500 -- doc/cql/CQL.textile | 2 ++ 1 file changed, 2 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e740c297/doc/cql/CQL.textile --
git commit: Ninja: add note about CQL2 removal to CQL2 docs
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 ff211a4c4 -> 9906a4e5d
Ninja: add note about CQL2 removal to CQL2 docs
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9906a4e5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9906a4e5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9906a4e5
Branch: refs/heads/cassandra-2.0
Commit: 9906a4e5de083b3d23d4e2b68c2bf1736405d878
Parents: ff211a4
Author: Tyler Hobbs
Authored: Tue Jul 22 11:59:53 2014 -0500
Committer: Tyler Hobbs
Committed: Tue Jul 22 12:00:24 2014 -0500
--
doc/cql/CQL.textile | 2 ++
1 file changed, 2 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9906a4e5/doc/cql/CQL.textile
--
diff --git a/doc/cql/CQL.textile b/doc/cql/CQL.textile
index 1cfe883..a874a29 100644
--- a/doc/cql/CQL.textile
+++ b/doc/cql/CQL.textile
@@ -2,6 +2,8 @@
h1. Cassandra Query Language (CQL) v2.0
+%{color:red}NOTICE%: CQL 2 has been deprecated since Cassandra 2.0, and
will be removed in Cassandra 3.0. It is recommended that you upgrade to CQL 3,
which has much better driver support and many new features. For further
reading, see the "CQL 3
documentation":http://cassandra.apache.org/doc/cql3/CQL.html and the "CQL 3
drivers":http://wiki.apache.org/cassandra/ClientOptions.
+
h2. Table of Contents
{toc}
[jira] [Commented] (CASSANDRA-7585) cassandra sstableloader connection refused with inter_node_encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070481#comment-14070481 ] Brandon Williams commented on CASSANDRA-7585: - bq. Maybe write custom config loader that just use part of cassandra.yaml is the way to go. Couldn't we just add an option to specify the storage port? IIRC, the main reason we had to avoid yaml loading was the static init caused all kinds of other problems. > cassandra sstableloader connection refused with inter_node_encryption > - > > Key: CASSANDRA-7585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7585 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Reporter: Samphel Norden >Assignee: Yuki Morishita > > cassandra sstableloader connection refused with inter_node_encryption > When using sstableloader to import tables (cassandra 2.0.5) with inter-node > encryption and client encryption enabled, I get a connection refused error > I am using > sstableloader -d $myhost -p 9160 -u cassandra -pw cassandra -ciphers > TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA > -st JKS -tf org.apache.cassandra.thrift.SSLTransportFactory -ts > /path/to/truststore -tspw $fullpath/$table > Errors out with > Streaming session ID: 1bc395c0-fbb2-11e3-9812-73da15121373 > WARN 17:13:34,147 Failed attempt 1 to connect to > Similar problem reported in cassandra 2.0.8 by another user > http://stackoverflow.com/questions/24390604/cassandra-sstableloader-connection-refused-with-inter-node-encryption > == > Relevant cassandra.yaml snippet (with obfuscation) > server_encryption_options: > > internode_encryption: all > > keystore:/path/to/keystore > > keystore_password: > > truststore:/path/to/truststore > > truststore_password: > > # More advanced defaults below: > > protocol: TLS > > algorithm: SunX509 > > store_type: JKS > > cipher_suites: > [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] > > require_client_auth: true > > > > # enable or disable client/server encryption. > > client_encryption_options: > > enabled: true > > keystore: /path/to/keystore > > keystore_password: > > #require_client_auth: true > > # Set trustore and truststore_password if require_client_auth is true > > truststore:/path/to/truststore > > truststore_password: > > # More advanced defaults below: > > protocol: TLS > > algorithm: SunX509 > > store_type: JKS
[Cassandra Wiki] Trivial Update of "DataModel" by JonathanEllis
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "DataModel" page has been changed by JonathanEllis: https://wiki.apache.org/cassandra/DataModel?action=diff&rev1=37&rev2=38 Comment: update link to 2.0 docs This allows pervasive denormalization to "pre-build" resultsets at update time, rather than doing expensive joins across the cluster. - !DataStax has a [[http://www.datastax.com/documentation/cql/3.0/webhelp/index.html#cql/ddl/ddl_anatomy_table_c.html|good introduction to data modeling in Cassandra here]]. + !DataStax has a [[http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_intro_c.html|good introduction to data modeling in Cassandra here]]. For more detail, see Patrick !McFadin's data modeling series:
[jira] [Commented] (CASSANDRA-7585) cassandra sstableloader connection refused with inter_node_encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070463#comment-14070463 ] Samphel Norden commented on CASSANDRA-7585: --- sstableloader always fails with connection refused, if internode encryption is on... The naive explanation (at least to me) is that it is somehow causing some activity on port 7000 between nodes (whether streaming is the reason is unknown) which is not the port on which nodes talk to each other when internode encryption is enabled... As I said above, sstableloader works correctly if only client to server encryption is enabled (that was a bug fixed in 2.0.4 IIRC). I think in both cases it is using the default ports 9160 and 7000. The client encryption part works fine since it also uses the default 9160 port even if client-to-server encryption is enabled.. The problem I think is that sstableloader is using 7000 (for unknown reasons) and the nodes no longer listen on 7000 when we have inter-node encryption enabled. Thats my speculative thinking. Whatever the reason might be, this is a critical bug for us since we have to enable encryption in enterprise deployments and need sstableloader to work for backup restores. > cassandra sstableloader connection refused with inter_node_encryption > - > > Key: CASSANDRA-7585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7585 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Reporter: Samphel Norden >Assignee: Yuki Morishita > > cassandra sstableloader connection refused with inter_node_encryption > When using sstableloader to import tables (cassandra 2.0.5) with inter-node > encryption and client encryption enabled, I get a connection refused error > I am using > sstableloader -d $myhost -p 9160 -u cassandra -pw cassandra -ciphers > TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA > -st JKS -tf org.apache.cassandra.thrift.SSLTransportFactory -ts > /path/to/truststore -tspw $fullpath/$table > Errors out with > Streaming session ID: 1bc395c0-fbb2-11e3-9812-73da15121373 > WARN 17:13:34,147 Failed attempt 1 to connect to > Similar problem reported in cassandra 2.0.8 by another user > http://stackoverflow.com/questions/24390604/cassandra-sstableloader-connection-refused-with-inter-node-encryption > == > Relevant cassandra.yaml snippet (with obfuscation) > server_encryption_options: > > internode_encryption: all > > keystore:/path/to/keystore > > keystore_password: > > truststore:/path/to/truststore > > truststore_password: > > # More advanced defaults below: > > protocol: TLS > > algorithm: SunX509 > > store_type: JKS > > cipher_suites: > [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] > > require_client_auth: true > > > > # enable or disable client/server encryption. > > client_encryption_options: > > enabled: true > > keystore: /path/to/keystore > > keystore_password: > > #require_client_auth: true > > # Set trustor
[jira] [Commented] (CASSANDRA-6434) Repair-aware gc grace period
[ https://issues.apache.org/jira/browse/CASSANDRA-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070452#comment-14070452 ] Marcus Eriksson commented on CASSANDRA-6434: hmm, I think we were just being cautious with this feature in 2.1, should be fine in 3.0 though - created CASSANDRA-7586 > Repair-aware gc grace period > - > > Key: CASSANDRA-6434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6434 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: sankalp kohli >Assignee: Marcus Eriksson > Fix For: 3.0 > > > Since the reason for gcgs is to ensure that we don't purge tombstones until > every replica has been notified, it's redundant in a world where we're > tracking repair times per sstable (and repairing frequentily), i.e., a world > where we default to incremental repair a la CASSANDRA-5351. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7586) Mark SSTables as repaired after full repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-7586: --- Description: In 2.1 we avoided anticompaction and marking sstables as repaired after old-style full repairs (reasoning was that we wanted users to be able to carry on as before) In 3.0 incremental repairs is on by default and we should always mark and anticompact sstables was: In 2.1 we avoided anticompaction and marking sstables as repaired after old-style full repairs (reasoning was that we wanted users to be able to carry on as before - the impact ) In 3.0 incremental repairs is on by default and we should always mark and anticompact sstables > Mark SSTables as repaired after full repairs > > > Key: CASSANDRA-7586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7586 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson > Fix For: 3.0 > > > In 2.1 we avoided anticompaction and marking sstables as repaired after > old-style full repairs (reasoning was that we wanted users to be able to > carry on as before) > In 3.0 incremental repairs is on by default and we should always mark and > anticompact sstables -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7585) cassandra sstableloader connection refused with inter_node_encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-7585: -- Assignee: Yuki Morishita hmm, streaming determines whether to use secure connection based on settings in cassandra.yaml, which sstableloader does not require/load. So it always connects none secure port. I think loading cassandra.yaml is not a noption since it does load unnecessary things that sometimes cause trouble on tools. Maybe write custom config loader that just use part of cassandra.yaml is the way to go. > cassandra sstableloader connection refused with inter_node_encryption > - > > Key: CASSANDRA-7585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7585 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Reporter: Samphel Norden >Assignee: Yuki Morishita > > cassandra sstableloader connection refused with inter_node_encryption > When using sstableloader to import tables (cassandra 2.0.5) with inter-node > encryption and client encryption enabled, I get a connection refused error > I am using > sstableloader -d $myhost -p 9160 -u cassandra -pw cassandra -ciphers > TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA > -st JKS -tf org.apache.cassandra.thrift.SSLTransportFactory -ts > /path/to/truststore -tspw $fullpath/$table > Errors out with > Streaming session ID: 1bc395c0-fbb2-11e3-9812-73da15121373 > WARN 17:13:34,147 Failed attempt 1 to connect to > Similar problem reported in cassandra 2.0.8 by another user > http://stackoverflow.com/questions/24390604/cassandra-sstableloader-connection-refused-with-inter-node-encryption > == > Relevant cassandra.yaml snippet (with obfuscation) > server_encryption_options: > > internode_encryption: all > > keystore:/path/to/keystore > > keystore_password: > > truststore:/path/to/truststore > > truststore_password: > > # More advanced defaults below: > > protocol: TLS > > algorithm: SunX509 > > store_type: JKS > > cipher_suites: > [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] > > require_client_auth: true > > > > # enable or disable client/server encryption. > > client_encryption_options: > > enabled: true > > keystore: /path/to/keystore > > keystore_password: > > #require_client_auth: true > > # Set trustore and truststore_password if require_client_auth is true > > truststore:/path/to/truststore > > truststore_password: > > # More advanced defaults below: > > protocol: TLS > > algorithm: SunX509 >
[jira] [Created] (CASSANDRA-7586) Mark SSTables as repaired after full repairs
Marcus Eriksson created CASSANDRA-7586: -- Summary: Mark SSTables as repaired after full repairs Key: CASSANDRA-7586 URL: https://issues.apache.org/jira/browse/CASSANDRA-7586 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson Fix For: 3.0 In 2.1 we avoided anticompaction and marking sstables as repaired after old-style full repairs (reasoning was that we wanted users to be able to carry on as before - the impact ) In 3.0 incremental repairs is on by default and we should always mark and anticompact sstables -- This message was sent by Atlassian JIRA (v6.2#6252)
