[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap after long GC pause
[
https://issues.apache.org/jira/browse/CASSANDRA-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961750#comment-14961750
]
Mikhail Stepura commented on CASSANDRA-10449:
-
CASSANDRA-9681?
> OOM on bootstrap after long GC pause
>
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
> Labels: gc
> Fix For: 2.1.x
>
> Attachments: GCpath.txt, heap_dump.png, system.log.10-05,
> thread_dump.log, threads.txt
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and
> 500-700GB per node. SSTable counts are <10 per table. I am attempting to
> provision additional nodes, but bootstrapping OOMs every time after about 10
> hours with a sudden long GC pause:
> {noformat}
> INFO [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old
> Generation GC in 1586126ms. G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to
> no avail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10449) OOM on bootstrap after long GC pause
[
https://issues.apache.org/jira/browse/CASSANDRA-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961726#comment-14961726
]
Mikhail Stepura edited comment on CASSANDRA-10449 at 10/17/15 4:50 AM:
---
So, there are 2 ColumnFamilyStores with 6G of memtables each (5797 'live'
memtables per intsance) in the heap, but for some reason they are not being
flushed. All 32 MemtableFlushWriters (and 1 post-flush) are waiting on
{{writeBarrier}} s
was (Author: mishail):
So, there are 2 6G memtables in the heap, but for some reason they are not
being flushed. All 32 MemtableFlushWriters (and 1 post-flush) are waiting on
{{writeBarrier}} s
> OOM on bootstrap after long GC pause
>
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
> Labels: gc
> Fix For: 2.1.x
>
> Attachments: GCpath.txt, heap_dump.png, system.log.10-05,
> thread_dump.log, threads.txt
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and
> 500-700GB per node. SSTable counts are <10 per table. I am attempting to
> provision additional nodes, but bootstrapping OOMs every time after about 10
> hours with a sudden long GC pause:
> {noformat}
> INFO [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old
> Generation GC in 1586126ms. G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to
> no avail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10449) OOM on bootstrap after long GC pause
[
https://issues.apache.org/jira/browse/CASSANDRA-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-10449:
Attachment: GCpath.txt
threads.txt
So, there are 2 6G memtables in the heap, but for some reason they are not
being flushed. All 32 MemtableFlushWriters (and 1 post-flush) are waiting on
{{writeBarrier}} s
> OOM on bootstrap after long GC pause
>
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
> Labels: gc
> Fix For: 2.1.x
>
> Attachments: GCpath.txt, heap_dump.png, system.log.10-05,
> thread_dump.log, threads.txt
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and
> 500-700GB per node. SSTable counts are <10 per table. I am attempting to
> provision additional nodes, but bootstrapping OOMs every time after about 10
> hours with a sudden long GC pause:
> {noformat}
> INFO [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old
> Generation GC in 1586126ms. G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to
> no avail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap after long GC pause
[
https://issues.apache.org/jira/browse/CASSANDRA-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961610#comment-14961610
]
Mikhail Stepura commented on CASSANDRA-10449:
-
What was the heap size for the dump? 16G?
> OOM on bootstrap after long GC pause
>
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
> Labels: gc
> Fix For: 2.1.x
>
> Attachments: heap_dump.png, system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and
> 500-700GB per node. SSTable counts are <10 per table. I am attempting to
> provision additional nodes, but bootstrapping OOMs every time after about 10
> hours with a sudden long GC pause:
> {noformat}
> INFO [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old
> Generation GC in 1586126ms. G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to
> no avail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap after long GC pause
[
https://issues.apache.org/jira/browse/CASSANDRA-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961340#comment-14961340
]
Mikhail Stepura commented on CASSANDRA-10449:
-
Any chance to get the dump file itself? Of course if it doesn't contain any
sensible information.
> OOM on bootstrap after long GC pause
>
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
> Labels: gc
> Fix For: 2.1.x
>
> Attachments: heap_dump.png, system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and
> 500-700GB per node. SSTable counts are <10 per table. I am attempting to
> provision additional nodes, but bootstrapping OOMs every time after about 10
> hours with a sudden long GC pause:
> {noformat}
> INFO [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old
> Generation GC in 1586126ms. G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to
> no avail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap due to long GC pause
[
https://issues.apache.org/jira/browse/CASSANDRA-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959148#comment-14959148
]
Mikhail Stepura commented on CASSANDRA-10449:
-
I would love to get hold of a heapdump for that OOM. At least we could figure
out what's consuming the heap.
> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
> Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05, thread_dump.log
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and
> 500-700GB per node. SSTable counts are <10 per table. I am attempting to
> provision additional nodes, but bootstrapping OOMs every time after about 10
> hours with a sudden long GC pause:
> {noformat}
> INFO [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old
> Generation GC in 1586126ms. G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to
> no avail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10515) Commit logs back up with move to 2.1.10
[
https://issues.apache.org/jira/browse/CASSANDRA-10515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959074#comment-14959074
]
Mikhail Stepura commented on CASSANDRA-10515:
-
[~jeffery.griffith] could you please attach a thread dump as well?
> Commit logs back up with move to 2.1.10
> ---
>
> Key: CASSANDRA-10515
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10515
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: redhat 6.5, cassandra 2.1.10
>Reporter: Jeff Griffith
>Assignee: Branimir Lambov
>Priority: Critical
> Labels: commitlog, triage
> Attachments: CommitLogProblem.jpg, CommitLogSize.jpg, system.log.clean
>
>
> After upgrading from cassandra 2.0.x to 2.1.10, we began seeing problems
> where some nodes break the 12G commit log max we configured and go as high as
> 65G or more before it restarts. Once it reaches the state of more than 12G
> commit log files, "nodetool compactionstats" hangs. Eventually C* restarts
> without errors (not sure yet whether it is crashing but I'm checking into it)
> and the cleanup occurs and the commit logs shrink back down again. Here is
> the nodetool compactionstats immediately after restart.
> {code}
> jgriffith@prod1xc1.c2.bf1:~$ ndc
> pending tasks: 2185
>compaction type keyspace table completed
> totalunit progress
> Compaction SyncCore *cf1* 61251208033
> 170643574558 bytes 35.89%
> Compaction SyncCore *cf2* 19262483904
> 19266079916 bytes 99.98%
> Compaction SyncCore *cf3*6592197093
> 6592316682 bytes100.00%
> Compaction SyncCore *cf4*3411039555
> 3411039557 bytes100.00%
> Compaction SyncCore *cf5*2879241009
> 2879487621 bytes 99.99%
> Compaction SyncCore *cf6* 21252493623
> 21252635196 bytes100.00%
> Compaction SyncCore *cf7* 81009853587
> 81009854438 bytes100.00%
> Compaction SyncCore *cf8*3005734580
> 3005768582 bytes100.00%
> Active compaction remaining time :n/a
> {code}
> I was also doing periodic "nodetool tpstats" which were working but not being
> logged in system.log on the StatusLogger thread until after the compaction
> started working again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10401) json2sstable fails with NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14937737#comment-14937737
]
Mikhail Stepura commented on CASSANDRA-10401:
-
BTW, did colum family {{table_name-3264cbe063c211e5bc34e746786b7b29}} exist
when {{json2sstable}} was executed?
> json2sstable fails with NPE
> ---
>
> Key: CASSANDRA-10401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10401
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Cassandra 2.1.8.621
>Reporter: Jose Martinez Poblete
>
> We have the following table...
> {noformat}
> CREATE TABLE keyspace_name.table_name (
> col1 text,
> col2 text,
> col3 text,
> col4 text,
> PRIMARY KEY ((col1, col2), col3)
> ) WITH CLUSTERING ORDER BY (col3 ASC)
> {noformat}
> And the following json in a file created from sstable2json tool
> {noformat}
> [
> {"key": "This is col1:This is col2,
> "cells": [["This is col3:","",1443217787319002],
>["This is col3:"col4","This is col4",1443217787319002]]}
> ]
> {noformat}
> Let's say we deleted that record form the DB and wanted to bring it back
> If we try to create an sstable from this data in a json file named
> test_file.json, we get a NPE
> {noformat}
> -bash-4.1$ json2sstable -K elp -c table_name-3264cbe063c211e5bc34e746786b7b29
> test_file.json
> /var/lib/cassandra/data/keyspace_name/table_name-3264cbe063c211e5bc34e746786b7b29/keyspace_name-table_name-ka-1-Data.db
> Importing 1 keys...
> java.lang.NullPointerException
> at
> org.apache.cassandra.tools.SSTableImport.getKeyValidator(SSTableImport.java:442)
> at
> org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:316)
> at
> org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:287)
> at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:514)
> ERROR: null
> -bash-4.1$
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9777) If you have a ~/.cqlshrc and a ~/.cassandra/cqlshrc, cqlsh will overwrite the latter with the former
[
https://issues.apache.org/jira/browse/CASSANDRA-9777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634165#comment-14634165
]
Mikhail Stepura commented on CASSANDRA-9777:
bq. I'm not sure which of the two possible cqlshrc take precedence so I just
assumed it was the latter
I have no strong preferences either. [~thobbs] [~iamaleksey] any thoughts?
> If you have a ~/.cqlshrc and a ~/.cassandra/cqlshrc, cqlsh will overwrite the
> latter with the former
>
>
> Key: CASSANDRA-9777
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9777
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jon Moses
>Assignee: David Kua
> Labels: cqlsh
> Fix For: 2.2.x
>
>
> If you have a .cqlshrc file, and a ~/.cassandra/cqlshrc file, when you run
> `cqlsh`, it will overwrite the latter with the former.
> https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L202
> If the 'new' path exists (~/.cassandra/cqlsh), cqlsh should either WARN or
> just leave the files alone.
> {noformat}
> ~$ cat .cqlshrc
> [authentication]
> ~$ cat .cassandra/cqlshrc
> [connection]
> ~$ cqlsh
> ~$ cat .cqlshrc
> cat: .cqlshrc: No such file or directory
> ~$ cat .cassandra/cqlshrc
> [authentication]
> ~$
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9385) cqlsh autocomplete does not work for DTCS min_threshold
[
https://issues.apache.org/jira/browse/CASSANDRA-9385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14579590#comment-14579590
]
Mikhail Stepura commented on CASSANDRA-9385:
[~alex.buck10] you should use {{nose}} to run those tests
> cqlsh autocomplete does not work for DTCS min_threshold
> ---
>
> Key: CASSANDRA-9385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9385
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>Priority: Trivial
> Labels: cqlsh, lhf
>
> Confirmed that min_threshold is a valid parameter for DTCS:
> {code}
> create TABLE test1 (key text, col1 text, primary key (key)) WITH compaction =
> {'class': 'DateTieredCompactionStrategy', 'min_threshold': '4' };
> {code}
> But the min_threshold does not appear in the tab auto complete options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8735) Batch log replication is not randomized when there are only 2 racks
[ https://issues.apache.org/jira/browse/CASSANDRA-8735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14570189#comment-14570189 ] Mikhail Stepura commented on CASSANDRA-8735: [~yukim]. I don't remember. It looks like I made that test case based on the assumption that the behavior from Jonathan's patch CASSANDRA-6551 #2 *is* the expected one. > Batch log replication is not randomized when there are only 2 racks > --- > > Key: CASSANDRA-8735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8735 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Mihai Suteu >Priority: Minor > Fix For: 2.1.x, 2.2.x > > Attachments: CASSANDRA-8735.patch > > > Batch log replication is not randomized and the same 2 nodes can be picked up > when there are only 2 racks in the cluster. > https://github.com/apache/cassandra/blob/cassandra-2.0.11/src/java/org/apache/cassandra/service/BatchlogEndpointSelector.java#L72-73 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9385) cqlsh autocomplete does not work for DTCS min_threshold
[
https://issues.apache.org/jira/browse/CASSANDRA-9385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-9385:
---
Assignee: (was: Mikhail Stepura)
> cqlsh autocomplete does not work for DTCS min_threshold
> ---
>
> Key: CASSANDRA-9385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9385
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>Priority: Trivial
> Labels: lhf
>
> Confirmed that min_threshold is a valid parameter for DTCS:
> {code}
> create TABLE test1 (key text, col1 text, primary key (key)) WITH compaction =
> {'class': 'DateTieredCompactionStrategy', 'min_threshold': '4' };
> {code}
> But the min_threshold does not appear in the tab auto complete options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9385) cqlsh autocomplete does not work for DTCS min_threshold
[
https://issues.apache.org/jira/browse/CASSANDRA-9385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14566251#comment-14566251
]
Mikhail Stepura commented on CASSANDRA-9385:
Need to adjust options in {{cql3handling.py}}
> cqlsh autocomplete does not work for DTCS min_threshold
> ---
>
> Key: CASSANDRA-9385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9385
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>Priority: Trivial
> Labels: lhf
>
> Confirmed that min_threshold is a valid parameter for DTCS:
> {code}
> create TABLE test1 (key text, col1 text, primary key (key)) WITH compaction =
> {'class': 'DateTieredCompactionStrategy', 'min_threshold': '4' };
> {code}
> But the min_threshold does not appear in the tab auto complete options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9385) cqlsh autocomplete does not work for DTCS min_threshold
[
https://issues.apache.org/jira/browse/CASSANDRA-9385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-9385:
---
Labels: lhf (was: )
> cqlsh autocomplete does not work for DTCS min_threshold
> ---
>
> Key: CASSANDRA-9385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9385
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>Assignee: Mikhail Stepura
>Priority: Trivial
> Labels: lhf
>
> Confirmed that min_threshold is a valid parameter for DTCS:
> {code}
> create TABLE test1 (key text, col1 text, primary key (key)) WITH compaction =
> {'class': 'DateTieredCompactionStrategy', 'min_threshold': '4' };
> {code}
> But the min_threshold does not appear in the tab auto complete options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7212) Allow to switch user within CQLSH session
[ https://issues.apache.org/jira/browse/CASSANDRA-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-7212: --- Fix Version/s: (was: 2.0.15) 2.0.16 > Allow to switch user within CQLSH session > - > > Key: CASSANDRA-7212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7212 > Project: Cassandra > Issue Type: Improvement > Components: API > Environment: [cqlsh 4.1.1 | Cassandra 2.0.7.31 | CQL spec 3.1.1 | > Thrift protocol 19.39.0] >Reporter: Jose Martinez Poblete >Assignee: Carl Yeksigian > Labels: cqlsh > Fix For: 2.2.0 beta 1, 2.1.6, 2.0.16 > > Attachments: 7212-2.0-v5.txt, 7212-2.1-v5.txt, 7212-v3.txt, > 7212-v4.txt, 7212_1.patch, 7212_v2.patch > > > Once a user is logged into CQLSH, it is not possible to switch to another > user without exiting and relaunch > This is a feature offered in postgres and probably other databases: > http://secure.encivasolutions.com/knowledgebase.php?action=displayarticle&id=1126 > > Perhaps this could be implemented on CQLSH as part of the "USE" directive: > USE [USER] [password] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9306) Test coverage for cqlsh COPY
[
https://issues.apache.org/jira/browse/CASSANDRA-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14556480#comment-14556480
]
Mikhail Stepura commented on CASSANDRA-9306:
http://cassci.datastax.com/job/cassandra-2.0_novnode_dtest/24/testReport/junit/cqlsh_tests/TestCqlsh/test_eat_glass/
> Test coverage for cqlsh COPY
>
>
> Key: CASSANDRA-9306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9306
> Project: Cassandra
> Issue Type: Test
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Jim Witschey
> Labels: cqlsh
> Fix For: 2.1.6, 2.0.16, 2.2.0 rc1
>
>
> We need much more thorough test coverage for cqlsh's COPY TO/FROM commands.
> There is one existing basic dtest ({{cqlsh_tests.py:TestCqlsh.test_copy_to}})
> that we can use as a starting point for new tests.
> The following things need to be tested:
> * Non-default delimiters
> * Null fields and non-default null markers
> * Skipping a header line
> * Explicit column ordering
> * Column names that need to be quoted
> * Every supported C* data type
> * Data that fails validation server-side
> * Wrong number of columns
> * Node going down during COPY operation
> In the non-failure cases, the tests should generally inserted data into
> Cassandra, run COPY TO to dump the data to CSV, truncate, run COPY FROM to
> reimport the data, and then verify that the reloaded data matches the
> originally inserted data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9306) Test coverage for cqlsh COPY
[
https://issues.apache.org/jira/browse/CASSANDRA-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14556440#comment-14556440
]
Mikhail Stepura commented on CASSANDRA-9306:
I'm having the same problem using "cassandra-2.0.15" tag
> Test coverage for cqlsh COPY
>
>
> Key: CASSANDRA-9306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9306
> Project: Cassandra
> Issue Type: Test
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Jim Witschey
> Labels: cqlsh
> Fix For: 2.1.6, 2.0.16, 2.2.0 rc1
>
>
> We need much more thorough test coverage for cqlsh's COPY TO/FROM commands.
> There is one existing basic dtest ({{cqlsh_tests.py:TestCqlsh.test_copy_to}})
> that we can use as a starting point for new tests.
> The following things need to be tested:
> * Non-default delimiters
> * Null fields and non-default null markers
> * Skipping a header line
> * Explicit column ordering
> * Column names that need to be quoted
> * Every supported C* data type
> * Data that fails validation server-side
> * Wrong number of columns
> * Node going down during COPY operation
> In the non-failure cases, the tests should generally inserted data into
> Cassandra, run COPY TO to dump the data to CSV, truncate, run COPY FROM to
> reimport the data, and then verify that the reloaded data matches the
> originally inserted data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7458) functional indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-7458:
---
Assignee: (was: Mikhail Stepura)
> functional indexes
> --
>
> Key: CASSANDRA-7458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7458
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
>Reporter: Jonathan Ellis
> Fix For: 3.x
>
>
> Indexing information derived from the row can be powerful. For example,
> using the hypothetical {{extract_date}} function,
> {code}
> create table ticks (
> symbol text,
> ticked_at datetime,
> price int,
> tags set,
> PRIMARY KEY (symbol, ticked_at)
> );
> CREATE INDEX ticks_by_day ON ticks(extract_date(ticked_at));
> SELECT * FROM ticks_by_day WHERE extract_date(ticked_at) = '2014-5-13';
> {code}
> http://www.postgresql.org/docs/9.3/static/indexes-expressional.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7814) enable describe on indices
[ https://issues.apache.org/jira/browse/CASSANDRA-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371461#comment-14371461 ] Mikhail Stepura commented on CASSANDRA-7814: bq. So we should not commit until the driver has been updated. If driver ticket is rejected or is not ready in time we can always rework the patch to loop on tables and columns. We usually build an "internal" version of the driver with the changes and commit with that version > enable describe on indices > -- > > Key: CASSANDRA-7814 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7814 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: radha >Assignee: Stefania >Priority: Minor > Fix For: 2.1.4 > > > Describe index should be supported, right now, the only way is to export the > schema and find what it really is before updating/dropping the index. > verified in > [cqlsh 3.1.8 | Cassandra 1.2.18.1 | CQL spec 3.0.0 | Thrift protocol 19.36.2] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7220) Nodes hang with 100% CPU load
[
https://issues.apache.org/jira/browse/CASSANDRA-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14351775#comment-14351775
]
Mikhail Stepura commented on CASSANDRA-7220:
I've seen similar behavior because of CASSANDRA-8485, and there is ~20min delay
in flushing in the logs
{code}
INFO [OptionalTasks:1] 2014-08-17 23:13:53,303 MeteredFlusher.java (line 58)
flushing high-traffic column family CFS(Keyspace='services',
ColumnFamily='service_request_count_per_minute') (estimated 16777216 bytes)
..
INFO [OptionalTasks:1] 2014-08-17 23:34:26,217 MeteredFlusher.java (line 58)
flushing high-traffic column family CFS(Keyspace='services',
ColumnFamily='service_request_count') (estimated 12582912 bytes)
{code}
> Nodes hang with 100% CPU load
> -
>
> Key: CASSANDRA-7220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7220
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: C* 2.0.7
> 4 nodes cluster on 12 core machines
>Reporter: Robert Stupp
> Attachments: c-12-read-100perc-cpu.zip, system.log
>
>
> I've ran a test that both reads and writes rows.
> After some time, all writes succeeded and all reads stopped.
> Two of the four nodes have 16 of 16 threads of the "ReadStage" thread pool
> running. The number of pending task continuouly grows on these nodes.
> I have attached outputs of the stack traces and some diagnostic output from
> "nodetool tpstats"
> "nodetool status" shows all nodes as UN.
> I had run that test previously without any issues in with the same
> configuration.
> Some "specials" from cassandra.yaml:
> - key_cache_size_in_mb: 1024
> - row_cache_size_in_mb: 8192
> The nodes running at 100% CPU are "node2" and "node3". node1&node4 are fine.
> I'm not sure if it is reproducable - but it's definitly not a good behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8919) cqlsh return error in querying of CompositeType data
[
https://issues.apache.org/jira/browse/CASSANDRA-8919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8919:
---
Description:
cqlsh return below error when querying CompositeType data. Seems like
deserialize_safe is undefined for this CompositeType. Is it a issue need to fix?
{code}
cassandra@cqlsh:up_data> select * from test_stand;
Traceback (most recent call last):
File "/home/mql/bin/cqlsh", line 986, in perform_simple_statement
rows = self.session.execute(statement, trace=self.tracing_enabled)
File
"/home/mql/bin/../lib/cassandra-driver-internal-only-2.1.2.zip/cassandra-driver-2.1.2/cassandra/cluster.py",
line 1294, in execute
result = future.result(timeout)
File
"/home/mql/bin/../lib/cassandra-driver-internal-only-2.1.2.zip/cassandra-driver-2.1.2/cassandra/cluster.py",
line 2788, in result
raise self._final_exception
AttributeError: type object 'CompositeType(UTF8Type, Int32Type)' has no
attribute 'deserialize_safe'
{code}
Pre-condition (in cassandra-cli)
{code}
create keyspace up_data with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:1};
use up_data;
create column family test_stand
with column_type = 'Standard'
and comparator = 'UTF8Type'
and default_validation_class = 'BytesType'
and key_validation_class = 'UTF8Type'
and column_metadata = [
{column_name : 'UTF8Typefield',
validation_class : 'UTF8Type'},
{column_name : 'IntegerTypefield',
validation_class : 'IntegerType'},
{column_name : 'CompositeTypefield',
validation_class :
'CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.Int32Type)'}
] and compression_options = null;
set test_stand ['test_stand1']['UTF8Typefield']='utf8Type';
set test_stand ['test_stand1']['CompositeTypefield']='utf8Type,12';
{code}
was:
cqlsh return below error when querying CompositeType data. Seems like
deserialize_safe is undefined for this CompositeType. Is it a issue need to fix?
cassandra@cqlsh:up_data> select * from test_stand;
Traceback (most recent call last):
File "/home/mql/bin/cqlsh", line 986, in perform_simple_statement
rows = self.session.execute(statement, trace=self.tracing_enabled)
File
"/home/mql/bin/../lib/cassandra-driver-internal-only-2.1.2.zip/cassandra-driver-2.1.2/cassandra/cluster.py",
line 1294, in execute
result = future.result(timeout)
File
"/home/mql/bin/../lib/cassandra-driver-internal-only-2.1.2.zip/cassandra-driver-2.1.2/cassandra/cluster.py",
line 2788, in result
raise self._final_exception
AttributeError: type object 'CompositeType(UTF8Type, Int32Type)' has no
attribute 'deserialize_safe'
Pre-condition (in cassandra-cli)
create keyspace up_data with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:1};
use up_data;
create column family test_stand
with column_type = 'Standard'
and comparator = 'UTF8Type'
and default_validation_class = 'BytesType'
and key_validation_class = 'UTF8Type'
and column_metadata = [
{column_name : 'UTF8Typefield',
validation_class : 'UTF8Type'},
{column_name : 'IntegerTypefield',
validation_class : 'IntegerType'},
{column_name : 'CompositeTypefield',
validation_class :
'CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.Int32Type)'}
] and compression_options = null;
set test_stand ['test_stand1']['UTF8Typefield']='utf8Type';
set test_stand ['test_stand1']['CompositeTypefield']='utf8Type,12';
> cqlsh return error in querying of CompositeType data
>
>
> Key: CASSANDRA-8919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8919
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: SUSE 11 SP3, C* 2.1.2
>Reporter: Mark
>Priority: Minor
> Fix For: 2.1.2
>
>
> cqlsh return below error when querying CompositeType data. Seems like
> deserialize_safe is undefined for this CompositeType. Is it a issue need to
> fix?
> {code}
> cassandra@cqlsh:up_data> select * from test_stand;
> Traceback (most recent call last):
> File "/home/mql/bin/cqlsh", line 986, in perform_simple_statement
> rows = self.session.execute(statement, trace=self.tracing_enabled)
> File
> "/home/mql/bin/../lib/cassandra-driver-internal-only-2.1.2.zip/cassandra-driver-2.1.2/cassandra/cluster.py",
> line 1294, in execute
> result = future.result(timeout)
> File
> "/home/mql/bin/../lib/cassandra-driver-internal-only-2.1.2.zip/cassandra-driver-2.1.2/cassandra/cluster.py",
> line 2788, in result
> raise self._final_exception
> AttributeError: type object 'CompositeType(UTF8Type, Int32Type)' has no
> attribute 'deserialize_safe'
> {code}
> Pre-condition (in cassandra-cli)
> {code}
> create keyspace u
[jira] [Commented] (CASSANDRA-8716) "java.util.concurrent.ExecutionException: java.lang.AssertionError: Memory was freed" when running cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14321232#comment-14321232
]
Mikhail Stepura commented on CASSANDRA-8716:
{code}
8b5cf64043e2d002fdb91921319110911e332042 is the first bad commit
commit 8b5cf64043e2d002fdb91921319110911e332042
Author: Robert Stupp
Date: Tue Nov 25 19:45:34 2014 -0600
Backport CASSANDRA-7386
:100644 100644 7519653816322c2cd744b0d11f89caebd7ded42a
937edbbd3ccbcc5402c80a3726bd4520c239c7a3 M CHANGES.txt
:04 04 edcbc884d4b693cdaae047eec650035140c35cd2
c1a1d00be8b2f32a283ba9522a5e7829a956481a M src
:04 04 2b6dba89cdf5bd19bf0f4feadc49fcca0f7a7c5f
1e8e1b958fcd16630758b8a9a900c5f8e01602c6 M test
{code}
> "java.util.concurrent.ExecutionException: java.lang.AssertionError: Memory
> was freed" when running cleanup
> --
>
> Key: CASSANDRA-8716
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8716
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Centos 6.6, Cassandra 2.0.12, Oracle JDK 1.7.0_67
>Reporter: Imri Zvik
>Assignee: Benedict
>Priority: Minor
> Fix For: 2.0.13
>
> Attachments: system.log.gz
>
>
> {code}Error occurred during cleanup
> java.util.concurrent.ExecutionException: java.lang.AssertionError: Memory was
> freed
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.cassandra.db.compaction.CompactionManager.performAllSSTableOperation(CompactionManager.java:234)
> at
> org.apache.cassandra.db.compaction.CompactionManager.performCleanup(CompactionManager.java:272)
> at
> org.apache.cassandra.db.ColumnFamilyStore.forceCleanup(ColumnFamilyStore.java:1115)
> at
> org.apache.cassandra.service.StorageService.forceKeyspaceCleanup(StorageService.java:2177)
> at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
[jira] [Commented] (CASSANDRA-8711) cassandra 2.1.2 cqlsh not able to connect when ssl client encryption enabled
[
https://issues.apache.org/jira/browse/CASSANDRA-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307593#comment-14307593
]
Mikhail Stepura commented on CASSANDRA-8711:
http://www.datastax.com/documentation/cassandra/2.1/cassandra/security/secureCqlshSSL_t.html
Don't forget to use {{--ssl}} flag
> cassandra 2.1.2 cqlsh not able to connect when ssl client encryption enabled
>
>
> Key: CASSANDRA-8711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8711
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Liu
> Fix For: 2.1.3
>
>
> I have been trying to setup client encryption on a three nodes 2.1.2 version
> cassandra cluster and keep getting the following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'localhost':
> ConnectionShutdown('Connection (closed)> is already closed',)})
> {noformat}
> I tried with both cqlsh and datatax python cassandra-driver and no luck to
> login.
> I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
> {noformat}
> [authentication]
> username =
> password =
> [connection]
> hostname = localhost
> port = 9160
> factory = cqlshlib.ssl.ssl_transport_factory
> [ssl]
> certfile = /root/.cassandra/localhost_user1.pem
> validate = false ## Optional, true by default
> {noformat}
> my cassandra.yaml configuration related to client_encryptions:
> {noformat}
> client_encryption_options:
> enabled: True
> keystore: /etc/cassandra/conf/.keystore
> keystore_password: cassnest
> {noformat}
> the keystore, truststore, cert/pem (localhost_user1.pem) key have been
> verified to be working fine for datastax enterprise version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8711) cassandra 2.1.2 cqlsh not able to connect when ssl client encryption enabled
[
https://issues.apache.org/jira/browse/CASSANDRA-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307582#comment-14307582
]
Mikhail Stepura commented on CASSANDRA-8711:
Why 9160? Cqlsh in 2.1 doesn't use Thrift anymore
> cassandra 2.1.2 cqlsh not able to connect when ssl client encryption enabled
>
>
> Key: CASSANDRA-8711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8711
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Liu
> Fix For: 2.1.3
>
>
> I have been trying to setup client encryption on a three nodes 2.1.2 version
> cassandra cluster and keep getting the following error:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'localhost':
> ConnectionShutdown('Connection (closed)> is already closed',)})
> {noformat}
> I tried with both cqlsh and datatax python cassandra-driver and no luck to
> login.
> I created /rooot/.cassandra/cqlshrc file for cqlsh settings, the content is:
> {noformat}
> [authentication]
> username =
> password =
> [connection]
> hostname = localhost
> port = 9160
> factory = cqlshlib.ssl.ssl_transport_factory
> [ssl]
> certfile = /root/.cassandra/localhost_user1.pem
> validate = false ## Optional, true by default
> {noformat}
> my cassandra.yaml configuration related to client_encryptions:
> {noformat}
> client_encryption_options:
> enabled: True
> keystore: /etc/cassandra/conf/.keystore
> keystore_password: cassnest
> {noformat}
> the keystore, truststore, cert/pem (localhost_user1.pem) key have been
> verified to be working fine for datastax enterprise version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7094) Keyspace name quoting is handled inconsistently and strangely
[
https://issues.apache.org/jira/browse/CASSANDRA-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-7094:
---
Assignee: (was: Mikhail Stepura)
> Keyspace name quoting is handled inconsistently and strangely
> --
>
> Key: CASSANDRA-7094
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7094
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: cassandra 1.2.16
>Reporter: Karl Mueller
>Priority: Trivial
>
> Keyspaces which are named starting with capital letters (and perhaps other
> things) sometimes require double quotes and sometimes do not.
> For example, describe works without quotes:
> cqlsh> describe keyspace ProductGenomeLocal;
> CREATE KEYSPACE "ProductGenomeLocal" WITH replication = {
> 'class': 'SimpleStrategy',
> 'replication_factor': '3'
> };
> USE "ProductGenomeLocal";
> [...]
> But use will not:
> cqlsh> use ProductGenomeLocal;
> Bad Request: Keyspace 'productgenomelocal' does not exist
> It seems that qoutes should only really be necessary when there's spaces or
> other symbols that need to be quoted.
> At the least, the acceptance or failures of quotes should be consistent.
> Other minor annoyance: tab expansion works in use and describe with quotes,
> but will not work in either without quotes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7483) COPY FROM doesn't accept diacritical characters
[ https://issues.apache.org/jira/browse/CASSANDRA-7483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-7483: --- Assignee: (was: Mikhail Stepura) > COPY FROM doesn't accept diacritical characters > --- > > Key: CASSANDRA-7483 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7483 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jan Penninkhof >Priority: Minor > > The current version of the COPY command chokes on diacritical characters such > as ñ ë á and ù. It would be great if the COPY command would support these > characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7458) functional indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14247255#comment-14247255
]
Mikhail Stepura edited comment on CASSANDRA-7458 at 12/15/14 9:29 PM:
--
[~jbellis] I've almost completed the initial implementation, but had no time to
finish that. I hope I should be able to complete that somewhen in January.
was (Author: mishail):
[~jbellis] Iэму almost completed the initial implementation, but had no time to
finish that. I hope I should be able to complete that somewhen in January.
> functional indexes
> --
>
> Key: CASSANDRA-7458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7458
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
>Reporter: Jonathan Ellis
>Assignee: Mikhail Stepura
> Fix For: 3.0
>
>
> Indexing information derived from the row can be powerful. For example,
> using the hypothetical {{extract_date}} function,
> {code}
> create table ticks (
> symbol text,
> ticked_at datetime,
> price int,
> tags set,
> PRIMARY KEY (symbol, ticked_at)
> );
> CREATE INDEX ticks_by_day ON ticks(extract_date(ticked_at));
> SELECT * FROM ticks_by_day WHERE extract_date(ticked_at) = '2014-5-13';
> {code}
> http://www.postgresql.org/docs/9.3/static/indexes-expressional.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7458) functional indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14247255#comment-14247255
]
Mikhail Stepura commented on CASSANDRA-7458:
[~jbellis] Iэму almost completed the initial implementation, but had no time to
finish that. I hope I should be able to complete that somewhen in January.
> functional indexes
> --
>
> Key: CASSANDRA-7458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7458
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
>Reporter: Jonathan Ellis
>Assignee: Mikhail Stepura
> Fix For: 3.0
>
>
> Indexing information derived from the row can be powerful. For example,
> using the hypothetical {{extract_date}} function,
> {code}
> create table ticks (
> symbol text,
> ticked_at datetime,
> price int,
> tags set,
> PRIMARY KEY (symbol, ticked_at)
> );
> CREATE INDEX ticks_by_day ON ticks(extract_date(ticked_at));
> SELECT * FROM ticks_by_day WHERE extract_date(ticked_at) = '2014-5-13';
> {code}
> http://www.postgresql.org/docs/9.3/static/indexes-expressional.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8351) Running COPY FROM in cqlsh aborts with errors or segmentation fault
[
https://issues.apache.org/jira/browse/CASSANDRA-8351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8351:
---
Description:
Running Cassandra 2.1.2 binary tarball on a single instance.
Put together a script to try to reproduce this using data generated by
cassandra-stress.
Reproduction steps: Download files and run cqlsh -f stress.cql
This may need to run a couple of times before errors are encountered. I've seen
this work best when running after a fresh install.
Errors seen:
1.Segmentation fault (core dumped)
2.
{code}
stress.cql:24:line contains NULL byte
stress.cql:24:Aborting import at record #0. Previously-inserted values
still present.
71 rows imported in 0.100 seconds.{code}
3.
{code}*** glibc detected *** python: corrupted double-linked list:
0x01121ad0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f80fe0cdb96]
/lib/x86_64-linux-gnu/libc.so.6(+0x7fead)[0x7f80fe0ceead]
python[0x42615d]
python[0x501dc8]
python[0x4ff715]
python[0x425d02]
python(PyEval_EvalCodeEx+0x1c4)[0x575db4]
python[0x577be2]
python(PyObject_Call+0x36)[0x4d91b6]
python(PyEval_EvalFrameEx+0x2035)[0x54d8a5]
python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
python(PyEval_EvalFrameEx+0x7b8)[0x54c028]
python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
python(PyEval_EvalFrameEx+0x7b8)[0x54c028]
python(PyEval_EvalFrameEx+0xa02)[0x54c272]
python(PyEval_EvalFrameEx+0xa02)[0x54c272]
python(PyEval_EvalFrameEx+0xa02)[0x54c272]
python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
python(PyEval_EvalFrameEx+0x7b8)[0x54c028]
python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
python(PyEval_EvalFrameEx+0x7b8)[0x54c028]
python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
python[0x577be2]
python(PyObject_Call+0x36)[0x4d91b6]
python(PyEval_EvalFrameEx+0x2035)[0x54d8a5]
python(PyEval_EvalFrameEx+0xa02)[0x54c272]
python(PyEval_EvalFrameEx+0xa02)[0x54c272]
python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
python[0x577ab0]
python(PyObject_Call+0x36)[0x4d91b6]
python[0x4c91fa]
python(PyObject_Call+0x36)[0x4d91b6]
python(PyEval_CallObjectWithKeywords+0x36)[0x4d97c6]
python[0x4f7f58]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f80ff369e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f80fe1433fd]
=== Memory map:
0040-00672000 r-xp 08:01 1447344
/usr/bin/python2.7
00871000-00872000 r--p 00271000 08:01 1447344
/usr/bin/python2.7
00872000-008db000 rw-p 00272000 08:01 1447344
/usr/bin/python2.7
008db000-008ed000 rw-p 00:00 0
0090e000-0126 rw-p 00:00 0 [heap]
7f80ec00-7f80ec0aa000 rw-p 00:00 0
7f80ec0aa000-7f80f000 ---p 00:00 0
7f80f000-7f80f0021000 rw-p 00:00 0
7f80f0021000-7f80f400 ---p 00:00 0
7f80f400-7f80f4021000 rw-p 00:00 0
7f80f4021000-7f80f800 ---p 00:00 0
7f80fa713000-7f80fa714000 ---p 00:00 0
7f80fa714000-7f80faf14000 rw-p 00:00 0
[stack:7493]
7f80faf14000-7f80faf15000 ---p 00:00 0
7f80faf15000-7f80fb715000 rw-p 00:00 0
[stack:7492]
7f80fb715000-7f80fb716000 ---p 00:00 0
7f80fb716000-7f80fbf16000 rw-p 00:00 0
[stack:7491]
7f80fbf16000-7f80fbf21000 r-xp 08:01 1456254
/usr/lib/python2.7/lib-dynload/_json.so
7f80fbf21000-7f80fc12 ---p b000 08:01 1456254
/usr/lib/python2.7/lib-dynload/_json.so
7f80fc12-7f80fc121000 r--p a000 08:01 1456254
/usr/lib/python2.7/lib-dynload/_json.so
7f80fc121000-7f80fc122000 rw-p b000 08:01 1456254
/usr/lib/python2.7/lib-dynload/_json.so
7f80fc122000-7f80fc133000 r-xp 08:01 1585974
/usr/local/lib/python2.7/dist-packages/blist/_blist.so
7f80fc133000-7f80fc332000 ---p 00011000 08:01 1585974
/usr/local/lib/python2.7/dist-packages/blist/_blist.so
7f80fc332000-7f80fc333000 r--p 0001 08:01 1585974
/usr/local/lib/python2.7/dist-packages/blist/_blist.so
7f80fc333000-7f80fc335000 rw-p 00011000 08:01 1585974
/usr/local/lib/python2.7/dist-packages/blist/_blist.so
7f80fc335000-7f80fc349000 r-xp 08:01 1456262
/usr/lib/python2.7/lib-dynload/datetime.so
7f80fc349000-7f80fc548000 ---p 00014000 08:01 1456262
/usr/lib/python2.7/lib-dynload/datetime.so
7f80fc548000-7f80fc549000 r--p 00013000 08:01 1456262
/usr/lib/python2.7/lib-dynload/datetime.so
7f80fc549000-7f80fc54d000 rw-p 00014000 08:01 1456262
/usr/lib/python2.7/lib-dynload/datetime.so
7f80fc54d000-7f80fc56c000 r-xp 08:01 1456251
/usr/lib/python2.7/lib-dynload/
[jira] [Updated] (CASSANDRA-8370) cqlsh doesn't handle LIST statements correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-8370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8370:
---
Attachment: 8370v2.patch
[~beobal] I suggest moving all that logic into {{parse_for_table_meta}}.
Attaching v2 for that. What do you think?
> cqlsh doesn't handle LIST statements correctly
> --
>
> Key: CASSANDRA-8370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8370
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.3
>
> Attachments: 8370.txt, 8370v2.patch
>
>
> {{LIST USERS}} and {{LIST PERMISSIONS}} statements are not handled correctly
> by cqlsh in 2.1 (since CASSANDRA-6307).
> Running such a query results in errors along the lines of:
> {noformat}
> sam@easy:~/projects/cassandra$ bin/cqlsh --debug -u cassandra -p cassandra
> Using CQL driver: '/home/sam/projects/cassandra/bin/../lib/cassandra-driver-internal-only-2.1.2.zip/cassandra-driver-2.1.2/cassandra/__init__.py'>
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.2-SNAPSHOT | CQL spec 3.2.0 | Native protocol v3]
> Use HELP for help.
> cassandra@cqlsh> list users;
> Traceback (most recent call last):
> File "bin/cqlsh", line 879, in onecmd
> self.handle_statement(st, statementtext)
> File "bin/cqlsh", line 920, in handle_statement
> return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
> File "bin/cqlsh", line 953, in perform_statement
> result = self.perform_simple_statement(stmt)
> File "bin/cqlsh", line 989, in perform_simple_statement
> self.print_result(rows, self.parse_for_table_meta(statement.query_string))
> File "bin/cqlsh", line 970, in parse_for_table_meta
> return self.get_table_meta(ks, cf)
> File "bin/cqlsh", line 732, in get_table_meta
> ksmeta = self.get_keyspace_meta(ksname)
> File "bin/cqlsh", line 717, in get_keyspace_meta
> raise KeyspaceNotFound('Keyspace %r not found.' % ksname)
> KeyspaceNotFound: Keyspace None not found.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8370) cqlsh doesn't handle LIST statements correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-8370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14226800#comment-14226800
]
Mikhail Stepura commented on CASSANDRA-8370:
I doubt it was broken by CASSANDRA-6307, rather by CASSANDRA-6910
> cqlsh doesn't handle LIST statements correctly
> --
>
> Key: CASSANDRA-8370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8370
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.3
>
> Attachments: 8370.txt
>
>
> {{LIST USERS}} and {{LIST PERMISSIONS}} statements are not handled correctly
> by cqlsh in 2.1 (since CASSANDRA-6307).
> Running such a query results in errors along the lines of:
> {noformat}
> sam@easy:~/projects/cassandra$ bin/cqlsh --debug -u cassandra -p cassandra
> Using CQL driver: '/home/sam/projects/cassandra/bin/../lib/cassandra-driver-internal-only-2.1.2.zip/cassandra-driver-2.1.2/cassandra/__init__.py'>
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.2-SNAPSHOT | CQL spec 3.2.0 | Native protocol v3]
> Use HELP for help.
> cassandra@cqlsh> list users;
> Traceback (most recent call last):
> File "bin/cqlsh", line 879, in onecmd
> self.handle_statement(st, statementtext)
> File "bin/cqlsh", line 920, in handle_statement
> return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
> File "bin/cqlsh", line 953, in perform_statement
> result = self.perform_simple_statement(stmt)
> File "bin/cqlsh", line 989, in perform_simple_statement
> self.print_result(rows, self.parse_for_table_meta(statement.query_string))
> File "bin/cqlsh", line 970, in parse_for_table_meta
> return self.get_table_meta(ks, cf)
> File "bin/cqlsh", line 732, in get_table_meta
> ksmeta = self.get_keyspace_meta(ksname)
> File "bin/cqlsh", line 717, in get_keyspace_meta
> raise KeyspaceNotFound('Keyspace %r not found.' % ksname)
> KeyspaceNotFound: Keyspace None not found.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223655#comment-14223655
]
Mikhail Stepura commented on CASSANDRA-7874:
for some reason I'm unable to apply the patch
{code}
4:21 $ git apply 7874v6.txt
7874v6.txt:29: trailing whitespace.
7874v6.txt:30: trailing whitespace.
REM JSR223 - collect all JSR223 engines' jars
7874v6.txt:31: trailing whitespace.
for /D %%P in ("%CASSANDRA_HOME%\lib\jsr223\*.*") do (
7874v6.txt:32: trailing whitespace.
for %%i in ("%%P\*.jar") do call :append "%%i"
7874v6.txt:33: trailing whitespace.
)
error: patch failed: bin/cassandra.bat:85
error: bin/cassandra.bat: patch does not apply
error: patch failed: bin/cassandra.in.bat:49
error: bin/cassandra.in.bat: patch does not apply
error: patch failed: conf/cassandra-env.ps1:197
error: conf/cassandra-env.ps1: patch does not apply
✘-1 ~/Documents/workspace/cassandra [trunk|…1⚑ 5]
{code}
> Validate functionality of different JSR-223 providers in UDFs
> -
>
> Key: CASSANDRA-7874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7874
> Project: Cassandra
> Issue Type: Task
> Components: Core
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: udf
> Fix For: 3.0
>
> Attachments: 7874.txt, 7874v2.txt, 7874v3.txt, 7874v4.txt,
> 7874v5.txt, 7874v6.txt
>
>
> CASSANDRA-7526 introduces ability to support optional JSR-223 providers like
> Clojure, Jython, Groovy or JRuby.
> This ticket is about to test functionality with these providers but not to
> include them in C* distribution.
> Expected result is a "how to" document, wiki page or similar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8351) Running COPY FROM in cqlsh aborts with errors or segmentation fault
[ https://issues.apache.org/jira/browse/CASSANDRA-8351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14221327#comment-14221327 ] Mikhail Stepura commented on CASSANDRA-8351: [~joechu] which OS are you running? > Running COPY FROM in cqlsh aborts with errors or segmentation fault > --- > > Key: CASSANDRA-8351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8351 > Project: Cassandra > Issue Type: Bug >Reporter: Joseph Chu >Priority: Minor > Attachments: stress.cql, stress.csv > > > Running Cassandra 2.1.2 binary tarball on a single instance. > Put together a script to try to reproduce this using data generated by > cassandra-stress. > Reproduction steps: Download files and run cqlsh -f stress.cql > This may need to run a couple of times before errors are encountered. I've > seen this work best when running after a fresh install. > Errors seen: > 1.Segmentation fault (core dumped) > 2.stress.cql:24:line contains NULL byte >stress.cql:24:Aborting import at record #0. Previously-inserted values > still present. >71 rows imported in 0.100 seconds. > 3. *** glibc detected *** python: corrupted double-linked list: > 0x01121ad0 *** > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f80fe0cdb96] > /lib/x86_64-linux-gnu/libc.so.6(+0x7fead)[0x7f80fe0ceead] > python[0x42615d] > python[0x501dc8] > python[0x4ff715] > python[0x425d02] > python(PyEval_EvalCodeEx+0x1c4)[0x575db4] > python[0x577be2] > python(PyObject_Call+0x36)[0x4d91b6] > python(PyEval_EvalFrameEx+0x2035)[0x54d8a5] > python(PyEval_EvalCodeEx+0x1a2)[0x575d92] > python(PyEval_EvalFrameEx+0x7b8)[0x54c028] > python(PyEval_EvalCodeEx+0x1a2)[0x575d92] > python(PyEval_EvalFrameEx+0x7b8)[0x54c028] > python(PyEval_EvalFrameEx+0xa02)[0x54c272] > python(PyEval_EvalFrameEx+0xa02)[0x54c272] > python(PyEval_EvalFrameEx+0xa02)[0x54c272] > python(PyEval_EvalCodeEx+0x1a2)[0x575d92] > python(PyEval_EvalFrameEx+0x7b8)[0x54c028] > python(PyEval_EvalCodeEx+0x1a2)[0x575d92] > python(PyEval_EvalFrameEx+0x7b8)[0x54c028] > python(PyEval_EvalCodeEx+0x1a2)[0x575d92] > python[0x577be2] > python(PyObject_Call+0x36)[0x4d91b6] > python(PyEval_EvalFrameEx+0x2035)[0x54d8a5] > python(PyEval_EvalFrameEx+0xa02)[0x54c272] > python(PyEval_EvalFrameEx+0xa02)[0x54c272] > python(PyEval_EvalCodeEx+0x1a2)[0x575d92] > python[0x577ab0] > python(PyObject_Call+0x36)[0x4d91b6] > python[0x4c91fa] > python(PyObject_Call+0x36)[0x4d91b6] > python(PyEval_CallObjectWithKeywords+0x36)[0x4d97c6] > python[0x4f7f58] > /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f80ff369e9a] > /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f80fe1433fd] > === Memory map: > 0040-00672000 r-xp 08:01 1447344 > /usr/bin/python2.7 > 00871000-00872000 r--p 00271000 08:01 1447344 > /usr/bin/python2.7 > 00872000-008db000 rw-p 00272000 08:01 1447344 > /usr/bin/python2.7 > 008db000-008ed000 rw-p 00:00 0 > 0090e000-0126 rw-p 00:00 0 > [heap] > 7f80ec00-7f80ec0aa000 rw-p 00:00 0 > 7f80ec0aa000-7f80f000 ---p 00:00 0 > 7f80f000-7f80f0021000 rw-p 00:00 0 > 7f80f0021000-7f80f400 ---p 00:00 0 > 7f80f400-7f80f4021000 rw-p 00:00 0 > 7f80f4021000-7f80f800 ---p 00:00 0 > 7f80fa713000-7f80fa714000 ---p 00:00 0 > 7f80fa714000-7f80faf14000 rw-p 00:00 0 > [stack:7493] > 7f80faf14000-7f80faf15000 ---p 00:00 0 > 7f80faf15000-7f80fb715000 rw-p 00:00 0 > [stack:7492] > 7f80fb715000-7f80fb716000 ---p 00:00 0 > 7f80fb716000-7f80fbf16000 rw-p 00:00 0 > [stack:7491] > 7f80fbf16000-7f80fbf21000 r-xp 08:01 1456254 > /usr/lib/python2.7/lib-dynload/_json.so > 7f80fbf21000-7f80fc12 ---p b000 08:01 1456254 > /usr/lib/python2.7/lib-dynload/_json.so > 7f80fc12-7f80fc121000 r--p a000 08:01 1456254 > /usr/lib/python2.7/lib-dynload/_json.so > 7f80fc121000-7f80fc122000 rw-p b000 08:01 1456254 > /usr/lib/python2.7/lib-dynload/_json.so > 7f80fc122000-7f80fc133000 r-xp 08:01 1585974 > /usr/local/lib/python2.7/dist-packages/blist/_blist.so > 7f80fc133000-7f80fc332000 ---p 00011000 08:01 1585974 > /usr/local/lib/python2.7/dist-packages/blist/_blist.so > 7f80fc332000-7f80fc333000 r--p 0001 08:01 1585974 > /usr/local/lib/python2.7/dist-packages/blist/_blist.so > 7f80fc333000-7f80fc335000 rw-p 00011000 08:01 1
[jira] [Commented] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213754#comment-14213754
]
Mikhail Stepura commented on CASSANDRA-7813:
[~dbrosius] preparations for CASSANDRA-8053 probably
> Decide how to deal with conflict between native and user-defined functions
> --
>
> Key: CASSANDRA-7813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Robert Stupp
> Labels: cql
> Fix For: 3.0
>
> Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt,
> 7813v5.txt, 7813v6.txt, 7813v7.txt, 7813v8.txt
>
>
> We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
> 3.0, user will be able to define new functions. Now, there is a very high
> change that we will provide more native functions over-time (to be clear, I'm
> not particularly for adding native functions for allthethings just because we
> can, but it's clear that we should ultimately provide more than what we
> have). Which begs the question: how do we want to deal with the problem of
> adding a native function potentially breaking a previously defined
> user-defined function?
> A priori I see the following options (maybe there is more?):
> # don't do anything specific, hoping that it won't happen often and consider
> it a user problem if it does.
> # reserve a big number of names that we're hoping will cover all future need.
> # make native function and user-defined function syntactically distinct so it
> cannot happen.
> I'm not a huge fan of solution 1). Solution 2) is actually what we did for
> UDT but I think it's somewhat less practical here: there is so much types
> that it makes sense to provide natively and so it wasn't too hard to come up
> with a reasonably small list of types name to reserve just in case. This
> feels a lot harder for functions to me.
> Which leaves solution 3). Since we already have the concept of namespaces for
> functions, a simple idea would be to force user function to have namespace.
> We could even allow that namespace to be empty as long as we force the
> namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
> functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205140#comment-14205140 ] Mikhail Stepura commented on CASSANDRA-7874: @JoshuaMcKenzie could you please review v5 ? > Validate functionality of different JSR-223 providers in UDFs > - > > Key: CASSANDRA-7874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7874 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Fix For: 3.0 > > Attachments: 7874.txt, 7874v2.txt, 7874v3.txt, 7874v4.txt, 7874v5.txt > > > CASSANDRA-7526 introduces ability to support optional JSR-223 providers like > Clojure, Jython, Groovy or JRuby. > This ticket is about to test functionality with these providers but not to > include them in C* distribution. > Expected result is a "how to" document, wiki page or similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8277) Eclipse project: re-use test classes from an ant build
[
https://issues.apache.org/jira/browse/CASSANDRA-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8277:
---
Attachment: cassandra-2.1-8277.patch
Attaching a trivial patch for that
> Eclipse project: re-use test classes from an ant build
> --
>
> Key: CASSANDRA-8277
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8277
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Mikhail Stepura
>Assignee: Mikhail Stepura
>Priority: Trivial
> Labels: eclipse, tools
> Fix For: 2.1.3
>
> Attachments: cassandra-2.1-8277.patch
>
>
> As a continuation of CASSANDRA-8250 we can improve the Eclipse project a
> little bit more by re-using test classes compiled by ant.
> Currently Eclipse builds them by itself into {{build/classes/main}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8277) Eclipse project: re-use test classes from an ant build
Mikhail Stepura created CASSANDRA-8277:
--
Summary: Eclipse project: re-use test classes from an ant build
Key: CASSANDRA-8277
URL: https://issues.apache.org/jira/browse/CASSANDRA-8277
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Mikhail Stepura
Assignee: Mikhail Stepura
Priority: Trivial
Fix For: 2.1.3
As a continuation of CASSANDRA-8250 we can improve the Eclipse project a little
bit more by re-using test classes compiled by ant.
Currently Eclipse builds them by itself into {{build/classes/main}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[
https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201420#comment-14201420
]
Mikhail Stepura commented on CASSANDRA-8022:
I doubt that is network related. I suspect it's a way cqlsh is launched. It
prints no prompt, so I guess cqlsh 'thinks' it is launched not from a terminal
( i.e. {{sys.stdin.isatty() == false}}).
> cqlsh hangs indefinitely within a Docker container connecting to itself with
> hostname
> -
>
> Key: CASSANDRA-8022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04
> container.
>Reporter: Matthew O'Riordan
> Labels: cqlsh
>
> I am unable to use the `cqlsh` tool within a Docker container running
> Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as
> follows:
> ```
> cqlsh --username cassandra --password whatever $(hostname)
> ```
> When I run the `cqlsh` command after attaching to a running container (I use
> LXC containerisation that allows attaching to a running container and running
> a console), it simply hangs and never reports an error. With the `--debug`
> flag on, I get the following with:
> **cqlsh 4.1.1**
> ```
> $ cqlsh --debug --username cassandra --password obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'>
> Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'>
> ```
> It then hangs in this state indefinitely, I have no errors from `cqlsh` and
> no errors in the Cassandra log.
> **cqlsh 5.0.1**
> ```
> $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'>
> ```
> It then also hangs in this state indefinitely, I have no errors from `cqlsh`
> and no errors in the Cassandra log.
> What's interesting, and quite confusing is that:
> * I can telnet within the container as follows `telnet $(hostname) 9042` and
> I get a socket. When trying to issue some commands, I see Protocol errors in
> the Cassandra log thus verifying that the port is indeed open on the host
> that resolves from $(hostname)
> * If I `cqlsh` from another container or another host to the Cassandra
> container it works just fine.
> * I have tried disabling authentication altogether and using the
> AllowAllAuthenticator, and I experience the same problem.
> * `nodetool` works fine
> In the mean time, I am forced to `cqlsh` from another container as a
> workaround. Happy to try and do anything require to diagnose the cause of
> this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8222) Unable to connect to "any" server with cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201290#comment-14201290
]
Mikhail Stepura commented on CASSANDRA-8222:
[~nad2000] it looks like a package/module conflict. Do you have some custom/3rd
party "json" module on system?
{code}
16:33 $ python -c "import json; print dir(json); print json.__version__"
['JSONDecoder', 'JSONEncoder', '__all__', '__author__', '__builtins__',
'__doc__', '__file__', '__name__', '__package__', '__path__', '__version__',
'_default_decoder', '_default_encoder', 'decoder', 'dump', 'dumps', 'encoder',
'load', 'loads', 'scanner']
2.0.9
{code}
> Unable to connect to "any" server with cqlsh
>
>
> Key: CASSANDRA-8222
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8222
> Project: Cassandra
> Issue Type: Bug
> Environment: java -version
> java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
> python --version
> Python 2.7.8
>Reporter: RADOMIRS CIRSKIS
> Labels: cqlsh
>
> I was going through the http://wiki.apache.org/cassandra/GettingStarted
> 1. Installed cassandra
> 2. run cassandra: bin/cassandra -f
> 3. in another terminal attempt to run cqlsh: cqlsh
> 4. also I have tried explicitly: cqlsh 127.0.0.1 9042
> 5. it produces a message:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'127.0.0.1':
> AttributeError("'module' object has no attribute 'loads'",)})
> {noformat}
> Cassandra is running and listening on the port 9042:
> {noformat}
> ...
> INFO 03:36:08 Using Netty Version:
> [netty-buffer=netty-buffer-4.0.23.Final.208198c,
> netty-codec=netty-codec-4.0.23.Final.208198c,
> netty-codec-http=netty-codec-http-4.0.23.Final.208198c,
> netty-codec-socks=netty-codec-socks-4.0.23.Final.208198c,
> netty-common=netty-common-4.0.23.Final.208198c,
> netty-handler=netty-handler-4.0.23.Final.208198c,
> netty-transport=netty-transport-4.0.23.Final.208198c,
> netty-transport-rxtx=netty-transport-rxtx-4.0.23.Final.208198c,
> netty-transport-sctp=netty-transport-sctp-4.0.23.Final.208198c,
> netty-transport-udt=netty-transport-udt-4.0.23.Final.208198c]
> INFO 03:36:08 Starting listening for CQL clients on
> localhost/127.0.0.1:9042...
> INFO 03:36:09 Binding thrift service to localhost/127.0.0.1:9160
> INFO 03:36:09 Listening for thrift clients...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8226) Cannot call a column 'timestamp'
[
https://issues.apache.org/jira/browse/CASSANDRA-8226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura resolved CASSANDRA-8226.
Resolution: Duplicate
Fix Version/s: (was: 2.1.3)
2.1.2
Reproduced In: 2.1.1
Will be fixed by CASSANDRA-8262
> Cannot call a column 'timestamp'
>
>
> Key: CASSANDRA-8226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8226
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native
> protocol v3]
>Reporter: Dave Cunningham
>Assignee: Mikhail Stepura
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.2
>
>
> {code}
> create table test(date text, timestamp timeuuid, stuff text, PRIMARY
> KEY(date, timestamp));
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> select * from test where date = '20141030' order by timestamp limit 1;
> Traceback (most recent call last):
> File "bin/cqlsh", line 861, in onecmd
> self.handle_statement(st, statementtext)
> File "bin/cqlsh", line 901, in handle_statement
> return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
> File "bin/cqlsh", line 910, in handle_parse_error
> return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
> File "bin/cqlsh", line 935, in perform_statement
> result = self.perform_simple_statement(stmt)
> File "bin/cqlsh", line 968, in perform_simple_statement
> self.print_result(rows, self.parse_for_table_meta(statement.query_string))
> File "bin/cqlsh", line 946, in parse_for_table_meta
> parsed = cqlruleset.cql_parse(query_string)[1]
> IndexError: list index out of range
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8226) Cannot call a column 'timestamp'
[
https://issues.apache.org/jira/browse/CASSANDRA-8226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8226:
---
Fix Version/s: (was: 2.1.2)
2.1.3
> Cannot call a column 'timestamp'
>
>
> Key: CASSANDRA-8226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8226
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native
> protocol v3]
>Reporter: Dave Cunningham
>Assignee: Mikhail Stepura
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.3
>
>
> {code}
> create table test(date text, timestamp timeuuid, stuff text, PRIMARY
> KEY(date, timestamp));
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> select * from test where date = '20141030' order by timestamp limit 1;
> Traceback (most recent call last):
> File "bin/cqlsh", line 861, in onecmd
> self.handle_statement(st, statementtext)
> File "bin/cqlsh", line 901, in handle_statement
> return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
> File "bin/cqlsh", line 910, in handle_parse_error
> return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
> File "bin/cqlsh", line 935, in perform_statement
> result = self.perform_simple_statement(stmt)
> File "bin/cqlsh", line 968, in perform_simple_statement
> self.print_result(rows, self.parse_for_table_meta(statement.query_string))
> File "bin/cqlsh", line 946, in parse_for_table_meta
> parsed = cqlruleset.cql_parse(query_string)[1]
> IndexError: list index out of range
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8262) parse_for_table_meta errors out on queries with undefined grammars
[
https://issues.apache.org/jira/browse/CASSANDRA-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199343#comment-14199343
]
Mikhail Stepura commented on CASSANDRA-8262:
Can we change
{code}
if not rows and not table_meta:
return
elif not rows:
# print header only
...
{code}
to just
{code}
if not rows:
if not table_meta:
return
# print header only
...
{code}
> parse_for_table_meta errors out on queries with undefined grammars
> --
>
> Key: CASSANDRA-8262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8262
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Philip Thompson
> Labels: cqlsh
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8262-1.txt, cassandra-2.1-8262-2.txt
>
>
> CASSANDRA-6910 introduced changes to the cqlsh function
> {{parse_for_table_meta}} that cause an error to be thrown whenever a query
> does not have its grammar defined in cql3handling.py. However, this is
> affecting queries that are legitimate cql syntax and are accepted by
> Cassandra, but aren't defined in cqlsh.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8258) SELECT ... TOKEN() function broken in C* 2.1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199318#comment-14199318
]
Mikhail Stepura commented on CASSANDRA-8258:
[~philipthompson] Can we fix it just with {{ ::= |
"TOKEN"}} ? It would correspond Cassandra's CQL.g grammar file then
> SELECT ... TOKEN() function broken in C* 2.1.1
> --
>
> Key: CASSANDRA-8258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8258
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04 64-bit, Oracle Java 1.7.0_72
>Reporter: Lex Lythius
>Assignee: Philip Thompson
> Labels: cqlsh
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8258-1.txt, cassandra-2.1-8258-2.txt
>
>
> {code:title=Cassandra 2.1.1, Oracle Java 1.7.0_72, Ubuntu 14.04.1 64 bit}
> cqlsh:blink> show version;
> [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3]
> cqlsh:blink> select token(id) from users limit 1;
> list index out of range
> {code}
> versus
> {code:title=Cassandra 2.1.0, Oracle Java 1.7.0_67, Ubuntu 12.04.5 64 bit}
> cqlsh:blink> show version;
> [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> cqlsh:blink> select token(id) from users limit 1;
> token(id)
> --
> -9223237793432919630
> (1 rows)
> {code}
> It also fails with C* 2.1.1, Java 1.7.0_72, Ubuntu 12.04.5.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8262) parse_for_table_meta errors out on queries with undefined grammars
[
https://issues.apache.org/jira/browse/CASSANDRA-8262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199280#comment-14199280
]
Mikhail Stepura commented on CASSANDRA-8262:
Let's fallback to the old behavior
> parse_for_table_meta errors out on queries with undefined grammars
> --
>
> Key: CASSANDRA-8262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8262
> Project: Cassandra
> Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Philip Thompson
> Labels: cqlsh
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8262-1.txt
>
>
> CASSANDRA-6910 introduced changes to the cqlsh function
> {{parse_for_table_meta}} that cause an error to be thrown whenever a query
> does not have its grammar defined in cql3handling.py. However, this is
> affecting queries that are legitimate cql syntax and are accepted by
> Cassandra, but aren't defined in cqlsh.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8258) SELECT ... TOKEN() function broken in C* 2.1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199184#comment-14199184
]
Mikhail Stepura commented on CASSANDRA-8258:
[~philipthompson] I have no preferences :)
> SELECT ... TOKEN() function broken in C* 2.1.1
> --
>
> Key: CASSANDRA-8258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8258
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04 64-bit, Oracle Java 1.7.0_72
>Reporter: Lex Lythius
>Assignee: Philip Thompson
> Labels: cqlsh
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8258-1.txt
>
>
> {code:title=Cassandra 2.1.1, Oracle Java 1.7.0_72, Ubuntu 14.04.1 64 bit}
> cqlsh:blink> show version;
> [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3]
> cqlsh:blink> select token(id) from users limit 1;
> list index out of range
> {code}
> versus
> {code:title=Cassandra 2.1.0, Oracle Java 1.7.0_67, Ubuntu 12.04.5 64 bit}
> cqlsh:blink> show version;
> [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> cqlsh:blink> select token(id) from users limit 1;
> token(id)
> --
> -9223237793432919630
> (1 rows)
> {code}
> It also fails with C* 2.1.1, Java 1.7.0_72, Ubuntu 12.04.5.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8258) SELECT ... TOKEN() function broken in C* 2.1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199143#comment-14199143
]
Mikhail Stepura commented on CASSANDRA-8258:
I think we should fix {{parse_for_table_meta}} to handle the case when
{{cqlruleset.cql_parse}} returns unexpected result
> SELECT ... TOKEN() function broken in C* 2.1.1
> --
>
> Key: CASSANDRA-8258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8258
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04 64-bit, Oracle Java 1.7.0_72
>Reporter: Lex Lythius
>Assignee: Philip Thompson
> Labels: cqlsh
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8258-1.txt
>
>
> {code:title=Cassandra 2.1.1, Oracle Java 1.7.0_72, Ubuntu 14.04.1 64 bit}
> cqlsh:blink> show version;
> [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3]
> cqlsh:blink> select token(id) from users limit 1;
> list index out of range
> {code}
> versus
> {code:title=Cassandra 2.1.0, Oracle Java 1.7.0_67, Ubuntu 12.04.5 64 bit}
> cqlsh:blink> show version;
> [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> cqlsh:blink> select token(id) from users limit 1;
> token(id)
> --
> -9223237793432919630
> (1 rows)
> {code}
> It also fails with C* 2.1.1, Java 1.7.0_72, Ubuntu 12.04.5.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8258) SELECT ... TOKEN() function broken in C* 2.1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8258:
---
Assignee: Philip Thompson (was: Mikhail Stepura)
> SELECT ... TOKEN() function broken in C* 2.1.1
> --
>
> Key: CASSANDRA-8258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8258
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04 64-bit, Oracle Java 1.7.0_72
>Reporter: Lex Lythius
>Assignee: Philip Thompson
> Labels: cqlsh
> Fix For: 2.1.2
>
>
> {code:title=Cassandra 2.1.1, Oracle Java 1.7.0_72, Ubuntu 14.04.1 64 bit}
> cqlsh:blink> show version;
> [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3]
> cqlsh:blink> select token(id) from users limit 1;
> list index out of range
> {code}
> versus
> {code:title=Cassandra 2.1.0, Oracle Java 1.7.0_67, Ubuntu 12.04.5 64 bit}
> cqlsh:blink> show version;
> [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> cqlsh:blink> select token(id) from users limit 1;
> token(id)
> --
> -9223237793432919630
> (1 rows)
> {code}
> It also fails with C* 2.1.1, Java 1.7.0_72, Ubuntu 12.04.5.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8250) Eclipse project recompiles Thrift classes again
[
https://issues.apache.org/jira/browse/CASSANDRA-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8250:
---
Attachment: cassandra-2.1-8250.patch
Attaching a patch
> Eclipse project recompiles Thrift classes again
> ---
>
> Key: CASSANDRA-8250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8250
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Mikhail Stepura
>Assignee: Mikhail Stepura
>Priority: Trivial
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8250.patch
>
>
> Current workflow for {{generate-eclipse-files}} is
> # Compile {{$interface.thrift.dir/gen-java}} files to
> {{$build.classes.thrift}}.
> # Compile all other sources to {{$build.classes.main}}
> # Create an eclipse project with output folder == {{$build.classes.main}},
> and add {{$interface.thrift.dir}/gen-java}} as a source folder.
> When you start Eclipse with that project, Eclipse will recompile all the
> sources from {{$interface.thrift.dir}/gen-java}} to {{$build.classes.main}}
> (i.e to only known output folder), even though there are compiled classes in
> {{$build.classes.thrift}}.
> As a solution I suggest to remove {{$interface.thrift.dir}/gen-java}} as a
> "source" folder, and attach it as "source" to {{build/classes/thrift}}
> "library".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8250) Eclipse project recompiles Thrift classes again
[
https://issues.apache.org/jira/browse/CASSANDRA-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8250:
---
Summary: Eclipse project recompiles Thrift classes again (was: Eclipse
project recomiles Thrift classes again)
> Eclipse project recompiles Thrift classes again
> ---
>
> Key: CASSANDRA-8250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8250
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Mikhail Stepura
>Assignee: Mikhail Stepura
>Priority: Trivial
> Fix For: 2.1.2
>
>
> Current workflow for {{generate-eclipse-files}} is
> # Compile {{$interface.thrift.dir/gen-java}} files to
> {{$build.classes.thrift}}.
> # Compile all other sources to {{$build.classes.main}}
> # Create an eclipse project with output folder == {{$build.classes.main}},
> and add {{$interface.thrift.dir}/gen-java}} as a source folder.
> When you start Eclipse with that project, Eclipse will recompile all the
> sources from {{$interface.thrift.dir}/gen-java}} to {{$build.classes.main}}
> (i.e to only known output folder), even though there are compiled classes in
> {{$build.classes.thrift}}.
> As a solution I suggest to remove {{$interface.thrift.dir}/gen-java}} as a
> "source" folder, and attach it as "source" to {{build/classes/thrift}}
> "library".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8250) Eclipse project recomiles Thrift classes again
[
https://issues.apache.org/jira/browse/CASSANDRA-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8250:
---
Description:
Current workflow for {{generate-eclipse-files}} is
# Compile {{$interface.thrift.dir/gen-java}} files to {{$build.classes.thrift}}.
# Compile all other sources to {{$build.classes.main}}
# Create an eclipse project with output folder == {{$build.classes.main}}, and
add {{$interface.thrift.dir}/gen-java}} as a source folder.
When you start Eclipse with that project, Eclipse will recompile all the
sources from {{$interface.thrift.dir}/gen-java}} to {{$build.classes.main}}
(i.e to only known output folder), even though there are compiled classes in
{{$build.classes.thrift}}.
As a solution I suggest to remove {{$interface.thrift.dir}/gen-java}} as a
"source" folder, and attach it as "source" to {{build/classes/thrift}}
"library".
was:
Current workflow for {{generate-eclipse-files}} is
# Compile {{$interface.thrift.dir/gen-java}} files to {{$build.classes.thrift}}.
# Compile all other sources to {{$build.classes.main}}
# Create an eclipse project with output folder == {{$build.classes.main}}, and
add {{$interface.thrift.dir}/gen-java}} as a source folder.
When you start Eclipse with that project, Eclipse will recompile all the
sources from {{$interface.thrift.dir}/gen-java}} to {{$build.classes.main}},
even though there are compiled classes in {{$build.classes.thrift}}.
As a solution I suggest to remove {{$interface.thrift.dir}/gen-java}} as a
"source" folder, and attach it as "source" to {{build/classes/thrift}}
"library".
> Eclipse project recomiles Thrift classes again
> --
>
> Key: CASSANDRA-8250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8250
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Mikhail Stepura
>Assignee: Mikhail Stepura
>Priority: Trivial
> Fix For: 2.1.2
>
>
> Current workflow for {{generate-eclipse-files}} is
> # Compile {{$interface.thrift.dir/gen-java}} files to
> {{$build.classes.thrift}}.
> # Compile all other sources to {{$build.classes.main}}
> # Create an eclipse project with output folder == {{$build.classes.main}},
> and add {{$interface.thrift.dir}/gen-java}} as a source folder.
> When you start Eclipse with that project, Eclipse will recompile all the
> sources from {{$interface.thrift.dir}/gen-java}} to {{$build.classes.main}}
> (i.e to only known output folder), even though there are compiled classes in
> {{$build.classes.thrift}}.
> As a solution I suggest to remove {{$interface.thrift.dir}/gen-java}} as a
> "source" folder, and attach it as "source" to {{build/classes/thrift}}
> "library".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8250) Eclipse project recomiles Thrift classes again
Mikhail Stepura created CASSANDRA-8250:
--
Summary: Eclipse project recomiles Thrift classes again
Key: CASSANDRA-8250
URL: https://issues.apache.org/jira/browse/CASSANDRA-8250
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Mikhail Stepura
Assignee: Mikhail Stepura
Priority: Trivial
Fix For: 2.1.2
Current workflow for {{generate-eclipse-files}} is
# Compile {{$interface.thrift.dir/gen-java}} files to {{$build.classes.thrift}}.
# Compile all other sources to {{$build.classes.main}}
# Create an eclipse project with output folder == {{$build.classes.main}}, and
add {{$interface.thrift.dir}/gen-java}} as a source folder.
When you start Eclipse with that project, Eclipse will recompile all the
sources from {{$interface.thrift.dir}/gen-java}} to {{$build.classes.main}},
even though there are compiled classes in {{$build.classes.thrift}}.
As a solution I suggest to remove {{$interface.thrift.dir}/gen-java}} as a
"source" folder, and attach it as "source" to {{build/classes/thrift}}
"library".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8240) Attach existing sources to "Referenced libraries" in Eclipse project
[
https://issues.apache.org/jira/browse/CASSANDRA-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195559#comment-14195559
]
Mikhail Stepura commented on CASSANDRA-8240:
[~tjake] will be a more appropriate reviewer, probably :)
> Attach existing sources to "Referenced libraries" in Eclipse project
>
>
> Key: CASSANDRA-8240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8240
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Mikhail Stepura
>Assignee: Mikhail Stepura
>Priority: Trivial
> Labels: eclipse, tools
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8240-v2.patch, eclipse-sources.patch
>
>
> At the moment {{ant generate-eclipse-files}} adds all necessary jars to
> "Referenced libraries", but doesn't attach sources to those libraries.
> I'm attaching a simple patch which does that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8240) Attach existing sources to "Referenced libraries" in Eclipse project
[
https://issues.apache.org/jira/browse/CASSANDRA-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8240:
---
Reviewer: T Jake Luciani (was: Joshua McKenzie)
> Attach existing sources to "Referenced libraries" in Eclipse project
>
>
> Key: CASSANDRA-8240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8240
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Mikhail Stepura
>Assignee: Mikhail Stepura
>Priority: Trivial
> Labels: eclipse, tools
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8240-v2.patch, eclipse-sources.patch
>
>
> At the moment {{ant generate-eclipse-files}} adds all necessary jars to
> "Referenced libraries", but doesn't attach sources to those libraries.
> I'm attaching a simple patch which does that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6482) Add junitreport to ant test target
[ https://issues.apache.org/jira/browse/CASSANDRA-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-6482: --- Priority: Trivial (was: Minor) > Add junitreport to ant test target > -- > > Key: CASSANDRA-6482 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6482 > Project: Cassandra > Issue Type: Improvement > Components: Tests >Reporter: Michael Shuler >Assignee: Mikhail Stepura >Priority: Trivial > Labels: qa-resolved > Fix For: 2.1.2 > > Attachments: cassandra-2.1-6482.patch > > > Adding junitreport XML output for the unit tests will allow detailed > reporting and historical tracking in Jenkins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6482) Add junitreport to ant test target
[ https://issues.apache.org/jira/browse/CASSANDRA-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-6482: --- Attachment: cassandra-2.1-6482.patch I'm attaching a patch with junitreport > Add junitreport to ant test target > -- > > Key: CASSANDRA-6482 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6482 > Project: Cassandra > Issue Type: Improvement > Components: Tests >Reporter: Michael Shuler >Assignee: Mikhail Stepura >Priority: Minor > Labels: qa-resolved > Fix For: 2.1.2 > > Attachments: cassandra-2.1-6482.patch > > > Adding junitreport XML output for the unit tests will allow detailed > reporting and historical tracking in Jenkins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6482) Add junitreport to ant test target
[ https://issues.apache.org/jira/browse/CASSANDRA-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-6482: --- Fix Version/s: 2.1.2 > Add junitreport to ant test target > -- > > Key: CASSANDRA-6482 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6482 > Project: Cassandra > Issue Type: Improvement > Components: Tests >Reporter: Michael Shuler >Assignee: Mikhail Stepura >Priority: Minor > Labels: qa-resolved > Fix For: 2.1.2 > > > Adding junitreport XML output for the unit tests will allow detailed > reporting and historical tracking in Jenkins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CASSANDRA-6482) Add junitreport to ant test target
[ https://issues.apache.org/jira/browse/CASSANDRA-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura reopened CASSANDRA-6482: Assignee: Mikhail Stepura (was: Michael Shuler) I suggest to reopen this one, although not for a jenkins's sake, but to simplify analysis of local failures > Add junitreport to ant test target > -- > > Key: CASSANDRA-6482 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6482 > Project: Cassandra > Issue Type: Improvement > Components: Tests >Reporter: Michael Shuler >Assignee: Mikhail Stepura >Priority: Minor > Labels: qa-resolved > > Adding junitreport XML output for the unit tests will allow detailed > reporting and historical tracking in Jenkins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195072#comment-14195072 ] Mikhail Stepura commented on CASSANDRA-7874: [~snazy] I've verified all the instructions and they are correct, thanks! But you need to port your changes to windows .bat/.ps1 files as well. > Validate functionality of different JSR-223 providers in UDFs > - > > Key: CASSANDRA-7874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7874 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Fix For: 3.0 > > Attachments: 7874.txt, 7874v2.txt, 7874v3.txt, 7874v4.txt > > > CASSANDRA-7526 introduces ability to support optional JSR-223 providers like > Clojure, Jython, Groovy or JRuby. > This ticket is about to test functionality with these providers but not to > include them in C* distribution. > Expected result is a "how to" document, wiki page or similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-7874: --- Fix Version/s: 3.0 > Validate functionality of different JSR-223 providers in UDFs > - > > Key: CASSANDRA-7874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7874 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Fix For: 3.0 > > Attachments: 7874.txt, 7874v2.txt, 7874v3.txt, 7874v4.txt > > > CASSANDRA-7526 introduces ability to support optional JSR-223 providers like > Clojure, Jython, Groovy or JRuby. > This ticket is about to test functionality with these providers but not to > include them in C* distribution. > Expected result is a "how to" document, wiki page or similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193633#comment-14193633
]
Mikhail Stepura commented on CASSANDRA-7874:
[~snazy] do we really need those changes for {{DatacenterWriteResponseHandler}}
and {{ConsistencyLevel}} in this patch?
> Validate functionality of different JSR-223 providers in UDFs
> -
>
> Key: CASSANDRA-7874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7874
> Project: Cassandra
> Issue Type: Task
> Components: Core
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Labels: udf
> Attachments: 7874.txt, 7874v2.txt, 7874v3.txt
>
>
> CASSANDRA-7526 introduces ability to support optional JSR-223 providers like
> Clojure, Jython, Groovy or JRuby.
> This ticket is about to test functionality with these providers but not to
> include them in C* distribution.
> Expected result is a "how to" document, wiki page or similar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7874) Validate functionality of different JSR-223 providers in UDFs
[ https://issues.apache.org/jira/browse/CASSANDRA-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-7874: --- Reviewer: Mikhail Stepura > Validate functionality of different JSR-223 providers in UDFs > - > > Key: CASSANDRA-7874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7874 > Project: Cassandra > Issue Type: Task > Components: Core >Reporter: Robert Stupp >Assignee: Robert Stupp > Labels: udf > Attachments: 7874.txt, 7874v2.txt, 7874v3.txt > > > CASSANDRA-7526 introduces ability to support optional JSR-223 providers like > Clojure, Jython, Groovy or JRuby. > This ticket is about to test functionality with these providers but not to > include them in C* distribution. > Expected result is a "how to" document, wiki page or similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8240) Attach existing sources to "Referenced libraries" in Eclipse project
[
https://issues.apache.org/jira/browse/CASSANDRA-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8240:
---
Reviewer: Joshua McKenzie
[~JoshuaMcKenzie] could you please review?
> Attach existing sources to "Referenced libraries" in Eclipse project
>
>
> Key: CASSANDRA-8240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8240
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Mikhail Stepura
>Assignee: Mikhail Stepura
>Priority: Trivial
> Labels: eclipse, tools
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8240-v2.patch, eclipse-sources.patch
>
>
> At the moment {{ant generate-eclipse-files}} adds all necessary jars to
> "Referenced libraries", but doesn't attach sources to those libraries.
> I'm attaching a simple patch which does that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8240) Attach existing sources to "Referenced libraries" in Eclipse project
[
https://issues.apache.org/jira/browse/CASSANDRA-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8240:
---
Attachment: cassandra-2.1-8240-v2.patch
Attaching v2 of the patch which should work with JDK 8 as well (see
CASSANDRA-7430)
> Attach existing sources to "Referenced libraries" in Eclipse project
>
>
> Key: CASSANDRA-8240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8240
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Mikhail Stepura
>Assignee: Mikhail Stepura
>Priority: Trivial
> Labels: eclipse, tools
> Fix For: 2.1.2
>
> Attachments: cassandra-2.1-8240-v2.patch, eclipse-sources.patch
>
>
> At the moment {{ant generate-eclipse-files}} adds all necessary jars to
> "Referenced libraries", but doesn't attach sources to those libraries.
> I'm attaching a simple patch which does that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8240) Attach existing sources to "Referenced libraries" in Eclipse project
Mikhail Stepura created CASSANDRA-8240:
--
Summary: Attach existing sources to "Referenced libraries" in
Eclipse project
Key: CASSANDRA-8240
URL: https://issues.apache.org/jira/browse/CASSANDRA-8240
Project: Cassandra
Issue Type: Improvement
Reporter: Mikhail Stepura
Assignee: Mikhail Stepura
Priority: Trivial
Fix For: 2.1.2
Attachments: eclipse-sources.patch
At the moment {{ant generate-eclipse-files}} adds all necessary jars to
"Referenced libraries", but doesn't attach sources to those libraries.
I'm attaching a simple patch which does that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8226) Cannot call a column 'timestamp'
[
https://issues.apache.org/jira/browse/CASSANDRA-8226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192451#comment-14192451
]
Mikhail Stepura commented on CASSANDRA-8226:
At the moment cqlsh treats {{timestamp}} as a reserved keyword. We need to
adjust that with http://cassandra.apache.org/doc/cql3/CQL.html#appendixA
> Cannot call a column 'timestamp'
>
>
> Key: CASSANDRA-8226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8226
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native
> protocol v3]
>Reporter: Dave Cunningham
>Assignee: Mikhail Stepura
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.2
>
>
> {code}
> create table test(date text, timestamp timeuuid, stuff text, PRIMARY
> KEY(date, timestamp));
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> select * from test where date = '20141030' order by timestamp limit 1;
> Traceback (most recent call last):
> File "bin/cqlsh", line 861, in onecmd
> self.handle_statement(st, statementtext)
> File "bin/cqlsh", line 901, in handle_statement
> return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
> File "bin/cqlsh", line 910, in handle_parse_error
> return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
> File "bin/cqlsh", line 935, in perform_statement
> result = self.perform_simple_statement(stmt)
> File "bin/cqlsh", line 968, in perform_simple_statement
> self.print_result(rows, self.parse_for_table_meta(statement.query_string))
> File "bin/cqlsh", line 946, in parse_for_table_meta
> parsed = cqlruleset.cql_parse(query_string)[1]
> IndexError: list index out of range
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8226) Cannot call a column 'timestamp'
[
https://issues.apache.org/jira/browse/CASSANDRA-8226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8226:
---
Description:
{code}
create table test(date text, timestamp timeuuid, stuff text, PRIMARY KEY(date,
timestamp));
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
select * from test where date = '20141030' order by timestamp limit 1;
Traceback (most recent call last):
File "bin/cqlsh", line 861, in onecmd
self.handle_statement(st, statementtext)
File "bin/cqlsh", line 901, in handle_statement
return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
File "bin/cqlsh", line 910, in handle_parse_error
return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
File "bin/cqlsh", line 935, in perform_statement
result = self.perform_simple_statement(stmt)
File "bin/cqlsh", line 968, in perform_simple_statement
self.print_result(rows, self.parse_for_table_meta(statement.query_string))
File "bin/cqlsh", line 946, in parse_for_table_meta
parsed = cqlruleset.cql_parse(query_string)[1]
IndexError: list index out of range
{code}
was:
create table test(date text, timestamp timeuuid, stuff text, PRIMARY KEY(date,
timestamp));
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
select * from test where date = '20141030' order by timestamp limit 1;
Traceback (most recent call last):
File "bin/cqlsh", line 861, in onecmd
self.handle_statement(st, statementtext)
File "bin/cqlsh", line 901, in handle_statement
return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
File "bin/cqlsh", line 910, in handle_parse_error
return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
File "bin/cqlsh", line 935, in perform_statement
result = self.perform_simple_statement(stmt)
File "bin/cqlsh", line 968, in perform_simple_statement
self.print_result(rows, self.parse_for_table_meta(statement.query_string))
File "bin/cqlsh", line 946, in parse_for_table_meta
parsed = cqlruleset.cql_parse(query_string)[1]
IndexError: list index out of range
> Cannot call a column 'timestamp'
>
>
> Key: CASSANDRA-8226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8226
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native
> protocol v3]
>Reporter: Dave Cunningham
>Assignee: Mikhail Stepura
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.2
>
>
> {code}
> create table test(date text, timestamp timeuuid, stuff text, PRIMARY
> KEY(date, timestamp));
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
> select * from test where date = '20141030' order by timestamp limit 1;
> Traceback (most recent call last):
> File "bin/cqlsh", line 861, in onecmd
> self.handle_statement(st, statementtext)
> File "bin/cqlsh", line 901, in handle_statement
> return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
> File "bin/cqlsh", line 910, in handle_parse_error
> return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
> File "bin/cqlsh", line 935, in perform_statement
> result = self.perform_simple_statement(stmt)
> File "bin/cqlsh", line 968, in perform_simple_statement
> self.print_result(rows, self.parse_for_table_meta(statement.query_string))
> File "bin/cqlsh", line 946, in parse_for_table_meta
> parsed = cqlruleset.cql_parse(query_string)[1]
> IndexError: list index out of range
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8222) Unable to connect to "any" server with cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192271#comment-14192271
]
Mikhail Stepura commented on CASSANDRA-8222:
[~nad2000] What is the output of {noformat}python -c "import json; print
dir(json); print json.__version__"{noformat} in your system?
> Unable to connect to "any" server with cqlsh
>
>
> Key: CASSANDRA-8222
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8222
> Project: Cassandra
> Issue Type: Bug
> Environment: java -version
> java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
> python --version
> Python 2.7.8
>Reporter: RADOMIRS CIRSKIS
> Labels: cqlsh
>
> I was going through the http://wiki.apache.org/cassandra/GettingStarted
> 1. Installed cassandra
> 2. run cassandra: bin/cassandra -f
> 3. in another terminal attempt to run cqlsh: cqlsh
> 4. also I have tried explicitly: cqlsh 127.0.0.1 9042
> 5. it produces a message:
> {noformat}
> Connection error: ('Unable to connect to any servers', {'127.0.0.1':
> AttributeError("'module' object has no attribute 'loads'",)})
> {noformat}
> Cassandra is running and listening on the port 9042:
> {noformat}
> ...
> INFO 03:36:08 Using Netty Version:
> [netty-buffer=netty-buffer-4.0.23.Final.208198c,
> netty-codec=netty-codec-4.0.23.Final.208198c,
> netty-codec-http=netty-codec-http-4.0.23.Final.208198c,
> netty-codec-socks=netty-codec-socks-4.0.23.Final.208198c,
> netty-common=netty-common-4.0.23.Final.208198c,
> netty-handler=netty-handler-4.0.23.Final.208198c,
> netty-transport=netty-transport-4.0.23.Final.208198c,
> netty-transport-rxtx=netty-transport-rxtx-4.0.23.Final.208198c,
> netty-transport-sctp=netty-transport-sctp-4.0.23.Final.208198c,
> netty-transport-udt=netty-transport-udt-4.0.23.Final.208198c]
> INFO 03:36:08 Starting listening for CQL clients on
> localhost/127.0.0.1:9042...
> INFO 03:36:09 Binding thrift service to localhost/127.0.0.1:9160
> INFO 03:36:09 Listening for thrift clients...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7873) Replace AbstractRowResolver.replies with collection with tailored properties
[
https://issues.apache.org/jira/browse/CASSANDRA-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191001#comment-14191001
]
Mikhail Stepura commented on CASSANDRA-7873:
I do confirm that bisect points to this ticket
{code}
✔ ~/Documents/workspace/cassandra [:691d530|…3⚑ 3]
16:02 $ git bisect good
b867050270408ed6cc77c03d78d75cce9799e38e is the first bad commit
commit b867050270408ed6cc77c03d78d75cce9799e38e
Author: Benedict Elliott Smith
Date: Tue Sep 9 09:47:17 2014 +0700
Introduce new append-only concurrent collection, Accumulator, and use for
AbstractRowResolver.replies
patch by benedict; reviewed by mishail for CASSANDRA-7873
:04 04 11bf5b20a94cdf411e43df48801bfda507838d20
e705ba84008f188be5b462721367811c19465b7f M src
{code}
> Replace AbstractRowResolver.replies with collection with tailored properties
>
>
> Key: CASSANDRA-7873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7873
> Project: Cassandra
> Issue Type: Bug
> Environment: OSX and Ubuntu 14.04
>Reporter: Philip Thompson
>Assignee: Benedict
> Labels: qa-resolved
> Fix For: 3.0
>
> Attachments: 7873.21.txt, 7873.trunk.txt, 7873.txt
>
>
> The dtest auth_test.py:TestAuth.system_auth_ks_is_alterable_test is failing
> on trunk only with the following stack trace:
> {code}
> Unexpected error in node1 node log:
> ERROR [Thrift:1] 2014-09-03 15:48:08,389 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.util.ConcurrentModificationException: null
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
> ~[na:1.7.0_65]
> at java.util.ArrayList$Itr.next(ArrayList.java:831) ~[na:1.7.0_65]
> at
> org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:71)
> ~[main/:na]
> at
> org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:28)
> ~[main/:na]
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:144)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1228)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1154)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:256)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
> ~[main/:na]
> at org.apache.cassandra.auth.Auth.selectUser(Auth.java:257) ~[main/:na]
> at org.apache.cassandra.auth.Auth.isExistingUser(Auth.java:76)
> ~[main/:na]
> at org.apache.cassandra.service.ClientState.login(ClientState.java:178)
> ~[main/:na]
> at
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1486)
> ~[main/:na]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3579)
> ~[thrift/:na]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3563)
> ~[thrift/:na]
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:201)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
> {code}
> That exception is thrown when the following query is sent:
> {code}
> """SELECT strategy_options
> FROM system.schema_keyspaces
> WHERE keyspace_name = 'system_auth'"""
> {code}
> The test alters the RF of the system_auth keyspace, then shuts down and
> restarts the cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7873) Replace AbstractRowResolver.replies with collection with tailored properties
[
https://issues.apache.org/jira/browse/CASSANDRA-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189477#comment-14189477
]
Mikhail Stepura commented on CASSANDRA-7873:
{code}
[14:18:31] Three of the consistency_test.py dtests are
failing very consistently on trunk with client timeouts. I can increase the
timeout, but is this worth looking into as a possible bug?
[14:20:02] yeah, try raising the timeout and see if that resolves
it
[14:20:06] if not, might be a bug
[14:20:21] a bisect might be useful, too
[14:20:35] It does resolve it, but its suspicious that its
happening just on trunk and is consistent across multiple machines
[14:20:44] I would bisect, then
[14:20:51] Cool, will do
[15:50:35] Bisecting the consistency_test failure on trunk
leads me to #7873. mstepura_ is it likely that caused performance issues?
{code}
> Replace AbstractRowResolver.replies with collection with tailored properties
>
>
> Key: CASSANDRA-7873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7873
> Project: Cassandra
> Issue Type: Bug
> Environment: OSX and Ubuntu 14.04
>Reporter: Philip Thompson
>Assignee: Benedict
> Labels: qa-resolved
> Fix For: 3.0
>
> Attachments: 7873.21.txt, 7873.trunk.txt, 7873.txt
>
>
> The dtest auth_test.py:TestAuth.system_auth_ks_is_alterable_test is failing
> on trunk only with the following stack trace:
> {code}
> Unexpected error in node1 node log:
> ERROR [Thrift:1] 2014-09-03 15:48:08,389 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.util.ConcurrentModificationException: null
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
> ~[na:1.7.0_65]
> at java.util.ArrayList$Itr.next(ArrayList.java:831) ~[na:1.7.0_65]
> at
> org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:71)
> ~[main/:na]
> at
> org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:28)
> ~[main/:na]
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:144)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1228)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1154)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:256)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
> ~[main/:na]
> at org.apache.cassandra.auth.Auth.selectUser(Auth.java:257) ~[main/:na]
> at org.apache.cassandra.auth.Auth.isExistingUser(Auth.java:76)
> ~[main/:na]
> at org.apache.cassandra.service.ClientState.login(ClientState.java:178)
> ~[main/:na]
> at
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1486)
> ~[main/:na]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3579)
> ~[thrift/:na]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3563)
> ~[thrift/:na]
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:201)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
> {code}
> That exception is thrown when the following query is sent:
> {code}
> """SELECT strategy_options
> FROM system.schema_keyspaces
> WHERE keyspace_name = 'system_auth'"""
> {code}
> The test alters the RF of the system_auth keyspace, then shuts down and
> restarts the cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8155) confusing error when erroneously querying map secondary index
[
https://issues.apache.org/jira/browse/CASSANDRA-8155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8155:
---
Labels: cqlsh lhf (was: )
> confusing error when erroneously querying map secondary index
> -
>
> Key: CASSANDRA-8155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8155
> Project: Cassandra
> Issue Type: Bug
>Reporter: Russ Hatch
>Priority: Minor
> Labels: cqlsh, lhf
>
> With a secondary index on values, attempting to query by key returns an error
> message of "list index out of range".
> This is kinda a similar issue to CASSANDRA-8147 (but that scenario results in
> no error when there probably should be one).
> To repro:
> {noformat}
> cqlsh:test> CREATE TABLE test.foo (
> ... id1 text,
> ... id2 text,
> ... categories map,
> ... PRIMARY KEY (id1, id2));
> cqlsh:test> CREATE INDEX foo_categories_idx ON test.foo (categories);
> cqlsh:test> insert into foo (id1, id2, categories) values ('foo', 'bar',
> {'firstkey':'one', 'secondkey':'two'});
> {noformat}
> Now try to query the existing values index by key:
> {noformat}
> cqlsh:test> select * from foo where categories contains key 'firstkey';
> list index out of range
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8155) confusing error when erroneously querying map secondary index
[
https://issues.apache.org/jira/browse/CASSANDRA-8155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177835#comment-14177835
]
Mikhail Stepura commented on CASSANDRA-8155:
I believe it cqlsh only issue, where cqlsh fails to properly parse a statement.
> confusing error when erroneously querying map secondary index
> -
>
> Key: CASSANDRA-8155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8155
> Project: Cassandra
> Issue Type: Bug
>Reporter: Russ Hatch
>Priority: Minor
>
> With a secondary index on values, attempting to query by key returns an error
> message of "list index out of range".
> This is kinda a similar issue to CASSANDRA-8147 (but that scenario results in
> no error when there probably should be one).
> To repro:
> {noformat}
> cqlsh:test> CREATE TABLE test.foo (
> ... id1 text,
> ... id2 text,
> ... categories map,
> ... PRIMARY KEY (id1, id2));
> cqlsh:test> CREATE INDEX foo_categories_idx ON test.foo (categories);
> cqlsh:test> insert into foo (id1, id2, categories) values ('foo', 'bar',
> {'firstkey':'one', 'secondkey':'two'});
> {noformat}
> Now try to query the existing values index by key:
> {noformat}
> cqlsh:test> select * from foo where categories contains key 'firstkey';
> list index out of range
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8021) Improve cqlsh autocomplete for alter keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169578#comment-14169578
]
Mikhail Stepura commented on CASSANDRA-8021:
[~rnamboodiri] go ahead and create a patch for 2.0.x. There is no need for a
separate patch for the trunk
> Improve cqlsh autocomplete for alter keyspace
> -
>
> Key: CASSANDRA-8021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8021
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Philip Thompson
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: cqlsh, lhf
> Fix For: 2.0.11, 2.1.1
>
> Attachments: cassandra-2.1.1-8021.txt
>
>
> Cqlsh autocomplete stops giving suggestions for the statement
> {code}ALTER KEYSPACE k WITH REPLICATION { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1'};{code} after the word "WITH".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8021) Improve cqlsh autocomplete for alter keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8021:
---
Reviewer: Mikhail Stepura (was: Tyler Hobbs)
> Improve cqlsh autocomplete for alter keyspace
> -
>
> Key: CASSANDRA-8021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8021
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Philip Thompson
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: cqlsh, lhf
> Fix For: 2.0.11, 2.1.1
>
> Attachments: cassandra-2.1-8021.txt
>
>
> Cqlsh autocomplete stops giving suggestions for the statement
> {code}ALTER KEYSPACE k WITH REPLICATION { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1'};{code} after the word "WITH".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8021) Improve cqlsh autocomplete for alter keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164161#comment-14164161
]
Mikhail Stepura commented on CASSANDRA-8021:
I believe we don't need a new completer there. Adding a {{wat}} to
{{alterKeyspaceStatement}} should be enough
> Improve cqlsh autocomplete for alter keyspace
> -
>
> Key: CASSANDRA-8021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8021
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Philip Thompson
>Assignee: Rajanarayanan Thottuvaikkatumana
>Priority: Minor
> Labels: cqlsh, lhf
> Fix For: 2.0.11, 2.1.1
>
> Attachments: cassandra-2.1-8021.txt
>
>
> Cqlsh autocomplete stops giving suggestions for the statement
> {code}ALTER KEYSPACE k WITH REPLICATION { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1'};{code} after the word "WITH".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8062) IllegalArgumentException passing blob as tuple value element in list
[
https://issues.apache.org/jira/browse/CASSANDRA-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8062:
---
Description:
I am using the same table schema as described in earlier reports, e.g.,
CASSANDRA-7105:
{code}
CREATE TABLE sr (siteid uuid, listid bigint, partition int, createdate
timestamp, emailcrypt blob, emailaddr text, properties text, removedate
timestamp. removeimportid bigint,
PRIMARY KEY ((siteid, listid, partition), createdate, emailcrypt)
) WITH CLUSTERING ORDER BY (createdate DESC, emailcrypt DESC);
{code}
I am trying to take advantage of the new Tuple support to issue a query to
request multiple rows in a single wide row by (createdate,emailcrypt) pair. I
declare a new TupleType that covers the clustering columns and then issue an IN
predicate against a list of these values:
{code}
private static final TupleType dateEmailTupleType =
TupleType.of(DataType.timestamp(), DataType.blob());
...
List partitionKeys = new ArrayList<>(recipKeys.size());
...
BoundStatement boundStatement = new BoundStatement(preparedStatement);
boundStatement = boundStatement.bind(siteID, partition, listID);
boundStatement.setList(3, partitionKeys);
{code}
When I issue a SELECT against this table, the server fails apparently trying to
break apart the list values:
{code}
DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:15,312 Message.java:420 -
Received: PREPARE SELECT emailCrypt, emailAddr, removeDate, removeImportID,
properties FROM sr WHERE siteID = ? AND partition = ? AND listID = ? AND (
createDate, emailCrypt ) IN ? ;, v=2
DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:15,323 Tracing.java:157 - request
complete
DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:15,323 Message.java:433 -
Responding: RESULT PREPARED a18ff9151e8bd3b13b48a0ba56ecb784
[siteid(testdb_1412536748414, sr),
org.apache.cassandra.db.marshal.UUIDType][partition(testdb_1412536748414, sr),
org.apache.cassandra.db.marshal.Int32Type][listid(testdb_1412536748414, sr),
org.apache.cassandra.db.marshal.LongType][in(createdate,emailcrypt)(testdb_1412536748414,
sr),
org.apache.cassandra.db.marshal.ListType(org.apache.cassandra.db.marshal.TupleType(org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.TimestampType),org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.BytesType)))]
(resultMetadata=[emailcrypt(testdb_1412536748414, sr),
org.apache.cassandra.db.marshal.ReversedType(org.apache.cassandra.db.marshal.BytesType)][emailaddr(testdb_1412536748414,
sr),
org.apache.cassandra.db.marshal.UTF8Type][removedate(testdb_1412536748414, sr),
org.apache.cassandra.db.marshal.TimestampType][removeimportid(testdb_1412536748414,
sr),
org.apache.cassandra.db.marshal.LongType][properties(testdb_1412536748414, sr),
org.apache.cassandra.db.marshal.UTF8Type]), v=2
DEBUG [SharedPool-Worker-1] 2014-10-05 14:20:15,363 Message.java:420 -
Received: EXECUTE a18ff9151e8bd3b13b48a0ba56ecb784 with 4 values at consistency
QUORUM, v=2
DEBUG [SharedPool-Worker-2] 2014-10-05 14:20:15,380 Message.java:420 -
Received: EXECUTE a18ff9151e8bd3b13b48a0ba56ecb784 with 4 values at consistency
QUORUM, v=2
DEBUG [SharedPool-Worker-5] 2014-10-05 14:20:15,402 Message.java:420 -
Received: EXECUTE a18ff9151e8bd3b13b48a0ba56ecb784 with 4 values at consistency
QUORUM, v=2
ERROR [SharedPool-Worker-5] 2014-10-05 14:20:16,125 ErrorMessage.java:218 -
Unexpected exception during request
java.lang.IllegalArgumentException: null
at java.nio.Buffer.limit(Unknown Source) ~[na:1.7.0_25]
at
org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:539)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.serializers.CollectionSerializer.readValue(CollectionSerializer.java:122)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.serializers.ListSerializer.deserializeForNativeProtocol(ListSerializer.java:87)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.serializers.ListSerializer.deserializeForNativeProtocol(ListSerializer.java:27)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.serializers.CollectionSerializer.deserialize(CollectionSerializer.java:48)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:66)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.cql3.Tuples$InValue.fromSerialized(Tuples.java:249)
~[apache-cassandra-2.1.0.jar:2.1.0]
at org.apache.cassandra.cql3.Tuples$InMarker.bind(Tuples.java:394)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.cql3.statements.MultiColumnRestriction$InWithMarker.splitValues(MultiColumnRestriction.java:103)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.cql3.statements.SelectStatement.buildMulti
[jira] [Resolved] (CASSANDRA-8030) cqlsh error when selecting data from a table with nested UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura resolved CASSANDRA-8030.
Resolution: Invalid
https://datastax-oss.atlassian.net/browse/PYTHON-167 to track
> cqlsh error when selecting data from a table with nested UDTs
> -
>
> Key: CASSANDRA-8030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8030
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 14.04. Cassandra 2.1.0. Single node.
>Reporter: Cory Snyder
> Labels: cqlsh
> Attachments: example_statements.txt, schema.txt
>
>
> The schema that was being used when this error was produced is attached.
> Whenever I try to select data from the LOAD_BALANCER_SERVICE table after
> having written data with non-empty sets for either the pools or
> virtual_servers fields, cqlsh fails with the following exception:
> {code}
> Traceback (most recent call last):
> File "/usr/bin/cqlsh", line 909, in perform_simple_statement
> rows = self.session.execute(statement, trace=self.tracing_enabled)
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/cluster.py",
> line 1281, in execute
> result = future.result(timeout)
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/cluster.py",
> line 2772, in result
> raise self._final_exception
> TypeError: unhashable type: 'set'
> {code}
> I am, however, able to select the data from the table with the Java Datastax
> driver. I am also able to select data from the table if both the pools and
> virtual_servers fields are empty sets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7458) functional indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154258#comment-14154258
]
Mikhail Stepura commented on CASSANDRA-7458:
A couple of questions about the scope of this ticket:
# Do we want to support functions with arbitrary number of arguments
{{f(x1,x2,...,column,...,xn)}} or just simple single argument functions
{{f(column)}}?
# Do we want to allow more than 1 index per a column?
> functional indexes
> --
>
> Key: CASSANDRA-7458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7458
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
>Reporter: Jonathan Ellis
>Assignee: Mikhail Stepura
> Fix For: 3.0
>
>
> Indexing information derived from the row can be powerful. For example,
> using the hypothetical {{extract_date}} function,
> {code}
> create table ticks (
> symbol text,
> ticked_at datetime,
> price int,
> tags set,
> PRIMARY KEY (symbol, ticked_at)
> );
> CREATE INDEX ticks_by_day ON ticks(extract_date(ticked_at));
> {code}
> http://www.postgresql.org/docs/9.3/static/indexes-expressional.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8030) cqlsh error when selecting data from a table with nested UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154136#comment-14154136
]
Mikhail Stepura commented on CASSANDRA-8030:
Could not reproduce on latest 2.1.0 on OS X.
[~cfsnyder] can you please check what is the output of {{python -c "from blist
import sortedset"}} on your system?
> cqlsh error when selecting data from a table with nested UDTs
> -
>
> Key: CASSANDRA-8030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8030
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 14.04. Cassandra 2.1.0. Single node.
>Reporter: Cory Snyder
> Labels: cqlsh
> Attachments: example_statements.txt, schema.txt
>
>
> The schema that was being used when this error was produced is attached.
> Whenever I try to select data from the LOAD_BALANCER_SERVICE table after
> having written data with non-empty sets for either the pools or
> virtual_servers fields, cqlsh fails with the following exception:
> {code}
> Traceback (most recent call last):
> File "/usr/bin/cqlsh", line 909, in perform_simple_statement
> rows = self.session.execute(statement, trace=self.tracing_enabled)
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/cluster.py",
> line 1281, in execute
> result = future.result(timeout)
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/cluster.py",
> line 2772, in result
> raise self._final_exception
> TypeError: unhashable type: 'set'
> {code}
> I am, however, able to select the data from the table with the Java Datastax
> driver. I am also able to select data from the table if both the pools and
> virtual_servers fields are empty sets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8029) BufferUnderflowException when writing a null value to a UDT field
[
https://issues.apache.org/jira/browse/CASSANDRA-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-8029:
---
Description:
This error was produced with the following schema:
{code}
CREATE TYPE LB_POOL_HEALTH_CHECK (
mode text,
uri text,
health_threshold text,
unhealth_threshold text,
interval text,
timeout text
);
CREATE TYPE LB_POOL_SERVICE_PORT (
enabled boolean,
protocol text,
algorithm text,
port text,
health_check_port text,
health_checks set>
);
CREATE TYPE LB_POOL_MEMBER (
ip_address text,
weight text,
service_ports set>
);
CREATE TYPE LB_PERSISTENCE_TYPE (
method text,
cookie_name text,
cookie_mode text
);
CREATE TYPE LB_VIRTUAL_SERVER_SERVICE_PROFILE (
enabled boolean,
protocol text,
port text,
persistence frozen
);
CREATE TYPE LOAD_BALANCER_POOL (
id text,
name text,
description text,
service_ports set>,
members set>,
operational boolean,
error_details text
);
CREATE TYPE LOAD_BALANCER_VIRTUAL_SERVER (
name text,
enabled boolean,
description text,
ip_address text,
service_profiles set>,
logging boolean,
pool text,
network text
);
CREATE TABLE LOAD_BALANCER_SERVICE (
edge_uuid text,
enabled boolean,
pools set>,
virtual_servers set>,
PRIMARY KEY (edge_uuid)
);
{code}
Whenever I write a null value to any of the id, name, or description fields for
a LOAD_BALANCER_POOL udt in the pools set of the LOAD_BALANCER_SERVICE table or
to the name, enabled, description, or ip_addresses fields of the
LOAD_BALANCER_VIRTUAL_SERVER table in the virtual_servers set of the
LOAD_BALANCER_SERVICE table, I get the following error from cqlsh:
{code}
{code}
When doing the same from the Java Datastax driver, this seems to succeed on the
first write but fail with a timeout exception on all subsequent writes until
either the table is truncated or both the pools and virtual_servers collections
are both written as empty sets.
Having null values in other UDT fields in the hierarchy doesn't seem to cause
any issues.
When I restart Cassandra after having these errors, Cassandra fails to start
and throws the following error when trying to replay the commit logs:
{code}
ERROR [main] 2014-09-30 13:43:04,183 CassandraDaemon.java:474 - Exception
encountered during startup
java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.nio.BufferUnderflowException
at
org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:411)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:400)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:426)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:95)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:137)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:117)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:296)
[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
[apache-cassandra-2.1.0.jar:2.1.0]
Caused by: java.util.concurrent.ExecutionException:
java.nio.BufferUnderflowException
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.get(AbstractTracingAwareExecutorService.java:198)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:407)
~[apache-cassandra-2.1.0.jar:2.1.0]
... 8 common frames omitted
Caused by: java.nio.BufferUnderflowException: null
at java.nio.Buffer.nextGetIndex(Buffer.java:506) ~[na:1.8.0_20]
at java.nio.HeapByteBuffer.getInt(HeapByteBuffer.java:361)
~[na:1.8.0_20]
at
org.apache.cassandra.serializers.CollectionSerializer.readCollectionSize(CollectionSerializer.java:85)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.db.marshal.ListType.compareListOrSet(ListType.java:96)
~[apache-cassandra-2.1.0.jar:2.1.0]
at org.apache.cassandra.db.marshal.SetType.compare(SetType.java:77)
~[apache-cassandra-2.1.0.jar:2.1.0]
at org.apache.cassandra.db.marshal.SetType.compare(SetType.java:29)
~[apache-cass
[jira] [Updated] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[ https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-8022: --- Reproduced In: (was: 2.1.0) > cqlsh hangs indefinitely within a Docker container connecting to itself with > hostname > - > > Key: CASSANDRA-8022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8022 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 > container. >Reporter: Matthew O'Riordan > Labels: cqlsh > > I am unable to use the `cqlsh` tool within a Docker container running > Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as > follows: > ``` > cqlsh --username cassandra --password whatever $(hostname) > ``` > When I run the `cqlsh` command after attaching to a running container (I use > LXC containerisation that allows attaching to a running container and running > a console), it simply hangs and never reports an error. With the `--debug` > flag on, I get the following with: > **cqlsh 4.1.1** > ``` > $ cqlsh --debug --username cassandra --password obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'> > Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'> > ``` > It then hangs in this state indefinitely, I have no errors from `cqlsh` and > no errors in the Cassandra log. > **cqlsh 5.0.1** > ``` > $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'> > ``` > It then also hangs in this state indefinitely, I have no errors from `cqlsh` > and no errors in the Cassandra log. > What's interesting, and quite confusing is that: > * I can telnet within the container as follows `telnet $(hostname) 9042` and > I get a socket. When trying to issue some commands, I see Protocol errors in > the Cassandra log thus verifying that the port is indeed open on the host > that resolves from $(hostname) > * If I `cqlsh` from another container or another host to the Cassandra > container it works just fine. > * I have tried disabling authentication altogether and using the > AllowAllAuthenticator, and I experience the same problem. > * `nodetool` works fine > In the mean time, I am forced to `cqlsh` from another container as a > workaround. Happy to try and do anything require to diagnose the cause of > this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[ https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-8022: --- Fix Version/s: (was: 2.1.1) > cqlsh hangs indefinitely within a Docker container connecting to itself with > hostname > - > > Key: CASSANDRA-8022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8022 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 > container. >Reporter: Matthew O'Riordan > Labels: cqlsh > > I am unable to use the `cqlsh` tool within a Docker container running > Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as > follows: > ``` > cqlsh --username cassandra --password whatever $(hostname) > ``` > When I run the `cqlsh` command after attaching to a running container (I use > LXC containerisation that allows attaching to a running container and running > a console), it simply hangs and never reports an error. With the `--debug` > flag on, I get the following with: > **cqlsh 4.1.1** > ``` > $ cqlsh --debug --username cassandra --password obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'> > Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'> > ``` > It then hangs in this state indefinitely, I have no errors from `cqlsh` and > no errors in the Cassandra log. > **cqlsh 5.0.1** > ``` > $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'> > ``` > It then also hangs in this state indefinitely, I have no errors from `cqlsh` > and no errors in the Cassandra log. > What's interesting, and quite confusing is that: > * I can telnet within the container as follows `telnet $(hostname) 9042` and > I get a socket. When trying to issue some commands, I see Protocol errors in > the Cassandra log thus verifying that the port is indeed open on the host > that resolves from $(hostname) > * If I `cqlsh` from another container or another host to the Cassandra > container it works just fine. > * I have tried disabling authentication altogether and using the > AllowAllAuthenticator, and I experience the same problem. > * `nodetool` works fine > In the mean time, I am forced to `cqlsh` from another container as a > workaround. Happy to try and do anything require to diagnose the cause of > this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[
https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152514#comment-14152514
]
Mikhail Stepura commented on CASSANDRA-8022:
Can you enter commands into that "hung" cqlsh?
Can you also check the output for {{ lsof -a -p -d0,1,2}} ?
> cqlsh hangs indefinitely within a Docker container connecting to itself with
> hostname
> -
>
> Key: CASSANDRA-8022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04
> container.
>Reporter: Matthew O'Riordan
> Fix For: 2.1.0
>
>
> I am unable to use the `cqlsh` tool within a Docker container running
> Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as
> follows:
> ```
> cqlsh --username cassandra --password whatever $(hostname)
> ```
> When I run the `cqlsh` command after attaching to a running container (I use
> LXC containerisation that allows attaching to a running container and running
> a console), it simply hangs and never reports an error. With the `--debug`
> flag on, I get the following with:
> **cqlsh 4.1.1**
> ```
> $ cqlsh --debug --username cassandra --password obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'>
> Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'>
> ```
> It then hangs in this state indefinitely, I have no errors from `cqlsh` and
> no errors in the Cassandra log.
> **cqlsh 5.0.1**
> ```
> $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'>
> ```
> It then also hangs in this state indefinitely, I have no errors from `cqlsh`
> and no errors in the Cassandra log.
> What's interesting, and quite confusing is that:
> * I can telnet within the container as follows `telnet $(hostname) 9042` and
> I get a socket. When trying to issue some commands, I see Protocol errors in
> the Cassandra log thus verifying that the port is indeed open on the host
> that resolves from $(hostname)
> * If I `cqlsh` from another container or another host to the Cassandra
> container it works just fine.
> * I have tried disabling authentication altogether and using the
> AllowAllAuthenticator, and I experience the same problem.
> * `nodetool` works fine
> In the mean time, I am forced to `cqlsh` from another container as a
> workaround. Happy to try and do anything require to diagnose the cause of
> this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[
https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152514#comment-14152514
]
Mikhail Stepura edited comment on CASSANDRA-8022 at 9/29/14 11:34 PM:
--
Can you enter commands into that "hung" cqlsh?
Can you also check the output for {{lsof -a -p -d0,1,2}} ?
was (Author: mishail):
Can you enter commands into that "hung" cqlsh?
Can you also check the output for {{ lsof -a -p -d0,1,2}} ?
> cqlsh hangs indefinitely within a Docker container connecting to itself with
> hostname
> -
>
> Key: CASSANDRA-8022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04
> container.
>Reporter: Matthew O'Riordan
> Fix For: 2.1.0
>
>
> I am unable to use the `cqlsh` tool within a Docker container running
> Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as
> follows:
> ```
> cqlsh --username cassandra --password whatever $(hostname)
> ```
> When I run the `cqlsh` command after attaching to a running container (I use
> LXC containerisation that allows attaching to a running container and running
> a console), it simply hangs and never reports an error. With the `--debug`
> flag on, I get the following with:
> **cqlsh 4.1.1**
> ```
> $ cqlsh --debug --username cassandra --password obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'>
> Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'>
> ```
> It then hangs in this state indefinitely, I have no errors from `cqlsh` and
> no errors in the Cassandra log.
> **cqlsh 5.0.1**
> ```
> $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'>
> ```
> It then also hangs in this state indefinitely, I have no errors from `cqlsh`
> and no errors in the Cassandra log.
> What's interesting, and quite confusing is that:
> * I can telnet within the container as follows `telnet $(hostname) 9042` and
> I get a socket. When trying to issue some commands, I see Protocol errors in
> the Cassandra log thus verifying that the port is indeed open on the host
> that resolves from $(hostname)
> * If I `cqlsh` from another container or another host to the Cassandra
> container it works just fine.
> * I have tried disabling authentication altogether and using the
> AllowAllAuthenticator, and I experience the same problem.
> * `nodetool` works fine
> In the mean time, I am forced to `cqlsh` from another container as a
> workaround. Happy to try and do anything require to diagnose the cause of
> this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8001) CQLSH broken in Mac OS 10.9.5
[
https://issues.apache.org/jira/browse/CASSANDRA-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147247#comment-14147247
]
Mikhail Stepura commented on CASSANDRA-8001:
"cql" (https://pypi.python.org/pypi/cql) is a driver used by cqlsh, and cqlsh
bundled with Cassandra doesn't require you to install that driver via pip,
because it uses a bundled version.
> CQLSH broken in Mac OS 10.9.5
> -
>
> Key: CASSANDRA-8001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8001
> Project: Cassandra
> Issue Type: Bug
> Environment: Mac OS 10.9.5, homebrew python 2.7, cql 4.1.1
>Reporter: Jonathan Hoskin
>
> Since upgrading to Mac OS 10.9.5, cqlsh has stopped working.
> Here is the error trace I get:
> {quote}
> $ cqlsh -u USER -k KEYSPACE HOST
> Traceback (most recent call last):
> File "/usr/local/bin/cqlsh", line 2044, in
> main(*read_options(sys.argv[1:], os.environ))
> File "/usr/local/bin/cqlsh", line 2030, in main
> display_float_precision=options.float_precision)
> File "/usr/local/bin/cqlsh", line 480, in __init__
> cql_version=cqlver, transport=transport)
> File "/usr/local/lib/python2.7/site-packages/cql/connection.py", line 143,
> in connect
> consistency_level=consistency_level, transport=transport)
> File "/usr/local/lib/python2.7/site-packages/cql/connection.py", line 59,
> in __init__
> self.establish_connection()
> File "/usr/local/lib/python2.7/site-packages/cql/thrifteries.py", line 157,
> in establish_connection
> self.client.login(AuthenticationRequest(credentials=self.credentials))
> File "/usr/local/lib/python2.7/site-packages/cql/cassandra/Cassandra.py",
> line 454, in login
> self.send_login(auth_request)
> File "/usr/local/lib/python2.7/site-packages/cql/cassandra/Cassandra.py",
> line 461, in send_login
> args.write(self._oprot)
> File "/usr/local/lib/python2.7/site-packages/cql/cassandra/Cassandra.py",
> line 2769, in write
> oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
> self.thrift_spec)))
> TypeError: expected string or Unicode object, NoneType found
> {quote}
> At first I suspected that some system dependency had changed, so I have clean
> reinstalled python, pip and cql. The error persists.
> I have also tested the cqlsh command on another Mac running OS 10.9.2 and it
> can connect fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8001) CQLSH broken in Mac OS 10.9.5
[
https://issues.apache.org/jira/browse/CASSANDRA-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147231#comment-14147231
]
Mikhail Stepura commented on CASSANDRA-8001:
I wonder how did you install/get cqlsh itself?
> CQLSH broken in Mac OS 10.9.5
> -
>
> Key: CASSANDRA-8001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8001
> Project: Cassandra
> Issue Type: Bug
> Environment: Mac OS 10.9.5, homebrew python 2.7, cql 4.1.1
>Reporter: Jonathan Hoskin
>
> Since upgrading to Mac OS 10.9.5, cqlsh has stopped working.
> Here is the error trace I get:
> {quote}
> $ cqlsh -u USER -k KEYSPACE HOST
> Traceback (most recent call last):
> File "/usr/local/bin/cqlsh", line 2044, in
> main(*read_options(sys.argv[1:], os.environ))
> File "/usr/local/bin/cqlsh", line 2030, in main
> display_float_precision=options.float_precision)
> File "/usr/local/bin/cqlsh", line 480, in __init__
> cql_version=cqlver, transport=transport)
> File "/usr/local/lib/python2.7/site-packages/cql/connection.py", line 143,
> in connect
> consistency_level=consistency_level, transport=transport)
> File "/usr/local/lib/python2.7/site-packages/cql/connection.py", line 59,
> in __init__
> self.establish_connection()
> File "/usr/local/lib/python2.7/site-packages/cql/thrifteries.py", line 157,
> in establish_connection
> self.client.login(AuthenticationRequest(credentials=self.credentials))
> File "/usr/local/lib/python2.7/site-packages/cql/cassandra/Cassandra.py",
> line 454, in login
> self.send_login(auth_request)
> File "/usr/local/lib/python2.7/site-packages/cql/cassandra/Cassandra.py",
> line 461, in send_login
> args.write(self._oprot)
> File "/usr/local/lib/python2.7/site-packages/cql/cassandra/Cassandra.py",
> line 2769, in write
> oprot.trans.write(fastbinary.encode_binary(self, (self.__class__,
> self.thrift_spec)))
> TypeError: expected string or Unicode object, NoneType found
> {quote}
> At first I suspected that some system dependency had changed, so I have clean
> reinstalled python, pip and cql. The error persists.
> I have also tested the cqlsh command on another Mac running OS 10.9.2 and it
> can connect fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-7458) functional indexes
[
https://issues.apache.org/jira/browse/CASSANDRA-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura reassigned CASSANDRA-7458:
--
Assignee: Mikhail Stepura
> functional indexes
> --
>
> Key: CASSANDRA-7458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7458
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
>Reporter: Jonathan Ellis
>Assignee: Mikhail Stepura
> Fix For: 3.0
>
>
> Indexing information derived from the row can be powerful. For example,
> using the hypothetical {{extract_date}} function,
> {code}
> create table ticks (
> symbol text,
> ticked_at datetime,
> price int,
> tags set,
> PRIMARY KEY (symbol, ticked_at)
> );
> CREATE INDEX ticks_by_day ON ticks(extract_date(ticked_at));
> {code}
> http://www.postgresql.org/docs/9.3/static/indexes-expressional.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7988) 2.1 broke cqlsh for IPv6
[ https://issues.apache.org/jira/browse/CASSANDRA-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-7988: --- Fix Version/s: 2.1.1 > 2.1 broke cqlsh for IPv6 > - > > Key: CASSANDRA-7988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7988 > Project: Cassandra > Issue Type: New Feature >Reporter: Josh Wright > Fix For: 2.1.1 > > > cqlsh in 2.1 switched to the cassandra-driver Python library, which only > recently added IPv6 support. The version bundled with 2.1.0 does not include > a sufficiently recent version, so cqlsh is unusable for those of us running > IPv6 (us? me...?) > The fix is to simply upgrade the bundled version of the Python > cassandra-driver to at least version 2.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7972) Add "CREATE INDEX ... ON ..(KEYS())" syntax to cqlsh and CQL.textile
[
https://issues.apache.org/jira/browse/CASSANDRA-7972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14141572#comment-14141572
]
Mikhail Stepura commented on CASSANDRA-7972:
[~philipthompson] I believe cqlsh should already support creation of indexes on
collections' values, but please double check.
bq.Could you explain what you meant by adding it to cql.textile
Just ignore that, it looks like {{doc/cql3/CQL.textile}} already contains that
information
> Add "CREATE INDEX ... ON ..(KEYS())" syntax to cqlsh and CQL.textile
>
>
> Key: CASSANDRA-7972
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7972
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tools
>Reporter: Mikhail Stepura
>Assignee: Philip Thompson
>Priority: Minor
> Labels: cqlsh, lhf
> Fix For: 2.1.1
>
> Attachments: 7972-1.txt
>
>
> http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/create_index_r.html?scroll=reference_ds_eqm_nmd_xj__CreatIdxCollKey
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7972) Add "CREATE INDEX ... ON ..(KEYS())" syntax to cqlsh and CQL.textile
[ https://issues.apache.org/jira/browse/CASSANDRA-7972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-7972: --- Description: http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/create_index_r.html?scroll=reference_ds_eqm_nmd_xj__CreatIdxCollKey > Add "CREATE INDEX ... ON ..(KEYS())" syntax to cqlsh and CQL.textile > > > Key: CASSANDRA-7972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7972 > Project: Cassandra > Issue Type: Sub-task > Components: Tools >Reporter: Mikhail Stepura >Priority: Minor > Labels: cqlsh, lhf > Fix For: 2.1.1 > > > http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/create_index_r.html?scroll=reference_ds_eqm_nmd_xj__CreatIdxCollKey -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-7972) Add "CREATE INDEX ... ON ..(KEYS())" syntax to cqlsh and CQL.textile
Mikhail Stepura created CASSANDRA-7972: -- Summary: Add "CREATE INDEX ... ON ..(KEYS())" syntax to cqlsh and CQL.textile Key: CASSANDRA-7972 URL: https://issues.apache.org/jira/browse/CASSANDRA-7972 Project: Cassandra Issue Type: Sub-task Components: Tools Reporter: Mikhail Stepura Priority: Minor Fix For: 2.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7801) A successful INSERT with CAS does not always store data in the DB after a DELETE
[
https://issues.apache.org/jira/browse/CASSANDRA-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-7801:
---
Description:
When I run a loop with CQL statements to DELETE, INSERT with CAS and then a GET.
The INSERT opertion is successful (Applied), but no data is stored in the
database. I have checked the database manually after the test to verify that
the DB is empty.
{code}
for (int i = 0; i < 1; ++i)
{
try
{
t.del();
t.cas();
t.select();
}
catch (Exception e)
{
System.err.println("i=" + i);
e.printStackTrace();
break;
}
}
myCluster =
Cluster.builder().addContactPoint("localhost").withPort(12742).build();
mySession = myCluster.connect();
mySession.execute("CREATE KEYSPACE IF NOT EXISTS castest WITH
REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };");
mySession.execute("CREATE TABLE IF NOT EXISTS castest.users (userid
text PRIMARY KEY, name text)");
myInsert = mySession.prepare("INSERT INTO castest.users (userid, name)
values ('user1', 'calle') IF NOT EXISTS");
myDelete = mySession.prepare("DELETE FROM castest.users where
userid='user1'");
myGet = mySession.prepare("SELECT * FROM castest.users where
userid='user1'");
}
{code}
I can reproduce the fault with the attached program on a PC with windows 7.
You need a cassandra runing and you need to set the port in the program.
was:
When I run a loop with CQL statements to DELETE, INSERT with CAS and then a GET.
The INSERT opertion is successful (Applied), but no data is stored in the
database. I have checked the database manually after the test to verify that
the DB is empty.
for (int i = 0; i < 1; ++i)
{
try
{
t.del();
t.cas();
t.select();
}
catch (Exception e)
{
System.err.println("i=" + i);
e.printStackTrace();
break;
}
}
myCluster =
Cluster.builder().addContactPoint("localhost").withPort(12742).build();
mySession = myCluster.connect();
mySession.execute("CREATE KEYSPACE IF NOT EXISTS castest WITH
REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };");
mySession.execute("CREATE TABLE IF NOT EXISTS castest.users (userid
text PRIMARY KEY, name text)");
myInsert = mySession.prepare("INSERT INTO castest.users (userid, name)
values ('user1', 'calle') IF NOT EXISTS");
myDelete = mySession.prepare("DELETE FROM castest.users where
userid='user1'");
myGet = mySession.prepare("SELECT * FROM castest.users where
userid='user1'");
}
I can reproduce the fault with the attached program on a PC with windows 7.
You need a cassandra runing and you need to set the port in the program.
> A successful INSERT with CAS does not always store data in the DB after a
> DELETE
>
>
> Key: CASSANDRA-7801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7801
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: PC with Windows 7 and on Linux installation.
> Have seen the fault on Cassandra 2.0.9 and Cassandra 2.1.0-rc5
>Reporter: Martin Fransson
>Assignee: Sylvain Lebresne
> Fix For: 2.0.11
>
> Attachments: 7801.txt, cas.zip
>
>
> When I run a loop with CQL statements to DELETE, INSERT with CAS and then a
> GET.
> The INSERT opertion is successful (Applied), but no data is stored in the
> database. I have checked the database manually after the test to verify that
> the DB is empty.
> {code}
> for (int i = 0; i < 1; ++i)
> {
> try
> {
> t.del();
> t.cas();
> t.select();
> }
> catch (Exception e)
> {
> System.err.println("i=" + i);
> e.printStackTrace();
> break;
> }
> }
> myCluster =
> Cluster.builder().addContactPoint("localhost").withPort(12742).build();
> mySession = myCluster.connect();
> mySession.execute("CREATE KEYSPACE IF NOT EXISTS castest WITH
> REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };");
> mySession.execute("CREATE TABLE IF NOT EXISTS castest.users (userid
> text PRIMARY KEY, name text)");
> myInsert = mySession.prepare("INSERT INTO castest.users (userid,
> name) values ('user1', 'calle') IF NOT EXISTS");
>
[jira] [Commented] (CASSANDRA-7944) cqlsh "describe keyspace" omits frozen<> keyword from CQL statements
[ https://issues.apache.org/jira/browse/CASSANDRA-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14135739#comment-14135739 ] Mikhail Stepura commented on CASSANDRA-7944: [~thobbs] it is supposed to be fixed by CASSANDRA-7863. isn't it? > cqlsh "describe keyspace" omits frozen<> keyword from CQL statements > > > Key: CASSANDRA-7944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7944 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jim Bisso >Assignee: Mikhail Stepura >Priority: Minor > Fix For: 2.1.1 > > > 1. create a schema. > 2. create a UDT or tuple > 3. in cqlsh "describe keyspace foo" should list CQL statements with frozen > keyword intact. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7131) Add command line option for cqlshrc file path
[ https://issues.apache.org/jira/browse/CASSANDRA-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-7131: --- Fix Version/s: 2.1.1 > Add command line option for cqlshrc file path > - > > Key: CASSANDRA-7131 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7131 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Jeremiah Jordan >Priority: Trivial > Labels: cqlsh, lhf > Fix For: 2.1.1 > > Attachments: CASSANDRA-2.1.1-7131.txt > > > It would be nice if you could specify the cqlshrc file location on the > command line, so you don't have to jump through hoops when running it from a > service user or something. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7921) Provide visibility into prepared statement churn
[ https://issues.apache.org/jira/browse/CASSANDRA-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-7921: --- Fix Version/s: (was: 2.1.0) > Provide visibility into prepared statement churn > > > Key: CASSANDRA-7921 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7921 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Nate McCall >Assignee: Nate McCall >Priority: Minor > Attachments: 7921-ps-churn.txt > > > Some JDBC drivers provide visibility into the preparedstatement cache in such > a way as to track churn. It would be nice to have this added to > CqlStatementMetrics -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7719) Add PreparedStatements related metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127922#comment-14127922
]
Mikhail Stepura commented on CASSANDRA-7719:
Couple of nits,
* Don't use {{String.format}} in {{logger.trace}}, use parameterized messages.
Like {code}logger.trace("Stored prepared statement {} with {} bind markers",
statementId, prepared.statement.getBoundTerms()){code}
* Replace Java {{assert}} with appropriate methods from {{org.junit.Assert}}.
> Add PreparedStatements related metrics
> --
>
> Key: CASSANDRA-7719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7719
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Michaël Figuière
>Assignee: T Jake Luciani
>Priority: Minor
> Fix For: 2.1.1
>
> Attachments: 7719.txt
>
>
> Cassandra newcomers often don't understand that they're expected to use
> PreparedStatements for almost all of their repetitive queries executed in
> production.
> It doesn't look like Cassandra currently expose any PreparedStatements
> related metrics.It would be interesting, and I believe fairly simple, to add
> several of them to make it possible, in development / management / monitoring
> tools, to show warnings or alerts related to this bad practice.
> Thus I would suggest to add the following metrics:
> * Executed prepared statements count
> * Executed unprepared statements count
> * Amount of PreparedStatements that have been registered on the node
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7828) New node cannot be joined if a value in composite type column is dropped (description updated)
[
https://issues.apache.org/jira/browse/CASSANDRA-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127663#comment-14127663
]
Mikhail Stepura commented on CASSANDRA-7828:
[~peter-librato] Mea culpa. That's because a merge conflict
> New node cannot be joined if a value in composite type column is dropped
> (description updated)
> --
>
> Key: CASSANDRA-7828
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7828
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Igor Zubchenok
>Assignee: Mikhail Stepura
> Fix For: 1.2.19, 2.0.11, 2.1.1
>
> Attachments: 1409959462180-myColumnFamily.zip,
> CASSANDRA-2.0-7828.patch
>
>
> I get a *RuntimeException* at new node system.log on bootstrapping a new DC:
> {code:title=system.out - RuntimeException caused by IllegalArgumentException
> in Buffer.limit|borderStyle=solid}
> INFO [NonPeriodicTasks:1] 2014-08-26 15:43:01,030 SecondaryIndexManager.java
> (line 137) Submitting index build of [myColumnFamily.myColumnFamily_myColumn]
> for data in
> SSTableReader(path='/var/lib/cassandra/data/testbug/myColumnFamily/testbug-myColumnFamily-jb-1-Data.db')
> ERROR [CompactionExecutor:2] 2014-08-26 15:43:01,035 CassandraDaemon.java
> (line 199) Exception in thread Thread[CompactionExecutor:2,1,main]
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:267)
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:587)
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytesWithShortLength(ByteBufferUtil.java:596)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:61)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:36)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:44)
> at org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:85)
> at org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:36)
> at
> java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:727)
> at
> java.util.concurrent.ConcurrentSkipListMap.findNode(ConcurrentSkipListMap.java:789)
> at
> java.util.concurrent.ConcurrentSkipListMap.doGet(ConcurrentSkipListMap.java:828)
> at
> java.util.concurrent.ConcurrentSkipListMap.get(ConcurrentSkipListMap.java:1626)
> at org.apache.cassandra.db.Memtable.resolve(Memtable.java:215)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:173)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:900)
> at
> org.apache.cassandra.db.index.AbstractSimplePerColumnSecondaryIndex.insert(AbstractSimplePerColumnSecondaryIndex.java:107)
> at
> org.apache.cassandra.db.index.SecondaryIndexManager.indexRow(SecondaryIndexManager.java:441)
> at org.apache.cassandra.db.Keyspace.indexRow(Keyspace.java:413)
> at
> org.apache.cassandra.db.index.SecondaryIndexBuilder.build(SecondaryIndexBuilder.java:62)
> at
> org.apache.cassandra.db.compaction.CompactionManager$9.run(CompactionManager.java:834)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> ERROR [NonPeriodicTasks:1] 2014-08-26 15:43:01,035 CassandraDaemon.java (line
> 199) Exception in thread Thread[NonPeriodicTasks:1,5,main]
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.IllegalArgumentException
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:413)
> at
> org.apache.cassandra.db.index.SecondaryIndexManager.maybeBuildSecondaryIndexes(SecondaryIndexManager.java:142)
> at
> org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:113)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExe
[jira] [Commented] (CASSANDRA-7873) java.util.ConcurrentModificationException seen after selecting from system_auth
[
https://issues.apache.org/jira/browse/CASSANDRA-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125988#comment-14125988
]
Mikhail Stepura commented on CASSANDRA-7873:
+1
> java.util.ConcurrentModificationException seen after selecting from
> system_auth
> ---
>
> Key: CASSANDRA-7873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7873
> Project: Cassandra
> Issue Type: Bug
> Environment: OSX and Ubuntu 14.04
>Reporter: Philip Thompson
>Assignee: Benedict
> Fix For: 3.0
>
> Attachments: 7873.21.txt, 7873.trunk.txt, 7873.txt
>
>
> The dtest auth_test.py:TestAuth.system_auth_ks_is_alterable_test is failing
> on trunk only with the following stack trace:
> {code}
> Unexpected error in node1 node log:
> ERROR [Thrift:1] 2014-09-03 15:48:08,389 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> java.util.ConcurrentModificationException: null
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
> ~[na:1.7.0_65]
> at java.util.ArrayList$Itr.next(ArrayList.java:831) ~[na:1.7.0_65]
> at
> org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:71)
> ~[main/:na]
> at
> org.apache.cassandra.service.RowDigestResolver.resolve(RowDigestResolver.java:28)
> ~[main/:na]
> at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:144)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1228)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1154)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:256)
> ~[main/:na]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
> ~[main/:na]
> at org.apache.cassandra.auth.Auth.selectUser(Auth.java:257) ~[main/:na]
> at org.apache.cassandra.auth.Auth.isExistingUser(Auth.java:76)
> ~[main/:na]
> at org.apache.cassandra.service.ClientState.login(ClientState.java:178)
> ~[main/:na]
> at
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1486)
> ~[main/:na]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3579)
> ~[thrift/:na]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3563)
> ~[thrift/:na]
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:201)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
> {code}
> That exception is thrown when the following query is sent:
> {code}
> """SELECT strategy_options
> FROM system.schema_keyspaces
> WHERE keyspace_name = 'system_auth'"""
> {code}
> The test alters the RF of the system_auth keyspace, then shuts down and
> restarts the cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7828) New node cannot be joined if a value in composite type column is dropped (description updated)
[
https://issues.apache.org/jira/browse/CASSANDRA-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125943#comment-14125943
]
Mikhail Stepura commented on CASSANDRA-7828:
[~iamaleksey] should we merge it into 2.1.0 as well?
> New node cannot be joined if a value in composite type column is dropped
> (description updated)
> --
>
> Key: CASSANDRA-7828
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7828
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Igor Zubchenok
>Assignee: Mikhail Stepura
> Fix For: 2.0.11
>
> Attachments: 1409959462180-myColumnFamily.zip,
> CASSANDRA-2.0-7828.patch
>
>
> I get a *RuntimeException* at new node system.log on bootstrapping a new DC:
> {code:title=system.out - RuntimeException caused by IllegalArgumentException
> in Buffer.limit|borderStyle=solid}
> INFO [NonPeriodicTasks:1] 2014-08-26 15:43:01,030 SecondaryIndexManager.java
> (line 137) Submitting index build of [myColumnFamily.myColumnFamily_myColumn]
> for data in
> SSTableReader(path='/var/lib/cassandra/data/testbug/myColumnFamily/testbug-myColumnFamily-jb-1-Data.db')
> ERROR [CompactionExecutor:2] 2014-08-26 15:43:01,035 CassandraDaemon.java
> (line 199) Exception in thread Thread[CompactionExecutor:2,1,main]
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:267)
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:587)
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytesWithShortLength(ByteBufferUtil.java:596)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:61)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:36)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:44)
> at org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:85)
> at org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:36)
> at
> java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:727)
> at
> java.util.concurrent.ConcurrentSkipListMap.findNode(ConcurrentSkipListMap.java:789)
> at
> java.util.concurrent.ConcurrentSkipListMap.doGet(ConcurrentSkipListMap.java:828)
> at
> java.util.concurrent.ConcurrentSkipListMap.get(ConcurrentSkipListMap.java:1626)
> at org.apache.cassandra.db.Memtable.resolve(Memtable.java:215)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:173)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:900)
> at
> org.apache.cassandra.db.index.AbstractSimplePerColumnSecondaryIndex.insert(AbstractSimplePerColumnSecondaryIndex.java:107)
> at
> org.apache.cassandra.db.index.SecondaryIndexManager.indexRow(SecondaryIndexManager.java:441)
> at org.apache.cassandra.db.Keyspace.indexRow(Keyspace.java:413)
> at
> org.apache.cassandra.db.index.SecondaryIndexBuilder.build(SecondaryIndexBuilder.java:62)
> at
> org.apache.cassandra.db.compaction.CompactionManager$9.run(CompactionManager.java:834)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> ERROR [NonPeriodicTasks:1] 2014-08-26 15:43:01,035 CassandraDaemon.java (line
> 199) Exception in thread Thread[NonPeriodicTasks:1,5,main]
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.IllegalArgumentException
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:413)
> at
> org.apache.cassandra.db.index.SecondaryIndexManager.maybeBuildSecondaryIndexes(SecondaryIndexManager.java:142)
> at
> org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:113)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
[jira] [Commented] (CASSANDRA-7895) ALTER TYPE RENAME TO no longer parses as valid cql
[
https://issues.apache.org/jira/browse/CASSANDRA-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14124747#comment-14124747
]
Mikhail Stepura commented on CASSANDRA-7895:
Committed, thanks
> ALTER TYPE RENAME TO no longer parses as valid cql
>
>
> Key: CASSANDRA-7895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7895
> Project: Cassandra
> Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Mikhail Stepura
>Priority: Minor
> Fix For: 2.1.0, 2.1.1
>
> Attachments: CASSANDRA-2.1.0-7895.patch
>
>
> Type renaming seems to be broken. The error looks like perhaps the syntax has
> changed or there's a problem parsing the cql.
> {noformat}
> cqlsh:test> create type foo (somefield int);
> cqlsh:test> alter type foo rename to bar;
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7895) ALTER TYPE RENAME TO no longer parses as valid cql
[
https://issues.apache.org/jira/browse/CASSANDRA-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-7895:
---
Attachment: CASSANDRA-2.1.0-7895.patch
I'm attaching a patch to adjust cqlsh tab-completion
> ALTER TYPE RENAME TO no longer parses as valid cql
>
>
> Key: CASSANDRA-7895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7895
> Project: Cassandra
> Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Mikhail Stepura
>Priority: Minor
> Fix For: 2.1.0
>
> Attachments: CASSANDRA-2.1.0-7895.patch
>
>
> Type renaming seems to be broken. The error looks like perhaps the syntax has
> changed or there's a problem parsing the cql.
> {noformat}
> cqlsh:test> create type foo (somefield int);
> cqlsh:test> alter type foo rename to bar;
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
