[jira] [Comment Edited] (CASSANDRA-12672) Automate Nodetool Documentation

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15554227#comment-15554227
 ] 

mck edited comment on CASSANDRA-12672 at 10/7/16 5:55 AM:
--

Committed 
https://git1-us-west.apache.org/repos/asf?p=cassandra.git;a=commit;h=b9191871c32d3ab06030548c9fa63e0cab43c6c7
  (added entry to CHANGES.txt)


was (Author: michaelsembwever):
Committed 
https://git1-us-west.apache.org/repos/asf?p=cassandra.git;a=commit;h=b9191871c32d3ab06030548c9fa63e0cab43c6c7

> Automate Nodetool Documentation
> ---
>
> Key: CASSANDRA-12672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12672
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Andrew Baker
>Assignee: mck
>Priority: Minor
>  Labels: documentaion, lhf, nodetool
> Fix For: 4.0
>
>
> nodetool.rst has this:
> todo:: Try to autogenerate this from Nodetool’s help.
> creating a ticket to submit this work against



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12672) Automate Nodetool Documentation

[mck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mck updated CASSANDRA-12672:

Resolution: Fixed
  Assignee: mck
  Reviewer: Jon Haddad  (was: mck)
Status: Resolved  (was: Ready to Commit)

Committed 
https://git1-us-west.apache.org/repos/asf?p=cassandra.git;a=commit;h=b9191871c32d3ab06030548c9fa63e0cab43c6c7

> Automate Nodetool Documentation
> ---
>
> Key: CASSANDRA-12672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12672
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Andrew Baker
>Assignee: mck
>Priority: Minor
>  Labels: documentaion, lhf, nodetool
> Fix For: 4.0
>
>
> nodetool.rst has this:
> todo:: Try to autogenerate this from Nodetool’s help.
> creating a ticket to submit this work against



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cassandra git commit: Automate Nodetool Documentation

[mck]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 324bd7187 -> b9191871c


Automate Nodetool Documentation

patch by Andrew Baker ; reviewed by Jon Haddad for CASSANDRA-12672


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b9191871
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b9191871
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b9191871

Branch: refs/heads/trunk
Commit: b9191871c32d3ab06030548c9fa63e0cab43c6c7
Parents: 324bd71
Author: mck 
Authored: Fri Oct 7 16:43:25 2016 +1100
Committer: mck 
Committed: Fri Oct 7 16:52:18 2016 +1100

--
 .gitignore|  1 +
 CHANGES.txt   |  1 +
 doc/Makefile  | 28 
 doc/gen-nodetool-docs.py  | 69 ++
 doc/source/tools/index.rst|  2 +-
 doc/source/tools/nodetool.rst | 22 
 6 files changed, 100 insertions(+), 23 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b9191871/.gitignore
--
diff --git a/.gitignore b/.gitignore
index f5b1ce1..76c4bd1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -75,3 +75,4 @@ lib/jsr223/scala/*.jar
 
 # Generated files from the documentation
 doc/source/configuration/cassandra_config_file.rst
+doc/source/tools/nodetool

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b9191871/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b5d5bf4..2783b9f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Add (automate) Nodetool Documentation (CASSANDRA-12672)
  * Update bundled cqlsh python driver to 3.7.0 (CASSANDRA-12736)
  * Reject invalid replication settings when creating or altering a keyspace 
(CASSANDRA-12681)
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b9191871/doc/Makefile
--
diff --git a/doc/Makefile b/doc/Makefile
index 81d7707..88ceaaf 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -19,6 +19,8 @@ YAML_DOC_OUTPUT=source/configuration/cassandra_config_file.rst
 
 MAKE_CASSANDRA_YAML = python convert_yaml_to_rst.py $(YAML_DOC_INPUT) 
$(YAML_DOC_OUTPUT)
 
+GENERATE_NODETOOL_DOCS = python gen-nodetool-docs.py
+
 WEB_SITE_PRESENCE_FILE='source/.build_for_website'
 
 .PHONY: help
@@ -60,6 +62,7 @@ clean:
 .PHONY: html
 html:
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
@@ -68,6 +71,7 @@ html:
 website: clean
@touch $(WEB_SITE_PRESENCE_FILE)
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@rm $(WEB_SITE_PRESENCE_FILE)
@echo
@@ -76,6 +80,7 @@ website: clean
 .PHONY: dirhtml
 dirhtml:
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
@@ -83,6 +88,7 @@ dirhtml:
 .PHONY: singlehtml
 singlehtml:
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
@@ -90,6 +96,7 @@ singlehtml:
 .PHONY: pickle
 pickle:
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
@@ -97,6 +104,7 @@ pickle:
 .PHONY: json
 json:
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
@@ -104,6 +112,7 @@ json:
 .PHONY: htmlhelp
 htmlhelp:
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
@@ -112,6 +121,7 @@ htmlhelp:
 .PHONY: qthelp
 qthelp:
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" 
\
@@ -123,6 +133,7 @@ qthelp:
 .PHONY: applehelp
 applehelp:
$(MAKE_CASSANDRA_YAML)
+   $(GENERATE_NODETOOL_DOCS)

[jira] [Updated] (CASSANDRA-12672) Automate Nodetool Documentation

[mck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mck updated CASSANDRA-12672:

Fix Version/s: (was: 3.x)
   4.0

> Automate Nodetool Documentation
> ---
>
> Key: CASSANDRA-12672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12672
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Andrew Baker
>Priority: Minor
>  Labels: documentaion, lhf, nodetool
> Fix For: 4.0
>
>
> nodetool.rst has this:
> todo:: Try to autogenerate this from Nodetool’s help.
> creating a ticket to submit this work against



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12701) Repair history tables should have TTL and TWCS

[Christopher Bradford (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Bradford updated CASSANDRA-12701:
-
Attachment: CASSANDRA-12701.txt

> Repair history tables should have TTL and TWCS
> --
>
> Key: CASSANDRA-12701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12701
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Chris Lohfink
>  Labels: lhf
> Attachments: CASSANDRA-12701.txt
>
>
> Some tools schedule a lot of small subrange repairs which can lead to a lot 
> of repairs constantly being run. These partitions can grow pretty big in 
> theory. I dont think much reads from them which might help but its still 
> kinda wasted disk space. I think a month TTL (longer than gc grace) and maybe 
> a 1 day twcs window makes sense to me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12701) Repair history tables should have TTL and TWCS

[Christopher Bradford (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Bradford updated CASSANDRA-12701:
-
Status: Patch Available  (was: Open)

> Repair history tables should have TTL and TWCS
> --
>
> Key: CASSANDRA-12701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12701
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Chris Lohfink
>  Labels: lhf
> Attachments: CASSANDRA-12701.txt
>
>
> Some tools schedule a lot of small subrange repairs which can lead to a lot 
> of repairs constantly being run. These partitions can grow pretty big in 
> theory. I dont think much reads from them which might help but its still 
> kinda wasted disk space. I think a month TTL (longer than gc grace) and maybe 
> a 1 day twcs window makes sense to me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12582) Removing static column results in ReadFailure due to CorruptSSTableException

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15554114#comment-15554114
 ] 

Stefania commented on CASSANDRA-12582:
--

Rebased on the latest branches, the 3.0 patch applies cleanly upwards:

||3.0||3.X||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/12582-3.0]|[patch|https://github.com/stef1927/cassandra/commits/12582-3.X]|[patch|https://github.com/stef1927/cassandra/commits/12582]|
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12582-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12582-3.X-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12582-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12582-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12582-3.X-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12582-dtest/]|

Since there were no conflicts when rebasing, I did not relaunch the CI jobs 
which were clean.

> Removing static column results in ReadFailure due to CorruptSSTableException
> 
>
> Key: CASSANDRA-12582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12582
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: Cassandra 3.0.8
>Reporter: Evan Prothro
>Assignee: Stefania
>Priority: Critical
>  Labels: compaction, corruption, drop, read, static
> Fix For: 3.0.x, 3.x
>
> Attachments: 12582.cdl, 12582_reproduce.sh
>
>
> We ran into an issue on production where reads began to fail for certain 
> queries, depending on the range within the relation for those queries. 
> Cassandra system log showed an unhandled {{CorruptSSTableException}} 
> exception.
> CQL read failure:
> {code}
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> Cassandra exception:
> {code}
> WARN  [SharedPool-Worker-2] 2016-08-31 12:49:27,979 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.RuntimeException: 
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted: 
> /usr/local/apache-cassandra-3.0.8/data/data/issue309/apples_by_tree-006748a06fa311e6a7f8ef8b642e977b/mb-1-big-Data.db
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2453)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_72]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.8.jar:3.0.8]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: 
> Corrupted: 
> /usr/local/apache-cassandra-3.0.8/data/data/issue309/apples_by_tree-006748a06fa311e6a7f8ef8b642e977b/mb-1-big-Data.db
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:343)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:66)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:62)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:24)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:295)
>  

[jira] [Commented] (CASSANDRA-12457) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_2_x.bug_5732_test

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15554096#comment-15554096
 ] 

Stefania commented on CASSANDRA-12457:
--

Rebased on latest branches, the 3.0 patch applies cleanly upwards:

||2.2||3.0||3.X||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/12457-2.2]|[patch|https://github.com/stef1927/cassandra/commits/12457-3.0]|[patch|https://github.com/stef1927/cassandra/commits/12457-3.X]|[patch|https://github.com/stef1927/cassandra/commits/12457]|
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12457-2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12457-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12457-3.X-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12457-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12457-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12457-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12457-3.X-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12457-dtest/]|


> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_2_x.bug_5732_test
> 
>
> Key: CASSANDRA-12457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12457
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
>Reporter: Craig Kodman
>Assignee: Stefania
>  Labels: dtest
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 12457_2.1_logs_with_allocation_stacks.tar.gz, 
> 12457_2.2_logs_with_allocation_stacks_1.tar.gz, 
> 12457_2.2_logs_with_allocation_stacks_2.tar.gz, 
> 12457_2.2_logs_with_allocation_stacks_3.tar.gz, 
> 12457_2.2_logs_with_allocation_stacks_4.tar.gz, node1.log, node1_debug.log, 
> node1_gc.log, node2.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.2_dtest_upgrade/16/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_2_x/bug_5732_test
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 358, in run
> self.tearDown()
>   File "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_base.py", line 
> 216, in tearDown
> super(UpgradeTester, self).tearDown()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 666, in tearDown
> raise AssertionError('Unexpected error in log, see stdout')
> "Unexpected error in log, see stdout\n >> begin captured 
> logging << \ndtest: DEBUG: Upgrade test beginning, 
> setting CASSANDRA_VERSION to 2.1.15, and jdk to 8. (Prior values will be 
> restored after test).\ndtest: DEBUG: cluster ccm directory: 
> /mnt/tmp/dtest-D8UF3i\ndtest: DEBUG: Done setting configuration options:\n{   
> 'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold': 
> 5,\n'range_request_timeout_in_ms': 1,\n
> 'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n   
>  'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms': 
> 1}\ndtest: DEBUG: [[Row(table_name=u'ks', index_name=u'test.testindex')], 
> [Row(table_name=u'ks', index_name=u'test.testindex')]]\ndtest: DEBUG: 
> upgrading node1 to git:91f7387e1f785b18321777311a5c3416af0663c2\nccm: INFO: 
> Fetching Cassandra updates...\ndtest: DEBUG: Querying upgraded node\ndtest: 
> DEBUG: Querying old node\ndtest: DEBUG: removing ccm cluster test at: 
> /mnt/tmp/dtest-D8UF3i\ndtest: DEBUG: clearing ssl stores from 
> [/mnt/tmp/dtest-D8UF3i] directory\n- >> end captured 
> logging << -"
> {code}
> {code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:91f7387e1f785b18321777311a5c3416af0663c2
> Unexpected error in node1 log, error: 
> ERROR [Reference-Reaper:1] 2016-08-13 01:34:34,581 Ref.java:199 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@73deb57f) to class 
> org.apache.cassandra.io.sstable.SSTableReader$DescriptorTypeTidy@2098812276:/mnt/tmp/dtest-D8UF3i/test/node1/data1/system/schema_columns-296e9c049bec3085827dc17d3df2122a/system-schema_columns-ka-4
>  was not released before the reference was garbage collected
> Unexpected error in node1 log, error: 
> ERROR [Reference-Reaper:1] 2016-08-13 01:34:34,581 Ref.java:199 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@7926de0f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$1@1009016655:[[OffHeapBitSet]]
>  was not released before the reference was garbage 

[jira] [Commented] (CASSANDRA-12450) CQLSSTableWriter does not allow Update statement

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15554071#comment-15554071
 ] 

Stefania commented on CASSANDRA-12450:
--

LGTM - committed to 3.X as 47c473ae3c0455e02b7a8529746988afdfdd9c54 and merged 
into trunk.

> CQLSSTableWriter does not allow Update statement
> 
>
> Key: CASSANDRA-12450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12450
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Kuku1
>Assignee: Alex Petrov
> Fix For: 3.10
>
>
> CQLSSTableWriter throws Exception when trying to use Update statement.
> Has been working fine in previous versions for me.
> Code:
> {code}
>   public static void main(String[] args) throws IOException {
>   final String KS = "test";
>   final String TABLE = "data";
>   final String schema = "CREATE TABLE " + KS + "." + TABLE
>   + "(k text, c1 text, c2 text, c3 text, v text, 
> primary key(k, c1,c2,c3))";
>   final String query = "UPDATE " + KS + "." + TABLE + " SET v = ? 
> WHERE k = ? and c1 = ? and c2 = ? and c3 = ?";
>   File dataDir = new File(...);
>   CQLSSTableWriter writer = 
> CQLSSTableWriter.builder().inDirectory(dataDir).forTable(schema).using(query).build();
>  //Exception here (see below) 
>   HashMap row = new HashMap<>();
>   row.put("k", "a");
>   row.put("c1", "a");
>   row.put("c2", "a");
>   row.put("c3", "a");
>   row.put("v", "v");
>   writer.addRow(row);
>   writer.close();
>   }
> {code}
> Exception:
> {code}
> 14:51:00.461 [main] INFO  o.a.cassandra.cql3.QueryProcessor - Initialized 
> prepar
> ed statement caches with 0 MB (native) and 0 MB (Thrift)
> Exception in thread "main" java.lang.IllegalArgumentException: Invalid query, 
> mu
> st be a INSERT statement but was: class 
> org.apache.cassandra.cql3.statements.Upd
> ateStatement$ParsedUpdate
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.parseStatement(CQLSS
> TableWriter.java:589)
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.access$000(CQLSSTabl
> eWriter.java:102)
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSST
> ableWriter.java:445)
> at CassandraJsonImporter.main(Cassand
> raJsonImporter.java:66)
> {code}
> I'm currently testing it with 3.7 version, my POM looks like this:
> {code}
> 
> org.apache.cassandra
> cassandra-all
> 3.7
> 
> 
> org.apache.cassandra
> cassandra-clientutil
> 3.7
> 
> 
>   com.datastax.cassandra
>   cassandra-driver-core
>   3.0.0
> 
> {code}
> It has been working with 3.0.8 versions in the POM, but that version is 
> somehow not including the UDT support? 
> I want to use UPDATE instead of INSERT because I need to append data to lists 
> and do not want to overwrite existing data in the lists. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12450) CQLSSTableWriter does not allow Update statement

[Stefania (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefania updated CASSANDRA-12450:
-
Component/s: (was: Streaming and Messaging)
 Tools

> CQLSSTableWriter does not allow Update statement
> 
>
> Key: CASSANDRA-12450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12450
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Kuku1
>Assignee: Alex Petrov
> Fix For: 3.10
>
>
> CQLSSTableWriter throws Exception when trying to use Update statement.
> Has been working fine in previous versions for me.
> Code:
> {code}
>   public static void main(String[] args) throws IOException {
>   final String KS = "test";
>   final String TABLE = "data";
>   final String schema = "CREATE TABLE " + KS + "." + TABLE
>   + "(k text, c1 text, c2 text, c3 text, v text, 
> primary key(k, c1,c2,c3))";
>   final String query = "UPDATE " + KS + "." + TABLE + " SET v = ? 
> WHERE k = ? and c1 = ? and c2 = ? and c3 = ?";
>   File dataDir = new File(...);
>   CQLSSTableWriter writer = 
> CQLSSTableWriter.builder().inDirectory(dataDir).forTable(schema).using(query).build();
>  //Exception here (see below) 
>   HashMap row = new HashMap<>();
>   row.put("k", "a");
>   row.put("c1", "a");
>   row.put("c2", "a");
>   row.put("c3", "a");
>   row.put("v", "v");
>   writer.addRow(row);
>   writer.close();
>   }
> {code}
> Exception:
> {code}
> 14:51:00.461 [main] INFO  o.a.cassandra.cql3.QueryProcessor - Initialized 
> prepar
> ed statement caches with 0 MB (native) and 0 MB (Thrift)
> Exception in thread "main" java.lang.IllegalArgumentException: Invalid query, 
> mu
> st be a INSERT statement but was: class 
> org.apache.cassandra.cql3.statements.Upd
> ateStatement$ParsedUpdate
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.parseStatement(CQLSS
> TableWriter.java:589)
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.access$000(CQLSSTabl
> eWriter.java:102)
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSST
> ableWriter.java:445)
> at CassandraJsonImporter.main(Cassand
> raJsonImporter.java:66)
> {code}
> I'm currently testing it with 3.7 version, my POM looks like this:
> {code}
> 
> org.apache.cassandra
> cassandra-all
> 3.7
> 
> 
> org.apache.cassandra
> cassandra-clientutil
> 3.7
> 
> 
>   com.datastax.cassandra
>   cassandra-driver-core
>   3.0.0
> 
> {code}
> It has been working with 3.0.8 versions in the POM, but that version is 
> somehow not including the UDT support? 
> I want to use UPDATE instead of INSERT because I need to append data to lists 
> and do not want to overwrite existing data in the lists. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12450) CQLSSTableWriter does not allow Update statement

[Stefania (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefania updated CASSANDRA-12450:
-
   Resolution: Fixed
Fix Version/s: 3.10
   Status: Resolved  (was: Patch Available)

> CQLSSTableWriter does not allow Update statement
> 
>
> Key: CASSANDRA-12450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12450
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Kuku1
>Assignee: Alex Petrov
> Fix For: 3.10
>
>
> CQLSSTableWriter throws Exception when trying to use Update statement.
> Has been working fine in previous versions for me.
> Code:
> {code}
>   public static void main(String[] args) throws IOException {
>   final String KS = "test";
>   final String TABLE = "data";
>   final String schema = "CREATE TABLE " + KS + "." + TABLE
>   + "(k text, c1 text, c2 text, c3 text, v text, 
> primary key(k, c1,c2,c3))";
>   final String query = "UPDATE " + KS + "." + TABLE + " SET v = ? 
> WHERE k = ? and c1 = ? and c2 = ? and c3 = ?";
>   File dataDir = new File(...);
>   CQLSSTableWriter writer = 
> CQLSSTableWriter.builder().inDirectory(dataDir).forTable(schema).using(query).build();
>  //Exception here (see below) 
>   HashMap row = new HashMap<>();
>   row.put("k", "a");
>   row.put("c1", "a");
>   row.put("c2", "a");
>   row.put("c3", "a");
>   row.put("v", "v");
>   writer.addRow(row);
>   writer.close();
>   }
> {code}
> Exception:
> {code}
> 14:51:00.461 [main] INFO  o.a.cassandra.cql3.QueryProcessor - Initialized 
> prepar
> ed statement caches with 0 MB (native) and 0 MB (Thrift)
> Exception in thread "main" java.lang.IllegalArgumentException: Invalid query, 
> mu
> st be a INSERT statement but was: class 
> org.apache.cassandra.cql3.statements.Upd
> ateStatement$ParsedUpdate
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.parseStatement(CQLSS
> TableWriter.java:589)
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.access$000(CQLSSTabl
> eWriter.java:102)
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSST
> ableWriter.java:445)
> at CassandraJsonImporter.main(Cassand
> raJsonImporter.java:66)
> {code}
> I'm currently testing it with 3.7 version, my POM looks like this:
> {code}
> 
> org.apache.cassandra
> cassandra-all
> 3.7
> 
> 
> org.apache.cassandra
> cassandra-clientutil
> 3.7
> 
> 
>   com.datastax.cassandra
>   cassandra-driver-core
>   3.0.0
> 
> {code}
> It has been working with 3.0.8 versions in the POM, but that version is 
> somehow not including the UDT support? 
> I want to use UPDATE instead of INSERT because I need to append data to lists 
> and do not want to overwrite existing data in the lists. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[3/3] cassandra git commit: Merge branch 'cassandra-3.X' into trunk

[stefania]

Merge branch 'cassandra-3.X' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/324bd718
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/324bd718
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/324bd718

Branch: refs/heads/trunk
Commit: 324bd7187325e78c073555fafac1499e5b241880
Parents: c3f7c2c 47c473a
Author: Stefania Alborghetti 
Authored: Fri Oct 7 12:14:10 2016 +0800
Committer: Stefania Alborghetti 
Committed: Fri Oct 7 12:14:10 2016 +0800

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cql3/QueryProcessor.java   | 18 -
 .../cassandra/io/sstable/CQLSSTableWriter.java  | 36 +++---
 .../io/sstable/CQLSSTableWriterTest.java| 71 ++--
 .../apache/cassandra/stress/StressProfile.java  |  5 +-
 5 files changed, 93 insertions(+), 38 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/324bd718/CHANGES.txt
--
diff --cc CHANGES.txt
index 837b976,f566b1b..b5d5bf4
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,9 -1,5 +1,10 @@@
 +4.0
 + * Update bundled cqlsh python driver to 3.7.0 (CASSANDRA-12736)
 + * Reject invalid replication settings when creating or altering a keyspace 
(CASSANDRA-12681)
 +
 +
  3.10
+  * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
   * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
   * Add pre- and post-shutdown hooks to Storage Service (CASSANDRA-12461)
   * Add hint delivery metrics (CASSANDRA-12693)

[1/3] cassandra git commit: CQLSSTableWriter does not allow Update statement

[stefania]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.X 6216ce879 -> 47c473ae3
  refs/heads/trunk c3f7c2cd7 -> 324bd7187


CQLSSTableWriter does not allow Update statement

Patch by Alex Petrov; reviewed by Stefania Alborghetti for CASSANDRA-12450


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/47c473ae
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/47c473ae
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/47c473ae

Branch: refs/heads/cassandra-3.X
Commit: 47c473ae3c0455e02b7a8529746988afdfdd9c54
Parents: 6216ce8
Author: Alex Petrov 
Authored: Fri Oct 7 12:09:12 2016 +0800
Committer: Stefania Alborghetti 
Committed: Fri Oct 7 12:11:32 2016 +0800

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cql3/QueryProcessor.java   | 18 -
 .../cassandra/io/sstable/CQLSSTableWriter.java  | 36 +++---
 .../io/sstable/CQLSSTableWriterTest.java| 71 ++--
 .../apache/cassandra/stress/StressProfile.java  |  5 +-
 5 files changed, 93 insertions(+), 38 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/47c473ae/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 08de041..f566b1b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
  * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
  * Add pre- and post-shutdown hooks to Storage Service (CASSANDRA-12461)
  * Add hint delivery metrics (CASSANDRA-12693)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/47c473ae/src/java/org/apache/cassandra/cql3/QueryProcessor.java
--
diff --git a/src/java/org/apache/cassandra/cql3/QueryProcessor.java 
b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
index c91105e..5313a1a 100644
--- a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
+++ b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
@@ -546,6 +546,22 @@ public class QueryProcessor implements QueryHandler
 return statement.prepare();
 }
 
+public static  T parseStatement(String 
queryStr, Class klass, String type) throws SyntaxException
+{
+try
+{
+ParsedStatement stmt = parseStatement(queryStr);
+
+if (!klass.isAssignableFrom(stmt.getClass()))
+throw new IllegalArgumentException("Invalid query, must be a " 
+ type + " statement but was: " + stmt.getClass());
+
+return klass.cast(stmt);
+}
+catch (RequestValidationException e)
+{
+throw new IllegalArgumentException(e.getMessage(), e);
+}
+}
 public static ParsedStatement parseStatement(String queryStr) throws 
SyntaxException
 {
 try
@@ -622,7 +638,7 @@ public class QueryProcessor implements QueryHandler
 while (iterator.hasNext())
 {
 Map.Entry entry = 
iterator.next();
-if (shouldInvalidate(ksName, cfName, 
entry.getValue().statement)) 
+if (shouldInvalidate(ksName, cfName, 
entry.getValue().statement))
 {
 SystemKeyspace.removePreparedStatement(entry.getKey());
 iterator.remove();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/47c473ae/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java 
b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
index 8a9d01d..a195235 100644
--- a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
@@ -41,6 +41,7 @@ import org.apache.cassandra.cql3.UpdateParameters;
 import org.apache.cassandra.cql3.functions.UDHelper;
 import org.apache.cassandra.cql3.statements.CreateTableStatement;
 import org.apache.cassandra.cql3.statements.CreateTypeStatement;
+import org.apache.cassandra.cql3.statements.ModificationStatement;
 import org.apache.cassandra.cql3.statements.ParsedStatement;
 import org.apache.cassandra.cql3.statements.UpdateStatement;
 import org.apache.cassandra.db.Clustering;
@@ -50,7 +51,6 @@ import org.apache.cassandra.db.partitions.Partition;
 import org.apache.cassandra.dht.IPartitioner;
 import org.apache.cassandra.dht.Murmur3Partitioner;
 import org.apache.cassandra.exceptions.InvalidRequestException;
-import 

[2/3] cassandra git commit: CQLSSTableWriter does not allow Update statement

[stefania]

CQLSSTableWriter does not allow Update statement

Patch by Alex Petrov; reviewed by Stefania Alborghetti for CASSANDRA-12450


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/47c473ae
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/47c473ae
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/47c473ae

Branch: refs/heads/trunk
Commit: 47c473ae3c0455e02b7a8529746988afdfdd9c54
Parents: 6216ce8
Author: Alex Petrov 
Authored: Fri Oct 7 12:09:12 2016 +0800
Committer: Stefania Alborghetti 
Committed: Fri Oct 7 12:11:32 2016 +0800

--
 CHANGES.txt |  1 +
 .../apache/cassandra/cql3/QueryProcessor.java   | 18 -
 .../cassandra/io/sstable/CQLSSTableWriter.java  | 36 +++---
 .../io/sstable/CQLSSTableWriterTest.java| 71 ++--
 .../apache/cassandra/stress/StressProfile.java  |  5 +-
 5 files changed, 93 insertions(+), 38 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/47c473ae/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 08de041..f566b1b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.10
+ * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
  * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
  * Add pre- and post-shutdown hooks to Storage Service (CASSANDRA-12461)
  * Add hint delivery metrics (CASSANDRA-12693)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/47c473ae/src/java/org/apache/cassandra/cql3/QueryProcessor.java
--
diff --git a/src/java/org/apache/cassandra/cql3/QueryProcessor.java 
b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
index c91105e..5313a1a 100644
--- a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
+++ b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
@@ -546,6 +546,22 @@ public class QueryProcessor implements QueryHandler
 return statement.prepare();
 }
 
+public static  T parseStatement(String 
queryStr, Class klass, String type) throws SyntaxException
+{
+try
+{
+ParsedStatement stmt = parseStatement(queryStr);
+
+if (!klass.isAssignableFrom(stmt.getClass()))
+throw new IllegalArgumentException("Invalid query, must be a " 
+ type + " statement but was: " + stmt.getClass());
+
+return klass.cast(stmt);
+}
+catch (RequestValidationException e)
+{
+throw new IllegalArgumentException(e.getMessage(), e);
+}
+}
 public static ParsedStatement parseStatement(String queryStr) throws 
SyntaxException
 {
 try
@@ -622,7 +638,7 @@ public class QueryProcessor implements QueryHandler
 while (iterator.hasNext())
 {
 Map.Entry entry = 
iterator.next();
-if (shouldInvalidate(ksName, cfName, 
entry.getValue().statement)) 
+if (shouldInvalidate(ksName, cfName, 
entry.getValue().statement))
 {
 SystemKeyspace.removePreparedStatement(entry.getKey());
 iterator.remove();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/47c473ae/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
--
diff --git a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java 
b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
index 8a9d01d..a195235 100644
--- a/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
+++ b/src/java/org/apache/cassandra/io/sstable/CQLSSTableWriter.java
@@ -41,6 +41,7 @@ import org.apache.cassandra.cql3.UpdateParameters;
 import org.apache.cassandra.cql3.functions.UDHelper;
 import org.apache.cassandra.cql3.statements.CreateTableStatement;
 import org.apache.cassandra.cql3.statements.CreateTypeStatement;
+import org.apache.cassandra.cql3.statements.ModificationStatement;
 import org.apache.cassandra.cql3.statements.ParsedStatement;
 import org.apache.cassandra.cql3.statements.UpdateStatement;
 import org.apache.cassandra.db.Clustering;
@@ -50,7 +51,6 @@ import org.apache.cassandra.db.partitions.Partition;
 import org.apache.cassandra.dht.IPartitioner;
 import org.apache.cassandra.dht.Murmur3Partitioner;
 import org.apache.cassandra.exceptions.InvalidRequestException;
-import org.apache.cassandra.exceptions.RequestValidationException;
 import org.apache.cassandra.exceptions.SyntaxException;
 import org.apache.cassandra.io.sstable.format.SSTableFormat;
 import 

[jira] [Commented] (CASSANDRA-12736) Update the bundled python driver on trunk

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553990#comment-15553990
 ] 

Stefania commented on CASSANDRA-12736:
--

I created a driver [pull 
request|https://github.com/datastax/python-driver/pull/668] to merge the 
temporary fix into _cassandra-test_ in case we need to bundle a new version 
before [PYTHON-651|https://datastax-oss.atlassian.net/browse/PYTHON-651] is 
available.

> Update the bundled python driver on trunk
> -
>
> Key: CASSANDRA-12736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12736
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Philip Thompson
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 4.0
>
>
> Trunk was recently updated to be version 4.0. The bundled python driver that 
> cqlsh uses has a bug where it fails to connect to a C* server with a major 
> version number greater than 3. The driver was fixed upstream, and we should 
> pull in the fix.
> [~pauloricardomg] or [~stefania]?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11534) cqlsh fails to format collections when using aliases

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553950#comment-15553950
 ] 

Stefania commented on CASSANDRA-11534:
--

The driver [pull request|https://github.com/datastax/python-driver/pull/665] is 
still not merged, ping [~aholmber]. 

> cqlsh fails to format collections when using aliases
> 
>
> Key: CASSANDRA-11534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11534
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: Stefania
>Priority: Minor
>  Labels: cqlsh
> Fix For: 3.x
>
>
> Given is a simple table. Selecting the columns without an alias works fine. 
> However, if the map is selected using an alias, cqlsh fails to format the 
> value.
> {code}
> create keyspace foo WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE foo.foo (id int primary key, m map);
> insert into foo.foo (id, m) VALUES ( 1, {1: 'one', 2: 'two', 3:'three'});
> insert into foo.foo (id, m) VALUES ( 2, {1: '1one', 2: '2two', 3:'3three'});
> cqlsh> select id, m from foo.foo;
>  id | m
> +-
>   1 |{1: 'one', 2: 'two', 3: 'three'}
>   2 | {1: '1one', 2: '2two', 3: '3three'}
> (2 rows)
> cqlsh> select id, m as "weofjkewopf" from foo.foo;
>  id | weofjkewopf
> +---
>   1 |OrderedMapSerializedKey([(1, u'one'), (2, u'two'), (3, u'three')])
>   2 | OrderedMapSerializedKey([(1, u'1one'), (2, u'2two'), (3, u'3three')])
> (2 rows)
> Failed to format value OrderedMapSerializedKey([(1, u'one'), (2, u'two'), (3, 
> u'three')]) : 'NoneType' object has no attribute 'sub_types'
> Failed to format value OrderedMapSerializedKey([(1, u'1one'), (2, u'2two'), 
> (3, u'3three')]) : 'NoneType' object has no attribute 'sub_types'
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12758) Expose tasks queue length via JMX

[Michael Shuler (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553766#comment-15553766
 ] 

Michael Shuler commented on CASSANDRA-12758:


I updated fixver to 2.2.x, 3.0.x, 3.x, 4.x.  The 2.1 branch is critical-fix 
only, so while I understand this is related, an improvement shouldn't be pushed 
to 2.1. If some devs feel differently, I won't argue, however.

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.x, 4.x
>
> Attachments: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch, 
> 0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch
>
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12758) Expose tasks queue length via JMX

[Michael Shuler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Shuler updated CASSANDRA-12758:
---
Fix Version/s: 3.0.x

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.x, 4.x
>
> Attachments: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch, 
> 0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch
>
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12758) Expose tasks queue length via JMX

[Michael Shuler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Shuler updated CASSANDRA-12758:
---
Fix Version/s: (was: 2.1.16)
   2.2.x

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
> Fix For: 2.2.x, 3.x, 4.x
>
> Attachments: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch, 
> 0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch
>
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553759#comment-15553759
 ] 

mck commented on CASSANDRA-11381:
-

ping. is there anything outstanding here?

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: 11381-2.1.txt, 11381-2.2.txt, 11381-3.0.txt, 
> 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> 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)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12754) Change cassandra.wait_for_tracing_events_timeout_secs default to -1 so C* doesn't wait on trace events to be written before responding to request by default

[Jeremiah Jordan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremiah Jordan updated CASSANDRA-12754:

Fix Version/s: 3.x
   3.0.x
   2.2.x

> Change cassandra.wait_for_tracing_events_timeout_secs default to -1 so C* 
> doesn't wait on trace events to be written before responding to request by 
> default
> 
>
> Key: CASSANDRA-12754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12754
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andy Tolbert
>Assignee: Stefania
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> [CASSANDRA-11465] introduces a new system property 
> {{cassandra.wait_for_tracing_events_timeout_secs}} that controls whether or 
> not C* waits for events to be written before responding to client.   The 
> current default behavior is to wait up to 1 second and then respond and 
> timeout.  
> If using probabilistic tracing this can cause queries to be randomly delayed 
> up to 1 second.
> Changing the default to -1 (disabled and enabling it explicitly in 
> {{cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test}}.
> Ideally it would be nice to be able to control this behavior on a per request 
> basis (which would require native protocol changes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CASSANDRA-12754) Change cassandra.wait_for_tracing_events_timeout_secs default to -1 so C* doesn't wait on trace events to be written before responding to request by default

[Stefania (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefania reassigned CASSANDRA-12754:


Assignee: Stefania

> Change cassandra.wait_for_tracing_events_timeout_secs default to -1 so C* 
> doesn't wait on trace events to be written before responding to request by 
> default
> 
>
> Key: CASSANDRA-12754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12754
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Andy Tolbert
>Assignee: Stefania
>
> [CASSANDRA-11465] introduces a new system property 
> {{cassandra.wait_for_tracing_events_timeout_secs}} that controls whether or 
> not C* waits for events to be written before responding to client.   The 
> current default behavior is to wait up to 1 second and then respond and 
> timeout.  
> If using probabilistic tracing this can cause queries to be randomly delayed 
> up to 1 second.
> Changing the default to -1 (disabled and enabling it explicitly in 
> {{cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test}}.
> Ideally it would be nice to be able to control this behavior on a per request 
> basis (which would require native protocol changes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11380) Client visible backpressure mechanism

[Stefania (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553677#comment-15553677
 ] 

Stefania commented on CASSANDRA-11380:
--

CASSANDRA-9318 added a backpressure mechanism at the coordinator. It's not 
client visible but it indirectly slows down clients by delaying mutations at 
the coordinator based on the rate at which replicas acknowledge mutations. It 
also allows the possibility of implementing new strategies.  It's a long 
discussion, this is the initial 
[comment|https://issues.apache.org/jira/browse/CASSANDRA-9318?focusedCommentId=15344958=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15344958]
 (Sergio Bossa - 23 Jun 16) that describes the backpressure mechanism, but then 
it got changed again a few times so for a quick summary you can read the 
documentation in 
[cassandra.yaml|https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1176].

> Client visible backpressure mechanism
> -
>
> Key: CASSANDRA-11380
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11380
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Coordination
>Reporter: Wei Deng
>
> Cassandra currently lacks a sophisticated back pressure mechanism to prevent 
> clients ingesting data at too high throughput. One of the reasons why it 
> hasn't done so is because of its SEDA (Staged Event Driven Architecture) 
> design. With SEDA, an overloaded thread pool can drop those droppable 
> messages (in this case, MutationStage can drop mutation or counter mutation 
> messages) when they exceed the 2-second timeout. This can save the JVM from 
> running out of memory and crash. However, one downside from this kind of 
> load-shedding based backpressure approach is that increased number of dropped 
> mutations will increase the chance of inconsistency among replicas and will 
> likely require more repair (hints can help to some extent, but it's not 
> designed to cover all inconsistencies); another downside is that excessive 
> writes will also introduce much more pressure on compaction (especially LCS), 
>  and backlogged compaction will increase read latency and cause more frequent 
> GC pauses, and depending on the type of compaction, some backlog can take a 
> long time to clear up even after the write is removed. It seems that the 
> current load-shedding mechanism is not adequate to address a common bulk 
> loading scenario, where clients are trying to ingest data at highest 
> throughput possible. We need a more direct way to tell the client drivers to 
> slow down.
> It appears that HBase had suffered similar situation as discussed in 
> HBASE-5162, and they introduced some special exception type to tell the 
> client to slow down when a certain "overloaded" criteria is met. If we can 
> leverage a similar mechanism, our dropped mutation event can be used to 
> trigger such exceptions to push back on the client; at the same time, 
> backlogged compaction (when the number of pending compactions exceeds a 
> certain threshold) can also be used for the push back and this can prevent 
> vicious cycle mentioned in 
> https://issues.apache.org/jira/browse/CASSANDRA-11366?focusedCommentId=15198786=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15198786.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9754) Make index info heap friendly for large CQL partitions

[Michael Kjellman (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553444#comment-15553444
 ] 

Michael Kjellman commented on CASSANDRA-9754:
-

I just pushed up a squashed commit for the roughly 68 individual commits I've 
made while working on stability and performance over the past few weeks.

https://github.com/mkjellman/cassandra/commit/41c6d43d0b020149a5564d4f7ab3c92e1bfcba64

I'm currently writing up the findings from the latest stress test I've been 
running for the last 24 hours across 3 performance clusters and will update the 
ticket with that in a bit.

> Make index info heap friendly for large CQL partitions
> --
>
> Key: CASSANDRA-9754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9754
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Michael Kjellman
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 9754_part1-v1.diff, 9754_part2-v1.diff
>
>
>  Looking at a heap dump of 2.0 cluster, I found that majority of the objects 
> are IndexInfo and its ByteBuffers. This is specially bad in endpoints with 
> large CQL partitions. If a CQL partition is say 6,4GB, it will have 100K 
> IndexInfo objects and 200K ByteBuffers. This will create a lot of churn for 
> GC. Can this be improved by not creating so many objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12758) Expose tasks queue length via JMX

[Romain Hardouin (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553393#comment-15553393
 ] 

Romain Hardouin commented on CASSANDRA-12758:
-

The patch for the trunk also works for 3.X.

I think this MBean should be included in 2.1.16 because:
* the NTR queue size issue is a pain in production
* it really goes hand-in-hand with CASSANDRA-11363

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
> Fix For: 2.1.16, 3.x, 4.x
>
> Attachments: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch, 
> 0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch
>
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11380) Client visible backpressure mechanism

[Corentin Chary (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553373#comment-15553373
 ] 

Corentin Chary commented on CASSANDRA-11380:


This might be naive, but couldn't we just stop reading from client's socket 
(and maybe slow down compaction) if memory pressure / load becomes too high ? 
TCP will eventually do its job telling the client to "slow down". I currently 
have a setup with pretty frequent issues of infinite queues of pending mutation 
where the server seem to never be able to recover.

> Client visible backpressure mechanism
> -
>
> Key: CASSANDRA-11380
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11380
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Coordination
>Reporter: Wei Deng
>
> Cassandra currently lacks a sophisticated back pressure mechanism to prevent 
> clients ingesting data at too high throughput. One of the reasons why it 
> hasn't done so is because of its SEDA (Staged Event Driven Architecture) 
> design. With SEDA, an overloaded thread pool can drop those droppable 
> messages (in this case, MutationStage can drop mutation or counter mutation 
> messages) when they exceed the 2-second timeout. This can save the JVM from 
> running out of memory and crash. However, one downside from this kind of 
> load-shedding based backpressure approach is that increased number of dropped 
> mutations will increase the chance of inconsistency among replicas and will 
> likely require more repair (hints can help to some extent, but it's not 
> designed to cover all inconsistencies); another downside is that excessive 
> writes will also introduce much more pressure on compaction (especially LCS), 
>  and backlogged compaction will increase read latency and cause more frequent 
> GC pauses, and depending on the type of compaction, some backlog can take a 
> long time to clear up even after the write is removed. It seems that the 
> current load-shedding mechanism is not adequate to address a common bulk 
> loading scenario, where clients are trying to ingest data at highest 
> throughput possible. We need a more direct way to tell the client drivers to 
> slow down.
> It appears that HBase had suffered similar situation as discussed in 
> HBASE-5162, and they introduced some special exception type to tell the 
> client to slow down when a certain "overloaded" criteria is met. If we can 
> leverage a similar mechanism, our dropped mutation event can be used to 
> trigger such exceptions to push back on the client; at the same time, 
> backlogged compaction (when the number of pending compactions exceeds a 
> certain threshold) can also be used for the push back and this can prevent 
> vicious cycle mentioned in 
> https://issues.apache.org/jira/browse/CASSANDRA-11366?focusedCommentId=15198786=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15198786.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12758) Expose tasks queue length via JMX

[Romain Hardouin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Hardouin updated CASSANDRA-12758:

Fix Version/s: 4.x
   3.x
   Status: Patch Available  (was: Open)

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
> Fix For: 2.1.16, 3.x, 4.x
>
> Attachments: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch, 
> 0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch
>
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12758) Expose tasks queue length via JMX

[Romain Hardouin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Hardouin updated CASSANDRA-12758:

Attachment: 0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch
0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
> Fix For: 2.1.16
>
> Attachments: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch, 
> 0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch
>
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12758) Expose tasks queue length via JMX

[Romain Hardouin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Hardouin updated CASSANDRA-12758:

Status: Open  (was: Patch Available)

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
> Fix For: 2.1.16
>
> Attachments: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch, 
> 0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch
>
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12758) Expose tasks queue length via JMX

[Romain Hardouin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Hardouin updated CASSANDRA-12758:

Fix Version/s: 2.1.16
   Status: Patch Available  (was: Open)

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
> Fix For: 2.1.16
>
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12758) Expose tasks queue length via JMX

[Romain Hardouin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Hardouin updated CASSANDRA-12758:

Attachment: (was: 
0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch)

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12758) Expose tasks queue length via JMX

[Romain Hardouin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Hardouin updated CASSANDRA-12758:

Attachment: (was: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch)

> Expose tasks queue length via JMX
> -
>
> Key: CASSANDRA-12758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Romain Hardouin
>Priority: Minor
>
> CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
> to set the NTR queue length.
> Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
> allow to:
>  
> 1. Be sure this value has been set
> 2. Plot this value in a monitoring application to make correlations with 
> other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12758) Expose tasks queue length via JMX

[Romain Hardouin (JIRA)]

Romain Hardouin created CASSANDRA-12758:
---

 Summary: Expose tasks queue length via JMX
 Key: CASSANDRA-12758
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12758
 Project: Cassandra
  Issue Type: Improvement
Reporter: Romain Hardouin
Priority: Minor
 Attachments: 0001-Add-MBean-to-monitor-max-queued-tasks_2.1.patch, 
0001-Add-MBean-to-monitor-max-queued-tasks_trunk.patch

CASSANDRA-11363 introduced {{cassandra.max_queued_native_transport_requests}} 
to set the NTR queue length.
Currently Cassandra lacks of a JMX Mbean which exposes this value which would 
allow to:
 
1. Be sure this value has been set
2. Plot this value in a monitoring application to make correlations with 
other graphs when we make changes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12733) Throw an exception if there is a prepared statement id hash conflict.

[Jeremiah Jordan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremiah Jordan updated CASSANDRA-12733:

Fix Version/s: 3.x

> Throw an exception if there is a prepared statement id hash conflict.
> -
>
> Key: CASSANDRA-12733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12733
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Jeremiah Jordan
>Assignee: Jeremiah Jordan
>Priority: Minor
> Fix For: 3.x
>
>
> I seriously doubt there is any chance of actually getting two prepared 
> statement strings that have the same MD5.  But there should probably be 
> checks in QueryProcessor.getStoredPreparedStatement that the query string of 
> the statement being prepared matches the query string of the ID returned from 
> the cache when one already exists there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12757) NPE if allocate_tokens_for_keyspace is typo/doesn't exist.

[Jeremiah Jordan (JIRA)]

Jeremiah Jordan created CASSANDRA-12757:
---

 Summary: NPE if allocate_tokens_for_keyspace is typo/doesn't exist.
 Key: CASSANDRA-12757
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12757
 Project: Cassandra
  Issue Type: Bug
  Components: Configuration
Reporter: Jeremiah Jordan
 Fix For: 3.0.x, 3.x


If the keyspace specified in allocate_tokens_for_keyspace does not exist you 
get an NPE.  Should probably have a better error here letting people know what 
the issue was.

{code}
INFO  21:07:22,582  StorageService.java:1152 - JOINING: getting bootstrap token
Exception (java.lang.NullPointerException) encountered during startup: null
ERROR 21:07:22,590  CassandraDaemon.java:709 - Exception encountered during 
startup
java.lang.NullPointerException: null
   at 
org.apache.cassandra.db.Keyspace.createReplicationStrategy(Keyspace.java:325) 
~[cassandra-all-3.0.8.jar:3.0.8]
   at org.apache.cassandra.db.Keyspace.(Keyspace.java:298) 
~[cassandra-all-3.0.8.jar:3.0.8]
   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129) 
~[cassandra-all-3.0.8.jar:3.0.8]
   at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106) 
~[cassandra-all-3.0.8.jar:3.0.8]
   at 
org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:201) 
~[cassandra-all-3.0.8.jar:3.0.8]
   at 
org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173) 
~[cassandra-all-3.0.8:3.0.8]
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12582) Removing static column results in ReadFailure due to CorruptSSTableException

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12582:

Reproduced In: 3.0.9, 3.0.8, 3.0.7  (was: 3.0.7, 3.0.8, 3.0.9)
 Reviewer: Carl Yeksigian

> Removing static column results in ReadFailure due to CorruptSSTableException
> 
>
> Key: CASSANDRA-12582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12582
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: Cassandra 3.0.8
>Reporter: Evan Prothro
>Assignee: Stefania
>Priority: Critical
>  Labels: compaction, corruption, drop, read, static
> Fix For: 3.0.x, 3.x
>
> Attachments: 12582.cdl, 12582_reproduce.sh
>
>
> We ran into an issue on production where reads began to fail for certain 
> queries, depending on the range within the relation for those queries. 
> Cassandra system log showed an unhandled {{CorruptSSTableException}} 
> exception.
> CQL read failure:
> {code}
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation 
> failed - received 0 responses and 1 failures" info={'failures': 1, 
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {code}
> Cassandra exception:
> {code}
> WARN  [SharedPool-Worker-2] 2016-08-31 12:49:27,979 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[SharedPool-Worker-2,5,main]: {}
> java.lang.RuntimeException: 
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted: 
> /usr/local/apache-cassandra-3.0.8/data/data/issue309/apples_by_tree-006748a06fa311e6a7f8ef8b642e977b/mb-1-big-Data.db
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2453)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_72]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.8.jar:3.0.8]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: 
> Corrupted: 
> /usr/local/apache-cassandra-3.0.8/data/data/issue309/apples_by_tree-006748a06fa311e6a7f8ef8b642e977b/mb-1-big-Data.db
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator$1.initializeIterator(BigTableScanner.java:343)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.maybeInit(LazilyInitializedUnfilteredRowIterator.java:48)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:65)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.isReverseOrder(LazilyInitializedUnfilteredRowIterator.java:66)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:62)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:24)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:295)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) 
> ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289) 
> ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1796)
>  ~[apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> 

[jira] [Updated] (CASSANDRA-11534) cqlsh fails to format collections when using aliases

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-11534:

Reviewer: Robert Stupp

> cqlsh fails to format collections when using aliases
> 
>
> Key: CASSANDRA-11534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11534
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: Stefania
>Priority: Minor
>  Labels: cqlsh
> Fix For: 3.x
>
>
> Given is a simple table. Selecting the columns without an alias works fine. 
> However, if the map is selected using an alias, cqlsh fails to format the 
> value.
> {code}
> create keyspace foo WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE foo.foo (id int primary key, m map);
> insert into foo.foo (id, m) VALUES ( 1, {1: 'one', 2: 'two', 3:'three'});
> insert into foo.foo (id, m) VALUES ( 2, {1: '1one', 2: '2two', 3:'3three'});
> cqlsh> select id, m from foo.foo;
>  id | m
> +-
>   1 |{1: 'one', 2: 'two', 3: 'three'}
>   2 | {1: '1one', 2: '2two', 3: '3three'}
> (2 rows)
> cqlsh> select id, m as "weofjkewopf" from foo.foo;
>  id | weofjkewopf
> +---
>   1 |OrderedMapSerializedKey([(1, u'one'), (2, u'two'), (3, u'three')])
>   2 | OrderedMapSerializedKey([(1, u'1one'), (2, u'2two'), (3, u'3three')])
> (2 rows)
> Failed to format value OrderedMapSerializedKey([(1, u'one'), (2, u'two'), (3, 
> u'three')]) : 'NoneType' object has no attribute 'sub_types'
> Failed to format value OrderedMapSerializedKey([(1, u'1one'), (2, u'2two'), 
> (3, u'3three')]) : 'NoneType' object has no attribute 'sub_types'
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12720) Permissions on aggregate functions are not removed on drop

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12720:

Reviewer: Joel Knighton

> Permissions on aggregate functions are not removed on drop
> --
>
> Key: CASSANDRA-12720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12720
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> When a user defined aggregate is dropped, either directly or when it's 
> enclosing keyspace is dropped, permissions granted on it are not cleaned up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12646) nodetool stopdaemon errors out on stopdaemon

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12646:

Reviewer: Alex Petrov

> nodetool stopdaemon errors out on stopdaemon
> 
>
> Key: CASSANDRA-12646
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12646
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x
>
>
> {{nodetool stopdaemon}} works, but it prints a {{java.net.ConnectException: 
> Connection refused}} error message in {{NodeProbe.close()}} - which is 
> expected.
> Attached patch prevents that error message (i.e. it expects {{close()}} to 
> fail for {{stopdaemon}}).
> Additionally, on trunk a call to {{DD.clientInit()}} has been added, because 
> {{JVMStabilityInspector.inspectThrowable}} implicitly requires this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12535) Occasionally seeing AccessControlException, CodecNotFoundException when executing a User Defined Aggregate

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12535:

Reviewer: Carl Yeksigian

> Occasionally seeing AccessControlException, CodecNotFoundException when 
> executing a User Defined Aggregate
> --
>
> Key: CASSANDRA-12535
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12535
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 3.7 (via brew install), Mac OS X 10.11.6
>Reporter: Pat Patterson
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> I have defined a UDA to implement standard deviation:
> {noformat}
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdState ( state 
> tuple, val double ) CALLED ON NULL INPUT RETURNS 
> tuple LANGUAGE java AS 
>  ... 'int n = state.getInt(0); double mean = state.getDouble(1); double m2 = 
> state.getDouble(2); n++; double delta = val - mean; mean += delta / n; m2 += 
> delta * (val - mean); state.setInt(0, n); state.setDouble(1, mean); 
> state.setDouble(2, m2); return state;'; 
> cqlsh:mykeyspace> CREATE OR REPLACE FUNCTION sdFinal ( state 
> tuple ) CALLED ON NULL INPUT RETURNS double LANGUAGE java 
> AS 
>  ... 'int n = state.getInt(0); double m2 = state.getDouble(2); if (n < 1) { 
> return null; } return Math.sqrt(m2 / (n - 1));';
> cqlsh:mykeyspace> CREATE AGGREGATE IF NOT EXISTS stdev ( double ) 
>  ... SFUNC sdState STYPE tuple FINALFUNC sdFinal INITCOND 
> (0,0,0);
> {noformat}
> My table:
> {noformat}
> CREATE TABLE readings (
> sensor_id int,
> time timestamp,
> temperature double,
> status text,
> PRIMARY KEY (sensor_id, time)
> ) WITH CLUSTERING ORDER BY (time ASC);
> {noformat}
> I'm inserting a row every 0.1 seconds. The data looks like this:
> {noformat}
> cqlsh:mykeyspace> select * from readings limit 10;
>  sensor_id | time| status | temperature
> ---+-++-
>  5 | 2016-08-24 19:11:34.896000+ | OK |9.97
>  5 | 2016-08-24 19:11:43.933000+ | OK |   10.28
>  5 | 2016-08-24 19:11:49.958000+ | OK |7.65
>  5 | 2016-08-24 19:11:51.968000+ | OK |   10.11
>  5 | 2016-08-24 19:12:58.512000+ |  Fault |   10.41
>  5 | 2016-08-24 19:13:04.542000+ | OK |9.66
>  5 | 2016-08-24 19:13:16.593000+ | OK |10.9
>  5 | 2016-08-24 19:13:37.692000+ | OK |11.2
>  5 | 2016-08-24 19:13:46.738000+ | OK |   10.34
>  5 | 2016-08-24 19:13:49.757000+ | OK |10.6
> {noformat}
> I'm running a query every few seconds with my UDA - like this (timestamps are 
> different each time):
> {noformat}
> select avg(temperature), stdev(temperature) from readings where sensor_id = 1 
> and time > 1472066523193;
> {noformat}
> Most of the time, this works just fine:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings 
> where sensor_id = 1 and time > 1472066523193;
>  system.avg(temperature) | mykeyspace.stdev(temperature)
> -+---
>   9.9291 |   0.94179
> (1 rows)
> {noformat}
> But, occasionally, it fails with one of two exceptions:
> {noformat}
> cqlsh:mykeyspace> select avg(temperature), stdev(temperature) from readings 
> where sensor_id = 1 and time > 1472066523193;
> Traceback (most recent call last):
>   File "/usr/local/Cellar/cassandra/3.7/libexec/bin/cqlsh.py", line 1277, in 
> perform_simple_statement
> result = future.result()
>   File "cassandra/cluster.py", line 3629, in 
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369)
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'mykeyspace.sdstate[frozen>, 
> double]' failed: java.security.AccessControlException: access denied 
> ("java.io.FilePermission" "/usr/local/etc/cassandra/logback.xml" "read")"
> {noformat}
> or
> {noformat}
> cqlsh:mykeyspace> select count(*), avg(temperature), stdev(temperature) from 
> readings where sensor_id = 1 and time > '2016-08-24 15:00:00.000+';
> Traceback (most recent call last):
>   File "/usr/local/Cellar/cassandra/3.7/libexec/bin/cqlsh.py", line 1277, in 
> perform_simple_statement
> result = future.result()
>   File "cassandra/cluster.py", line 3629, in 
> cassandra.cluster.ResponseFuture.result (cassandra/cluster.c:69369)
> raise 

[jira] [Updated] (CASSANDRA-12712) Update Debian Install Doc

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12712:

Reviewer: T Jake Luciani

> Update Debian Install Doc
> -
>
> Key: CASSANDRA-12712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12712
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation and Website
>Reporter: Michael Shuler
>Assignee: Michael Shuler
> Fix For: 3.x
>
> Attachments: 0001-Update-Debian-Installation-Documentation.patch
>
>
> CASSANDRA-12239 added a key to the KEYS file, so deb repo install 
> intsructions need to be update in the doc source (wiki page is updated). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12733) Throw an exception if there is a prepared statement id hash conflict.

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12733:

Assignee: Alex Petrov  (was: Jeremiah Jordan)

> Throw an exception if there is a prepared statement id hash conflict.
> -
>
> Key: CASSANDRA-12733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12733
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Jeremiah Jordan
>Assignee: Alex Petrov
>Priority: Minor
>
> I seriously doubt there is any chance of actually getting two prepared 
> statement strings that have the same MD5.  But there should probably be 
> checks in QueryProcessor.getStoredPreparedStatement that the query string of 
> the statement being prepared matches the query string of the ID returned from 
> the cache when one already exists there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12733) Throw an exception if there is a prepared statement id hash conflict.

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12733:

Assignee: Jeremiah Jordan  (was: Alex Petrov)
Reviewer: Jeremiah Jordan

> Throw an exception if there is a prepared statement id hash conflict.
> -
>
> Key: CASSANDRA-12733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12733
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Jeremiah Jordan
>Assignee: Jeremiah Jordan
>Priority: Minor
>
> I seriously doubt there is any chance of actually getting two prepared 
> statement strings that have the same MD5.  But there should probably be 
> checks in QueryProcessor.getStoredPreparedStatement that the query string of 
> the statement being prepared matches the query string of the ID returned from 
> the cache when one already exists there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12733) Throw an exception if there is a prepared statement id hash conflict.

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12733:

Reviewer: Alex Petrov  (was: Jeremiah Jordan)

> Throw an exception if there is a prepared statement id hash conflict.
> -
>
> Key: CASSANDRA-12733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12733
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Jeremiah Jordan
>Assignee: Jeremiah Jordan
>Priority: Minor
>
> I seriously doubt there is any chance of actually getting two prepared 
> statement strings that have the same MD5.  But there should probably be 
> checks in QueryProcessor.getStoredPreparedStatement that the query string of 
> the statement being prepared matches the query string of the ID returned from 
> the cache when one already exists there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12652) Failure in SASIIndexTest.testStaticIndex-compression

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12652:

Reviewer: Joel Knighton

> Failure in SASIIndexTest.testStaticIndex-compression
> 
>
> Key: CASSANDRA-12652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12652
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Alex Petrov
>
> Stacktrace:
> {code}
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
>   at 
> org.apache.cassandra.index.sasi.SASIIndexTest.testStaticIndex(SASIIndexTest.java:1839)
>   at 
> org.apache.cassandra.index.sasi.SASIIndexTest.testStaticIndex(SASIIndexTest.java:1786)
> {code}
> Example failure:
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.index.sasi/SASIIndexTest/testStaticIndex_compression/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12457) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_2_x.bug_5732_test

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12457:

Reviewer: Marcus Eriksson

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_2_x.bug_5732_test
> 
>
> Key: CASSANDRA-12457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12457
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
>Reporter: Craig Kodman
>Assignee: Stefania
>  Labels: dtest
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 12457_2.1_logs_with_allocation_stacks.tar.gz, 
> 12457_2.2_logs_with_allocation_stacks_1.tar.gz, 
> 12457_2.2_logs_with_allocation_stacks_2.tar.gz, 
> 12457_2.2_logs_with_allocation_stacks_3.tar.gz, 
> 12457_2.2_logs_with_allocation_stacks_4.tar.gz, node1.log, node1_debug.log, 
> node1_gc.log, node2.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.2_dtest_upgrade/16/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_2_x/bug_5732_test
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 358, in run
> self.tearDown()
>   File "/home/automaton/cassandra-dtest/upgrade_tests/upgrade_base.py", line 
> 216, in tearDown
> super(UpgradeTester, self).tearDown()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 666, in tearDown
> raise AssertionError('Unexpected error in log, see stdout')
> "Unexpected error in log, see stdout\n >> begin captured 
> logging << \ndtest: DEBUG: Upgrade test beginning, 
> setting CASSANDRA_VERSION to 2.1.15, and jdk to 8. (Prior values will be 
> restored after test).\ndtest: DEBUG: cluster ccm directory: 
> /mnt/tmp/dtest-D8UF3i\ndtest: DEBUG: Done setting configuration options:\n{   
> 'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold': 
> 5,\n'range_request_timeout_in_ms': 1,\n
> 'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n   
>  'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms': 
> 1}\ndtest: DEBUG: [[Row(table_name=u'ks', index_name=u'test.testindex')], 
> [Row(table_name=u'ks', index_name=u'test.testindex')]]\ndtest: DEBUG: 
> upgrading node1 to git:91f7387e1f785b18321777311a5c3416af0663c2\nccm: INFO: 
> Fetching Cassandra updates...\ndtest: DEBUG: Querying upgraded node\ndtest: 
> DEBUG: Querying old node\ndtest: DEBUG: removing ccm cluster test at: 
> /mnt/tmp/dtest-D8UF3i\ndtest: DEBUG: clearing ssl stores from 
> [/mnt/tmp/dtest-D8UF3i] directory\n- >> end captured 
> logging << -"
> {code}
> {code}
> Standard Output
> http://git-wip-us.apache.org/repos/asf/cassandra.git 
> git:91f7387e1f785b18321777311a5c3416af0663c2
> Unexpected error in node1 log, error: 
> ERROR [Reference-Reaper:1] 2016-08-13 01:34:34,581 Ref.java:199 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@73deb57f) to class 
> org.apache.cassandra.io.sstable.SSTableReader$DescriptorTypeTidy@2098812276:/mnt/tmp/dtest-D8UF3i/test/node1/data1/system/schema_columns-296e9c049bec3085827dc17d3df2122a/system-schema_columns-ka-4
>  was not released before the reference was garbage collected
> Unexpected error in node1 log, error: 
> ERROR [Reference-Reaper:1] 2016-08-13 01:34:34,581 Ref.java:199 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@7926de0f) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$1@1009016655:[[OffHeapBitSet]]
>  was not released before the reference was garbage collected
> Unexpected error in node1 log, error: 
> ERROR [Reference-Reaper:1] 2016-08-13 01:34:34,581 Ref.java:199 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@3a5760f9) to class 
> org.apache.cassandra.io.util.MmappedSegmentedFile$Cleanup@223486002:/mnt/tmp/dtest-D8UF3i/test/node1/data0/system/schema_columns-296e9c049bec3085827dc17d3df2122a/system-schema_columns-ka-3-Index.db
>  was not released before the reference was garbage collected
> Unexpected error in node1 log, error: 
> ERROR [Reference-Reaper:1] 2016-08-13 01:34:34,582 Ref.java:199 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@42cb4131) to class 
> org.apache.cassandra.utils.concurrent.WrappedSharedCloseable$1@1544265728:[Memory@[0..4),
>  Memory@[0..a)] was not released before the reference was garbage collected
> Unexpected error in node1 log, error: 
> ERROR [Reference-Reaper:1] 2016-08-13 01:34:34,582 Ref.java:199 - LEAK 
> DETECTED: a reference 
> 

[jira] [Updated] (CASSANDRA-12454) Unable to start on IPv6-only node with local JMX

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12454:

Reviewer: Alex Petrov

> Unable to start on IPv6-only node with local JMX
> 
>
> Key: CASSANDRA-12454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12454
> Project: Cassandra
>  Issue Type: Bug
> Environment: Ubuntu Trusty, Oracle JDK 1.8.0_102-b14, IPv6-only host
>Reporter: Vadim Tsesko
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> A Cassandra node using *default* configuration is unable to start on 
> *IPv6-only* machine with the following error message:
> {code}
> ERROR [main] 2016-08-13 14:38:07,309 CassandraDaemon.java:731 - Bad URL path: 
> :0:0:0:0:0:1/jndi/rmi://0:0:0:0:0:0:0:1:7199/jmxrmi
> {code}
> The problem might be located in {{JMXServerUtils.createJMXServer()}} (I am 
> not sure, because there is no stack trace in {{system.log}}):
> {code:java}
> String urlTemplate = "service:jmx:rmi://%1$s/jndi/rmi://%1$s:%2$d/jmxrmi";
> ...
> String url = String.format(urlTemplate, (serverAddress != null ? 
> serverAddress.getHostAddress() : "0.0.0.0"), port);
> {code}
> IPv6 addresses must be surrounded by square brackets when passed to 
> {{JMXServiceURL}}.
> Disabling {{LOCAL_JMX}} mode in {{cassandra-env.sh}} (and enabling JMX 
> authentication) helps.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12450) CQLSSTableWriter does not allow Update statement

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12450:

Reviewer: Stefania

> CQLSSTableWriter does not allow Update statement
> 
>
> Key: CASSANDRA-12450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12450
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Kuku1
>Assignee: Alex Petrov
>
> CQLSSTableWriter throws Exception when trying to use Update statement.
> Has been working fine in previous versions for me.
> Code:
> {code}
>   public static void main(String[] args) throws IOException {
>   final String KS = "test";
>   final String TABLE = "data";
>   final String schema = "CREATE TABLE " + KS + "." + TABLE
>   + "(k text, c1 text, c2 text, c3 text, v text, 
> primary key(k, c1,c2,c3))";
>   final String query = "UPDATE " + KS + "." + TABLE + " SET v = ? 
> WHERE k = ? and c1 = ? and c2 = ? and c3 = ?";
>   File dataDir = new File(...);
>   CQLSSTableWriter writer = 
> CQLSSTableWriter.builder().inDirectory(dataDir).forTable(schema).using(query).build();
>  //Exception here (see below) 
>   HashMap row = new HashMap<>();
>   row.put("k", "a");
>   row.put("c1", "a");
>   row.put("c2", "a");
>   row.put("c3", "a");
>   row.put("v", "v");
>   writer.addRow(row);
>   writer.close();
>   }
> {code}
> Exception:
> {code}
> 14:51:00.461 [main] INFO  o.a.cassandra.cql3.QueryProcessor - Initialized 
> prepar
> ed statement caches with 0 MB (native) and 0 MB (Thrift)
> Exception in thread "main" java.lang.IllegalArgumentException: Invalid query, 
> mu
> st be a INSERT statement but was: class 
> org.apache.cassandra.cql3.statements.Upd
> ateStatement$ParsedUpdate
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.parseStatement(CQLSS
> TableWriter.java:589)
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter.access$000(CQLSSTabl
> eWriter.java:102)
> at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.using(CQLSST
> ableWriter.java:445)
> at CassandraJsonImporter.main(Cassand
> raJsonImporter.java:66)
> {code}
> I'm currently testing it with 3.7 version, my POM looks like this:
> {code}
> 
> org.apache.cassandra
> cassandra-all
> 3.7
> 
> 
> org.apache.cassandra
> cassandra-clientutil
> 3.7
> 
> 
>   com.datastax.cassandra
>   cassandra-driver-core
>   3.0.0
> 
> {code}
> It has been working with 3.0.8 versions in the POM, but that version is 
> somehow not including the UDT support? 
> I want to use UPDATE instead of INSERT because I need to append data to lists 
> and do not want to overwrite existing data in the lists. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12274) mx4j not work in 3.0.8

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12274:

Reviewer: T Jake Luciani

> mx4j not work in 3.0.8
> --
>
> Key: CASSANDRA-12274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12274
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: suse 12
> java 1.8.0_60
> mx4j 3.0.2
>Reporter: Ilya
>Assignee: Robert Stupp
> Fix For: 3.0.x
>
> Attachments: mx4j-error-log.txt
>
>
> After update from 2.1 to 3.x version mx4j page begin empty
> {code}
> $ curl -i cassandra1:8081
> HTTP/1.0 200 OK
> expires: now
> Server: MX4J-HTTPD/1.0
> Cache-Control: no-cache
> pragma: no-cache
> Content-Type: text/html
> {code}
> There are no errors in the log.
> logs:
> {code}
> ~ $ grep -i mx4j /local/apache-cassandra/logs/system.log | tail -2
> INFO  [main] 2016-07-22 13:48:00,352 CassandraDaemon.java:432 - JVM 
> Arguments: [-Xloggc:/local/apache-cassandra//logs/gc.log, 
> -XX:+UseThreadPriorities, -XX:ThreadPriorityPolicy=42, 
> -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=/local/tmp, -Xss256k, 
> -XX:StringTableSize=103, -XX:+AlwaysPreTouch, -XX:+UseTLAB, 
> -XX:+ResizeTLAB, -XX:+UseNUMA, -Djava.net.preferIPv4Stack=true, -Xms512M, 
> -Xmx1G, -XX:+UseG1GC, -XX:G1RSetUpdatingPauseTimePercent=5, 
> -XX:MaxGCPauseMillis=500, -XX:InitiatingHeapOccupancyPercent=25, 
> -XX:G1HeapRegionSize=32m, -XX:ParallelGCThreads=16, -XX:+PrintGCDetails, 
> -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC, -XX:+PrintTenuringDistribution, 
> -XX:+PrintGCApplicationStoppedTime, -XX:+PrintPromotionFailure, 
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M, 
> -XX:CompileCommandFile=/local/apache-cassandra//conf/hotspot_compiler, 
> -javaagent:/local/apache-cassandra//lib/jamm-0.3.0.jar, 
> -Djava.rmi.server.hostname=cassandra1.d3, 
> -Dcom.sun.management.jmxremote.port=7199, 
> -Dcom.sun.management.jmxremote.rmi.port=7199, 
> -Dcom.sun.management.jmxremote.ssl=false, 
> -Dcom.sun.management.jmxremote.authenticate=false, 
> -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password,
>  -Djava.library.path=/local/apache-cassandra//lib/sigar-bin, -Dmx4jport=8081, 
> -Dlogback.configurationFile=logback.xml, 
> -Dcassandra.logdir=/local/apache-cassandra//logs, 
> -Dcassandra.storagedir=/local/apache-cassandra//data, 
> -Dcassandra-pidfile=/local/apache-cassandra/run/cassandra.pid]
> INFO  [main] 2016-07-22 13:48:04,045 Mx4jTool.java:63 - mx4j successfuly 
> loaded
> {code}
> {code}
> ~ $ sudo lsof -i:8081
> COMMAND   PID  USER   FD   TYPEDEVICE SIZE/OFF NODE NAME
> java14489 cassandra   86u  IPv4 381043582  0t0  TCP 
> cassandra1.d3:sunproxyadmin (LISTEN)
> {code}
> I checked versions 3.0.8  and 3.5, result the same - not work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12014) IndexSummary > 2G causes an assertion error

[Joshua McKenzie (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553070#comment-15553070
 ] 

Joshua McKenzie commented on CASSANDRA-12014:
-

[~jjirsa] - Care to take review on this one?

> IndexSummary > 2G causes an assertion error
> ---
>
> Key: CASSANDRA-12014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12014
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Brandon Williams
>Assignee: Stefania
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> {noformat}
> ERROR [CompactionExecutor:1546280] 2016-06-01 13:21:00,444  
> CassandraDaemon.java:229 - Exception in thread 
> Thread[CompactionExecutor:1546280,1,main]
> java.lang.AssertionError: null
> at 
> org.apache.cassandra.io.sstable.IndexSummaryBuilder.maybeAddEntry(IndexSummaryBuilder.java:171)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.append(SSTableWriter.java:634)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.afterAppend(SSTableWriter.java:179)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:205) 
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:263)
>  ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  ~[na:1.7.0_51]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {noformat}
> I believe this can be fixed by raising the min_index_interval, but we should 
> have a better method of coping with this than throwing the AE.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11803) Creating a materialized view on a table with "token" column breaks the cluster

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-11803:

Reviewer: Alex Petrov

> Creating a materialized view on a table with "token" column breaks the cluster
> --
>
> Key: CASSANDRA-11803
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11803
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: Kernel:
> Linux 4.4.8-20.46.amzn1.x86_64
> Java:
> Java OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassandra: 
> datastax-ddc-3.3.0-1.noarch
> datastax-ddc-tools-3.3.0-1.noarch
>Reporter: Victor Trac
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
>
> On a new Cassandra cluster, if we create a table with a field called "token" 
> (with quotes) and then create a materialized view that uses "token", the 
> cluster breaks. A ServerError is returned, and no further nodetool operations 
> on the sstables work. Restarting the Cassandra server will also fail. It 
> seems like the entire cluster is hosed.
> We tried this on Cassandra 3.3 and 3.5. 
> Here's how to produce (on an new, empty cassandra 3.5 docker container):
> {code}
> [cqlsh 5.0.1 | Cassandra 3.5 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE account WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> CREATE TABLE account.session  (
>...   "token" blob,
>...   account_id uuid,
>...   PRIMARY KEY("token")
>... )WITH compaction={'class': 'LeveledCompactionStrategy'} AND
>...   compression={'sstable_compression': 'LZ4Compressor'};
> cqlsh> CREATE MATERIALIZED VIEW account.account_session AS
>...SELECT account_id,"token" FROM account.session
>...WHERE "token" IS NOT NULL and account_id IS NOT NULL
>...PRIMARY KEY (account_id, "token");
> ServerError:  message="java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable 
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> cqlsh> drop table account.session;
> ServerError:  message="java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
> org.apache.cassandra.exceptions.SyntaxException: line 1:25 no viable 
> alternative at input 'FROM' (SELECT account_id, token [FROM]...)">
> {code}
> When any sstable*, nodetool, or when the Cassandra process is restarted, this 
> is emitted on startup and Cassandra exits (copied from a server w/ data):
> {code}
> INFO  [main] 2016-05-12 23:25:30,074 ColumnFamilyStore.java:395 - 
> Initializing system_schema.indexes
> DEBUG [SSTableBatchOpen:1] 2016-05-12 23:25:30,075 SSTableReader.java:480 - 
> Opening 
> /mnt/cassandra/data/system_schema/indexes-0feb57ac311f382fba6d9024d305702f/ma-4-big
>  (91 bytes)
> ERROR [main] 2016-05-12 23:25:30,143 CassandraDaemon.java:697 - Exception 
> encountered during startup
> org.apache.cassandra.exceptions.SyntaxException: line 1:59 no viable 
> alternative at input 'FROM' (..., expire_at, last_used, token [FROM]...)
> at 
> org.apache.cassandra.cql3.ErrorCollector.throwFirstSyntaxError(ErrorCollector.java:101)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:80)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:512)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchView(SchemaKeyspace.java:1128)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchViews(SchemaKeyspace.java:1092)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:903)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:879)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:867)
>  ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134) 
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:124) 
> ~[apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:229) 
> [apache-cassandra-3.5.0.jar:3.5.0]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
>  

[jira] [Updated] (CASSANDRA-12756) Duplicate (cql)rows for the same primary key

[Andreas Wederbrand (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Wederbrand updated CASSANDRA-12756:
---
Description: 
I observe what looks like duplicates when I run cql queries against a table. It 
only show for rows written during a couple of hours on a specific date but it 
shows for several partions and serveral clustering keys for each partition 
during that time range.

We've loaded data in two ways. 
1) through a normal insert
2) through sstableloader with sstables created using update-statements (to 
append to the map) and an older version of SSTableWriter. During this processes 
several months of data was re-loaded. 

The table DDL is 
{code:title=create statement|borderStyle=solid}
CREATE TABLE climate.climate_1510 (
installation_id bigint,
node_id bigint,
time_bucket int,
gateway_time timestamp,
humidity map,
temperature map,
PRIMARY KEY ((installation_id, node_id, time_bucket), gateway_time)
) WITH CLUSTERING ORDER BY (gateway_time DESC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{code}
and the result from the SELECT is
{code:title=cql output|borderStyle=solid}
> select * from climate.climate_1510 where installation_id = 133235 and node_id 
> = 35453983 and time_bucket = 189 and gateway_time > '2016-08-10 20:00:00' and 
> gateway_time < '2016-08-10 21:00:00' ;

 installation_id | node_id  | time_bucket | gateway_time | humidity 
| temperature
-+--+-+--+--+---
  133235 | 35453983 | 189 | 20160810 20:23:28.00 |  {0: 51} 
| {0: 24.37891}
  133235 | 35453983 | 189 | 20160810 20:23:28.00 |  {0: 51} 
| {0: 24.37891}
  133235 | 35453983 | 189 | 20160810 20:23:28.00 |  {0: 51} 
| {0: 24.37891}
{code}
I've used Andrew Tolbert's sstable-tools to be able to dump the json for this 
specific time and this is what I find. 

{code:title=json dump|borderStyle=solid}
[133235:35453983:189] Row[info=[ts=1470878906618000] ]: gateway_time=2016-08-10 
22:23+0200 | del(humidity)=deletedAt=1470878906617999, 
localDeletion=1470878906, [humidity[0]=51.0 ts=1470878906618000], 
del(temperature)=deletedAt=1470878906617999, localDeletion=1470878906, 
[temperature[0]=24.378906 ts=1470878906618000]
[133235:35453983:189] Row[info=[ts=-9223372036854775808] 
del=deletedAt=1470864506441999, localDeletion=1470864506 ]: 
gateway_time=2016-08-10 22:23+0200 | , [humidity[0]=51.0 ts=1470878906618000], 
, [temperature[0]=24.378906 ts=1470878906618000]
[133235:35453983:189] Row[info=[ts=-9223372036854775808] 
del=deletedAt=1470868106489000, localDeletion=1470868106 ]: 
gateway_time=2016-08-10 22:23+0200 | 
[133235:35453983:189] Row[info=[ts=-9223372036854775808] 
del=deletedAt=1470871706530999, localDeletion=1470871706 ]: 
gateway_time=2016-08-10 22:23+0200 | 
[133235:35453983:189] Row[info=[ts=-9223372036854775808] 
del=deletedAt=1470878906617999, localDeletion=1470878906 ]: 
gateway_time=2016-08-10 22:23+0200 | , [humidity[0]=51.0 ts=1470878906618000], 
, [temperature[0]=24.378906 ts=1470878906618000]
{code}
>From my understanding this should be impossible. Even if we have duplicates in 
>the sstables (which is normal) it should be filtered away before being 
>returned to the client.

I'm happy to add details to this bug if anything is missing.

  was:
I observe what looks like duplicates when I run cql queries against a table. It 
only show for rows written during a couple of hours on a specific date but it 
shows for several partions and serveral clustering keys for each partition 
during that time range.

We've loaded data in two ways. 
1) through a normal insert
2) through sstableloader with sstables created using update-statements (to 
append to the map) and an older version of SSTableWriter. During this processes 
several months of data was re-loaded. 

The table DDL is 
CREATE TABLE climate.climate_1510 (
installation_id bigint,
node_id bigint,
time_bucket int,
gateway_time timestamp,
humidity map,
temperature map,
PRIMARY KEY ((installation_id, node_id, time_bucket), gateway_time)
) WITH CLUSTERING ORDER BY 

[jira] [Created] (CASSANDRA-12756) Duplicate (cql)rows for the same primary key

[Andreas Wederbrand (JIRA)]

Andreas Wederbrand created CASSANDRA-12756:
--

 Summary: Duplicate (cql)rows for the same primary key
 Key: CASSANDRA-12756
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12756
 Project: Cassandra
  Issue Type: Bug
  Components: Compaction, CQL
 Environment: Linux, Cassandra 3.7 (upgraded at one point from 2.?).
Reporter: Andreas Wederbrand
Priority: Minor


I observe what looks like duplicates when I run cql queries against a table. It 
only show for rows written during a couple of hours on a specific date but it 
shows for several partions and serveral clustering keys for each partition 
during that time range.

We've loaded data in two ways. 
1) through a normal insert
2) through sstableloader with sstables created using update-statements (to 
append to the map) and an older version of SSTableWriter. During this processes 
several months of data was re-loaded. 

The table DDL is 
CREATE TABLE climate.climate_1510 (
installation_id bigint,
node_id bigint,
time_bucket int,
gateway_time timestamp,
humidity map,
temperature map,
PRIMARY KEY ((installation_id, node_id, time_bucket), gateway_time)
) WITH CLUSTERING ORDER BY (gateway_time DESC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';

and the result from the SELECT is
> select * from climate.climate_1510 where installation_id = 133235 and node_id 
> = 35453983 and time_bucket = 189 and gateway_time > '2016-08-10 20:00:00' and 
> gateway_time < '2016-08-10 21:00:00' ;

 installation_id | node_id  | time_bucket | gateway_time | humidity 
| temperature
-+--+-+--+--+---
  133235 | 35453983 | 189 | 20160810 20:23:28.00 |  {0: 51} 
| {0: 24.37891}
  133235 | 35453983 | 189 | 20160810 20:23:28.00 |  {0: 51} 
| {0: 24.37891}
  133235 | 35453983 | 189 | 20160810 20:23:28.00 |  {0: 51} 
| {0: 24.37891}

I've used Andrew Tolbert's sstable-tools to be able to dump the json for this 
specific time and this is what I find. 

[133235:35453983:189] Row[info=[ts=1470878906618000] ]: gateway_time=2016-08-10 
22:23+0200 | del(humidity)=deletedAt=1470878906617999, 
localDeletion=1470878906, [humidity[0]=51.0 ts=1470878906618000], 
del(temperature)=deletedAt=1470878906617999, localDeletion=1470878906, 
[temperature[0]=24.378906 ts=1470878906618000]
[133235:35453983:189] Row[info=[ts=-9223372036854775808] 
del=deletedAt=1470864506441999, localDeletion=1470864506 ]: 
gateway_time=2016-08-10 22:23+0200 | , [humidity[0]=51.0 ts=1470878906618000], 
, [temperature[0]=24.378906 ts=1470878906618000]
[133235:35453983:189] Row[info=[ts=-9223372036854775808] 
del=deletedAt=1470868106489000, localDeletion=1470868106 ]: 
gateway_time=2016-08-10 22:23+0200 | 
[133235:35453983:189] Row[info=[ts=-9223372036854775808] 
del=deletedAt=1470871706530999, localDeletion=1470871706 ]: 
gateway_time=2016-08-10 22:23+0200 | 
[133235:35453983:189] Row[info=[ts=-9223372036854775808] 
del=deletedAt=1470878906617999, localDeletion=1470878906 ]: 
gateway_time=2016-08-10 22:23+0200 | , [humidity[0]=51.0 ts=1470878906618000], 
, [temperature[0]=24.378906 ts=1470878906618000]

>From my understanding this should be impossible. Even if we have duplicates in 
>the sstables (which is normal) it should be filtered away before being 
>returned to the client.

I'm happy to add details to this bug if anything is missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11873) Add duration type

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552969#comment-15552969
 ] 

Benjamin Lerer commented on CASSANDRA-11873:


bq. Perhaps we should just specify that duration types are sorted by their 
binary representation and not try to restrict them from being used anywhere 
that could result in an ordering?

In my opinion having some checks will be probably less confusing for the user. 
With the current binary representation used for duration, the order will be 
completely random.

I have pushed some new branches for 3.X and trunk with some fixes for all the 
problems that you raised.

||Branch||utests||dtests||
|[3.X|https://github.com/blerer/cassandra/tree/11873-3.X]|[3.X|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-11873-3.X-testall/]|[3.X|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-11873-3.X-dtest/]|
|[trunk|https://github.com/blerer/cassandra/tree/11873-trunk]|[trunk|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-11873-trunk-testall/]|[trunk|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-11873-trunk-dtest/]|

bq. We will also need to add "duration" to the python driver's reserved 
keywords in {{cassandra/metadata.py}}.

I did not tackle that part but I thought that there will be more work to do on 
the python driver side.

> Add duration type
> -
>
> Key: CASSANDRA-11873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11873
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>  Labels: client-impacting, doc-impacting
> Fix For: 3.x
>
>
> For CASSANDRA-11871 or to allow queries with {{WHERE}} clause like:
> {{... WHERE reading_time < now() - 2h}}, we need to support some duration 
> type.
> In my opinion, it should be represented internally as a number of 
> microseconds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12755) Ability to control whether or not to wait on trace events being written before responding to client at request level

[Andy Tolbert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Tolbert updated CASSANDRA-12755:
-
Summary: Ability to control whether or not to wait on trace events being 
written before responding to client at request level  (was: Ability to control 
whether or not to wait on trace events being written before responding to 
client)

> Ability to control whether or not to wait on trace events being written 
> before responding to client at request level
> 
>
> Key: CASSANDRA-12755
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12755
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Andy Tolbert
>Priority: Minor
>
> [CASSANDRA-11465] introduces a new system property 
> {{cassandra.wait_for_tracing_events_timeout_secs}} that controls whether or 
> not C* waits for events to be written before responding to client. 
> Instead it would be great if this could be configured on a per request basis 
> (which would require a new flag at frame level or something else in protocol) 
> and also as an option on the {{settraceprobability}} command.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12755) Ability to control whether or not to wait on trace events being written before responding to client

[Andy Tolbert (JIRA)]

Andy Tolbert created CASSANDRA-12755:


 Summary: Ability to control whether or not to wait on trace events 
being written before responding to client
 Key: CASSANDRA-12755
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12755
 Project: Cassandra
  Issue Type: Improvement
Reporter: Andy Tolbert
Priority: Minor


[CASSANDRA-11465] introduces a new system property 
{{cassandra.wait_for_tracing_events_timeout_secs}} that controls whether or not 
C* waits for events to be written before responding to client. 

Instead it would be great if this could be configured on a per request basis 
(which would require a new flag at frame level or something else in protocol) 
and also as an option on the {{settraceprobability}} command.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12754) Change cassandra.wait_for_tracing_events_timeout_secs default to -1 so C* doesn't wait on trace events to be written before responding to request by default

[Andy Tolbert (JIRA)]

Andy Tolbert created CASSANDRA-12754:


 Summary: Change cassandra.wait_for_tracing_events_timeout_secs 
default to -1 so C* doesn't wait on trace events to be written before 
responding to request by default
 Key: CASSANDRA-12754
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12754
 Project: Cassandra
  Issue Type: Bug
Reporter: Andy Tolbert


[CASSANDRA-11465] introduces a new system property 
{{cassandra.wait_for_tracing_events_timeout_secs}} that controls whether or not 
C* waits for events to be written before responding to client.   The current 
default behavior is to wait up to 1 second and then respond and timeout.  

If using probabilistic tracing this can cause queries to be randomly delayed up 
to 1 second.

Changing the default to -1 (disabled and enabling it explicitly in 
{{cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test}}.

Ideally it would be nice to be able to control this behavior on a per request 
basis (which would require native protocol changes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12268) Make MV Index creation robust for wide referent rows

[Carl Yeksigian (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carl Yeksigian updated CASSANDRA-12268:
---
Status: Patch Available  (was: Open)

Those test failures were most likely due to the sizing of the nodes running 
this test.

I've also rebased in order to clean up the runs.

||3.0|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12268-3.0]|[utest|http://cassci.datastax.com/job/carlyeks-ticket-12268-3.0-testall/]|[dtest|http://cassci.datastax.com/job/carlyeks-ticket-12268-3.0-dtest/]|
||3.x|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12268-3.x]|[utest|http://cassci.datastax.com/job/carlyeks-ticket-12268-3.x-testall/]|[dtest|http://cassci.datastax.com/job/carlyeks-ticket-12268-3.x-dtest/]|
||trunk|[branch|https://github.com/carlyeks/cassandra/tree/ticket/12268]|[utest|http://cassci.datastax.com/job/carlyeks-ticket-12268-testall/]|[dtest|http://cassci.datastax.com/job/carlyeks-ticket-12268-dtest/]|

> Make MV Index creation robust for wide referent rows
> 
>
> Key: CASSANDRA-12268
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12268
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jonathan Shook
>Assignee: Carl Yeksigian
> Fix For: 3.0.x, 3.x
>
> Attachments: 12268.py
>
>
> When creating an index for a materialized view for extant data, heap pressure 
> is very dependent on the cardinality of of rows associated with each index 
> value. With the way that per-index value rows are created within the index, 
> this can cause unbounded heap pressure, which can cause OOM. This appears to 
> be a side-effect of how each index row is applied atomically as with batches.
> The commit logs can accumulate enough during the process to prevent the node 
> from being restarted. Given that this occurs during global index creation, 
> this can happen on multiple nodes, making stable recovery of a node set 
> difficult, as co-replicas become unavailable to assist in back-filling data 
> from commitlogs.
> While it is understandable that you want to avoid having relatively wide rows 
>  even in materialized views, this represents a particularly difficult 
> scenario for triage.
> The basic recommendation for improving this is to sub-group the index 
> creation into smaller chunks internally, providing a maximal bound against 
> the heap pressure when it is needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6719) redesign loadnewsstables

[Romain Hardouin (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552445#comment-15552445
 ] 

Romain Hardouin commented on CASSANDRA-6719:


Well, thanks to CASSANDRA-6514 I guess that my comment is not relevant

> redesign loadnewsstables
> 
>
> Key: CASSANDRA-6719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6719
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Jonathan Ellis
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 6719.patch
>
>
> CFSMBean.loadNewSSTables scans data directories for new sstables dropped 
> there by an external agent.  This is dangerous because of possible filename 
> conflicts with existing or newly generated sstables.
> Instead, we should support leaving the new sstables in a separate directory 
> (specified by a parameter, or configured as a new location in yaml) and take 
> care of renaming as necessary automagically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-6719) redesign loadnewsstables

[Romain Hardouin (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552432#comment-15552432
 ] 

Romain Hardouin commented on CASSANDRA-6719:


What about to make the directory with nodetool an argument instead of an 
option? 

{{nodetool refresh}} would throw an error because it's no longer supported - we 
can loose data, the user must be aware of that.
If a user really wants the old behavior we could use an `unsafe` option:
{{nodetool refresh --unsafe}}




> redesign loadnewsstables
> 
>
> Key: CASSANDRA-6719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6719
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Jonathan Ellis
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 6719.patch
>
>
> CFSMBean.loadNewSSTables scans data directories for new sstables dropped 
> there by an external agent.  This is dangerous because of possible filename 
> conflicts with existing or newly generated sstables.
> Instead, we should support leaving the new sstables in a separate directory 
> (specified by a parameter, or configured as a new location in yaml) and take 
> care of renaming as necessary automagically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11107) Add native_transport_address and native_transport_broadcast_address yaml options

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-11107:

Reproduced In: 3.0.2, 2.2.4  (was: 2.2.4, 3.0.2)
 Reviewer: Sam Tunnicliffe

> Add native_transport_address and native_transport_broadcast_address yaml 
> options
> 
>
> Key: CASSANDRA-11107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11107
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: n0rad
>Assignee: Joel Knighton
>Priority: Minor
>
> I'm starting cassandra on a container with this /etc/hosts
> {quote}
> 127.0.0.1rkt-235c219a-f0dc-4958-9e03-5afe2581bbe1 localhost
> ::1  rkt-235c219a-f0dc-4958-9e03-5afe2581bbe1 localhost
> {quote}
> I have the default configuration except :
> {quote}
>  - seeds: "10.1.1.1"
> listen_address : 10.1.1.1
> {quote}
> cassandra will start listening on *127.0.0.1:9042*
> if I set *rpc_address:10.1.1.1* , even if *start_rpc: false*, cassandra will 
> listen on 10.1.1.1
> Since rpc is not started, I assumed that *rpc_address* and 
> *broadcast_rpc_address* will be ignored
> It took me a while to figure that. There may be something to do around this



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11107) Add native_transport_address and native_transport_broadcast_address yaml options

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-11107:

Assignee: Joel Knighton

> Add native_transport_address and native_transport_broadcast_address yaml 
> options
> 
>
> Key: CASSANDRA-11107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11107
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: n0rad
>Assignee: Joel Knighton
>Priority: Minor
>
> I'm starting cassandra on a container with this /etc/hosts
> {quote}
> 127.0.0.1rkt-235c219a-f0dc-4958-9e03-5afe2581bbe1 localhost
> ::1  rkt-235c219a-f0dc-4958-9e03-5afe2581bbe1 localhost
> {quote}
> I have the default configuration except :
> {quote}
>  - seeds: "10.1.1.1"
> listen_address : 10.1.1.1
> {quote}
> cassandra will start listening on *127.0.0.1:9042*
> if I set *rpc_address:10.1.1.1* , even if *start_rpc: false*, cassandra will 
> listen on 10.1.1.1
> Since rpc is not started, I assumed that *rpc_address* and 
> *broadcast_rpc_address* will be ignored
> It took me a while to figure that. There may be something to do around this



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12373) 3.0 breaks CQL compatibility with super columns families

[Joshua McKenzie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joshua McKenzie updated CASSANDRA-12373:

Reviewer: Aleksey Yeschenko

> 3.0 breaks CQL compatibility with super columns families
> 
>
> Key: CASSANDRA-12373
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12373
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
> Fix For: 3.0.x, 3.x
>
>
> This is a follow-up to CASSANDRA-12335 to fix the CQL side of super column 
> compatibility.
> The details and a proposed solution can be found in the comments of 
> CASSANDRA-12335 but the crux of the issue is that super column famillies show 
> up differently in CQL in 3.0.x/3.x compared to 2.x, hence breaking backward 
> compatibilty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12698) add json/yaml format option to nodetool status

[Anonymous (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anonymous updated CASSANDRA-12698:
--
Status: Ready to Commit  (was: Patch Available)

> add json/yaml format option to nodetool status
> --
>
> Key: CASSANDRA-12698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12698
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Shogo Hoshii
>Assignee: Shogo Hoshii
> Attachments: ntstatus_json.patch, sample.json, sample.yaml
>
>
> Hello,
> This patch enables nodetool status to be output in json/yaml format.
> I think this format could be useful interface for tools that operate or 
> deploy cassandra.
> The format could free tools from parsing the result in their own way.
> It would be great if someone would review this patch.
> Thank you.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12598) BailErrorStragery alike for ANTLR grammar parsing

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552096#comment-15552096
 ] 

Benjamin Lerer commented on CASSANDRA-12598:


ANTLR 3.5.2 perform recovery at 2 places: in 
[BaseRecognizer::recoverFromMismatchedToken|https://github.com/antlr/antlr3/blob/master/runtime/Java/src/main/java/org/antlr/runtime/BaseRecognizer.java#L588]
 and 
in 
[BaseRecognizer::recover|https://github.com/antlr/antlr3/blob/master/runtime/Java/src/main/java/org/antlr/runtime/BaseRecognizer.java#L353].
 
[BaseRecognizer::recoverFromMismatchedSet|https://github.com/antlr/antlr3/blob/master/runtime/Java/src/main/java/org/antlr/runtime/BaseRecognizer.java#L621]
 is not used anymore.

In case of mismatch, {{BaseRecognizer::recoverFromMismatchedToken}} will attend 
to recover by either deleting the unexpected token or inserting the missing 
one, reporting an error in both cases.
If those 2 technics do not work it will throw a {{MismatchedTokenException}}. 
That Exception will be catch by the default code that ANTLR generates at the 
end of each rule’s method:
{code}
catch (RecognitionException re) {
reportError(re);
recover(input,re);
}
{code}

By consequence, the right way to disable recovery is to override 
{{BaseRecognizer::recoverFromMismatchedToken}} to make it always throw a 
{{MismatchedTokenException}} and
to either override the catch code generated by ANTLR using the {{rulecatch}} 
action or simply override {{BaseRecognizer::recover}} to make it does nothing.
As you seems to be in favor of the bulletproof approach, overriding 
{{BaseRecognizer::recover}} sound like the best option.

The final version of my experimentations is:
|[trunk|https://github.com/blerer/cassandra/tree/12598-trunk]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-12598-trunk-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-12598-trunk-dtest/lastCompletedBuild/]|

While trying the different approaches, I realized that several rules have not 
been written correctly and were preventing the generated code to compile 
depending on how the {{rulecatch}} action was used. So, I fixed those rules in 
the provided patch.

[~Bereng] Could you have a look at the patch and tell me if it looks fine to 
you?

> BailErrorStragery alike for ANTLR grammar parsing
> -
>
> Key: CASSANDRA-12598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12598
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
> Fix For: 3.x
>
>
> CQL parsing is missing a mechanism similar to 
> http://www.antlr.org/api/Java/org/antlr/v4/runtime/BailErrorStrategy.html
> This solves:
> - Stopping parsing instead of continuing when we've got already an error 
> which is wasteful.
> - Any skipped java code tied to 'recovered' missing tokens might later cause 
> java exceptions (think non-init variables, non incremented integers (div by 
> zero), etc.) which will bubble up directly and will hide properly formatted 
> error messages to the user with no indication on what went wrong at all. Just 
> a cryptic NPE i.e



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12666) dtest failure in paging_test.TestPagingData.test_paging_with_filtering_on_partition_key

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552104#comment-15552104
 ] 

Alex Petrov commented on CASSANDRA-12666:
-

You're right, same exact result can be achieved by just short-circuiting the 
filtering part. I've changed this part. 

Problem with filtering on of the partition key is that we have to hit all 
replicas in order to satisfy the slice, which is not the case with tokens. In 
fact, both {{... WHERE pk < 5 AND reg = 2}} and {{... WHERE reg = 2}} will be 
fetching same amount of data and filtering it afterwards. 

We can't get same problem with restrictions on token as a different code path 
is used for [key 
bounds|https://github.com/apache/cassandra/blob/3f49c328f202e68b67a9caaa63522e333ea5006f/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java#L678]
 and for [concrete 
bound|https://github.com/apache/cassandra/blob/3f49c328f202e68b67a9caaa63522e333ea5006f/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java#L708].
 

I've rebased trunk and 3.x and re-triggered CI: 

|[trunk|https://github.com/ifesdjeen/cassandra/tree/12666-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12666-trunk-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12666-trunk-dtest/]|
|[3.X|https://github.com/ifesdjeen/cassandra/tree/12666-3.X]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12666-3.X-testall/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12666-3.X-dtest/]|

(3.0 is unaffected since it doesn't have PK filtering patch)

> dtest failure in 
> paging_test.TestPagingData.test_paging_with_filtering_on_partition_key
> ---
>
> Key: CASSANDRA-12666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12666
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/480/testReport/paging_test/TestPagingData/test_paging_with_filtering_on_partition_key
> {code}
> Standard Output
> Unexpected error in node3 log, error: 
> ERROR [Native-Transport-Requests-3] 2016-09-17 00:50:11,543 Message.java:622 
> - Unexpected exception during request; channel = [id: 0x467a4afe, 
> L:/127.0.0.3:9042 - R:/127.0.0.1:59115]
> java.lang.AssertionError: null
>   at 
> org.apache.cassandra.dht.IncludingExcludingBounds.split(IncludingExcludingBounds.java:45)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy.getRestrictedRanges(StorageProxy.java:2368)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$RangeIterator.(StorageProxy.java:1951)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:2235)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.PartitionRangeReadCommand.execute(PartitionRangeReadCommand.java:184)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:66)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.pager.PartitionRangeQueryPager.fetchPage(PartitionRangeQueryPager.java:36)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:328)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:375)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:78)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247) 
> ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:232) 
> ~[main/:na]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:516)
>  [main/:na]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:409)
>  [main/:na]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> 

[jira] [Commented] (CASSANDRA-12598) BailErrorStragery alike for ANTLR grammar parsing

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552095#comment-15552095
 ] 

Benjamin Lerer commented on CASSANDRA-12598:


ANTLR 3.5.2 perform recovery at 2 places: in 
[BaseRecognizer::recoverFromMismatchedToken|https://github.com/antlr/antlr3/blob/master/runtime/Java/src/main/java/org/antlr/runtime/BaseRecognizer.java#L588]
 and 
in 
[BaseRecognizer::recover|https://github.com/antlr/antlr3/blob/master/runtime/Java/src/main/java/org/antlr/runtime/BaseRecognizer.java#L353].
 
[BaseRecognizer::recoverFromMismatchedSet|https://github.com/antlr/antlr3/blob/master/runtime/Java/src/main/java/org/antlr/runtime/BaseRecognizer.java#L621]
 is not used anymore.

In case of mismatch, {{BaseRecognizer::recoverFromMismatchedToken}} will attend 
to recover by either deleting the unexpected token or inserting the missing 
one, reporting an error in both cases.
If those 2 technics do not work it will throw a {{MismatchedTokenException}}. 
That Exception will be catch by the default code that ANTLR generates at the 
end of each rule’s method:
{code}
catch (RecognitionException re) {
reportError(re);
recover(input,re);
}
{code}

By consequence, the right way to disable recovery is to override 
{{BaseRecognizer::recoverFromMismatchedToken}} to make it always throw a 
{{MismatchedTokenException}} and
to either override the catch code generated by ANTLR using the {{rulecatch}} 
action or simply override {{BaseRecognizer::recover}} to make it does nothing.
As you seems to be in favor of the bulletproof approach, overriding 
{{BaseRecognizer::recover}} sound like the best option.

The final version of my experimentations is:
|[trunk|https://github.com/blerer/cassandra/tree/12598-trunk]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-12598-trunk-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-12598-trunk-dtest/lastCompletedBuild/]|

While trying the different approaches, I realized that several rules have not 
been written correctly and were preventing the generated code to compile 
depending on how the {{rulecatch}} action was used. So, I fixed those rules in 
the provided patch.

[~Bereng] Could you have a look at the patch and tell me if it looks fine to 
you?

> BailErrorStragery alike for ANTLR grammar parsing
> -
>
> Key: CASSANDRA-12598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12598
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
> Fix For: 3.x
>
>
> CQL parsing is missing a mechanism similar to 
> http://www.antlr.org/api/Java/org/antlr/v4/runtime/BailErrorStrategy.html
> This solves:
> - Stopping parsing instead of continuing when we've got already an error 
> which is wasteful.
> - Any skipped java code tied to 'recovered' missing tokens might later cause 
> java exceptions (think non-init variables, non incremented integers (div by 
> zero), etc.) which will bubble up directly and will hide properly formatted 
> error messages to the user with no indication on what went wrong at all. Just 
> a cryptic NPE i.e



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-9524) ColumnFamilyStoreTest.testSliceByNamesCommandOldMetadata failed in 2.2

[Joel Knighton (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Knighton resolved CASSANDRA-9524.
--
Resolution: Duplicate

> ColumnFamilyStoreTest.testSliceByNamesCommandOldMetadata failed in 2.2
> --
>
> Key: CASSANDRA-9524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9524
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Michael Shuler
>  Labels: test-failure
> Fix For: 2.2.x
>
>
> {noformat}
> junit.framework.AssertionFailedError
>   at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:171)
>   at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:166)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableWriter.rename(SSTableWriter.java:266)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.loadNewSSTables(ColumnFamilyStore.java:766)
>   at 
> org.apache.cassandra.db.ColumnFamilyStoreTest.testSliceByNamesCommandOldMetadata(ColumnFamilyStoreTest.java:1125)
> {noformat}
> http://cassci.datastax.com/job/cassandra-2.2_utest/56/testReport/org.apache.cassandra.db/ColumnFamilyStoreTest/testSliceByNamesCommandOldMetadata/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12751) pip install cassandra-driver

[Eric Pedregosa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Pedregosa updated CASSANDRA-12751:
---
Component/s: (was: Configuration)

> pip install cassandra-driver
> 
>
> Key: CASSANDRA-12751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12751
> Project: Cassandra
>  Issue Type: Task
> Environment: DSE 3.0
> RHEL 6.0
>Reporter: Eric Pedregosa
>Priority: Critical
>
> Hi,
> Just want to understand what this error mean.  I just installed Python 2.7 
> from 2.6.  Also, installed DSE 5.0 from 4.9.   
> Also, DSE 5.0 requires Python 2.7 but upon installing Python 2.7 the 2.6 
> remains. I learned that we cannot remove 2.6 from the system otherwise it may 
> cause problem.  Python 2.6 shell will be remain to be executed as 'python'.  
> How will DSE 5.0 associate with Python 2.7 instead of 2.6?
> [root@ushapls00056la ~]# pip install cassandra-driver
> Collecting cassandra-driver
>   Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=3, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=2, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=1, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=3, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=2, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=1, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Could not find a version that satisfies the requirement cassandra-driver 
> (from versions: )
> No matching distribution found for cassandra-driver
> [root@ushapls00056la ~]# cqlsh 100.114.116.104
> No appropriate python interpreter found.
> Thanks.
> Eric



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-12753) Create MV can corrupt C*, blocking all further table actions and startup

[Carl Yeksigian (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carl Yeksigian resolved CASSANDRA-12753.

Resolution: Duplicate

This is the same issue as in CASSANDRA-11803, with a different reserved word.

If you have a chance, can you try applying that patch and seeing if it fixes 
the issue?

> Create MV can corrupt C*, blocking all further table actions and startup
> 
>
> Key: CASSANDRA-12753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12753
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL6.5
> Cas 3.0.9
>Reporter: Hazel Bobrins
>Priority: Critical
> Attachments: Cass_start.txt, MV_Create.txt, table_drop.txt
>
>
> Creating a MV with a protected field name e.g. 'set' results in an error. 
> Post this failed MV create all further actions in the keyspace fail and node 
> startup fails until the keyspace is dropped.
> Tested on a fresh 3.0.9 install single node cluster.
> How to reproduce
> cassandra@cqlsh:test1> CREATE KEYSPACE test1 WITH replication = {'class': 
> 'SimpleStrategy', 'replication_factor': 1 } AND durable_writes = 'true';
> cassandra@cqlsh:test1> use test1 ;
> cassandra@cqlsh:test1> CREATE TABLE main_table ( field1 text, field2 text, 
> "set" text, PRIMARY KEY ( field1, field2 ) );
> cassandra@cqlsh:test1> CREATE MATERIALIZED VIEW mv1 AS SELECT field2, field1, 
> "set" FROM main_table WHERE field1 IS NOT NULL AND field2 IS NOT NULL PRIMARY 
> KEY ( field2, field1 ) ;
> ServerError: java.lang.RuntimeException: 
> java.util.concurrent.ExecutionException: 
> org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable 
> alternative at input 'set' (SELECT field1, field2, [set]...)
> ## Attached stack traces - 'MV_Create' thrown at this point
> cassandra@cqlsh:test1> drop TABLE main_table ;
> ServerError: java.lang.RuntimeException: 
> java.util.concurrent.ExecutionException: 
> org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable 
> alternative at input 'set' (SELECT field1, field2, [set]...)
> ## Attached stacke traces - 'Table_drop' thrown at this point
> Finally restart Cassandra. Attached stack 'Cass_start' thrown at this point 
> and C* does not start.
> Dropping the keyspace does work, however, this must obviously be done before 
> stopping the node.
> We have also tested this on a 4 node cluster, post the MV create all nodes 
> report the same issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-12751) pip install cassandra-driver

[Carl Yeksigian (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carl Yeksigian resolved CASSANDRA-12751.

Resolution: Invalid

This Jira is for core Cassandra development.

You should ask your question to the python driver group instead: 
https://github.com/datastax/python-driver#getting-help

> pip install cassandra-driver
> 
>
> Key: CASSANDRA-12751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12751
> Project: Cassandra
>  Issue Type: Task
>  Components: Configuration
> Environment: DSE 3.0
> RHEL 6.0
>Reporter: Eric Pedregosa
>Priority: Critical
>
> Hi,
> Just want to understand what this error mean.  I just installed Python 2.7 
> from 2.6.  Also, installed DSE 5.0 from 4.9.   
> Also, DSE 5.0 requires Python 2.7 but upon installing Python 2.7 the 2.6 
> remains. I learned that we cannot remove 2.6 from the system otherwise it may 
> cause problem.  Python 2.6 shell will be remain to be executed as 'python'.  
> How will DSE 5.0 associate with Python 2.7 instead of 2.6?
> [root@ushapls00056la ~]# pip install cassandra-driver
> Collecting cassandra-driver
>   Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=3, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=2, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=1, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=3, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=2, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=1, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after 
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-5, 'No 
> address associated with hostname'))': /simple/cassandra-driver/
>   Could not find a version that satisfies the requirement cassandra-driver 
> (from versions: )
> No matching distribution found for cassandra-driver
> [root@ushapls00056la ~]# cqlsh 100.114.116.104
> No appropriate python interpreter found.
> Thanks.
> Eric



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CASSANDRA-12606) CQLSSTableWriter unable to use blob conversion functions

[Alex Petrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov reassigned CASSANDRA-12606:
---

Assignee: Alex Petrov

> CQLSSTableWriter unable to use blob conversion functions
> 
>
> Key: CASSANDRA-12606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12606
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Tools
>Reporter: Mark Reddy
>Assignee: Alex Petrov
>Priority: Minor
>
> Attempting to use blob conversion functions e.g. textAsBlob, from 3.0 - 3.7 
> results in:
> {noformat}
> Exception in thread "main" 
> org.apache.cassandra.exceptions.InvalidRequestException: Unknown function 
> textasblob called
>   at 
> org.apache.cassandra.cql3.functions.FunctionCall$Raw.prepare(FunctionCall.java:136)
>   at 
> org.apache.cassandra.cql3.Operation$SetValue.prepare(Operation.java:163)
>   at 
> org.apache.cassandra.cql3.statements.UpdateStatement$ParsedInsert.prepareInternal(UpdateStatement.java:173)
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:785)
>   at 
> org.apache.cassandra.cql3.statements.ModificationStatement$Parsed.prepare(ModificationStatement.java:771)
>   at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.prepareInsert(CQLSSTableWriter.java:567)
>   at 
> org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.build(CQLSSTableWriter.java:510)
> {noformat}
> The following snippet will reproduce the issue
> {code}
> String table = String.format("%s.%s", "test_ks", "test_table");
> String schema = String.format("CREATE TABLE %s (test_text text, test_blob 
> blob, PRIMARY KEY(test_text));", table);
> String insertStatement = String.format("INSERT INTO %s (test_text, test_blob) 
> VALUES (?, textAsBlob(?))", table);
> File tempDir = Files.createTempDirectory("tempDir").toFile();
> CQLSSTableWriter sstableWriter = CQLSSTableWriter.builder()
> .forTable(schema)
> .using(insertStatement)
> .inDirectory(tempDir)
> .build();
> {code}
> This is caused in FunctionResolver.get(...) when 
> candidates.addAll(Schema.instance.getFunctions(name.asNativeFunction())); is 
> called, as there is no system keyspace initialised.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-12666) dtest failure in paging_test.TestPagingData.test_paging_with_filtering_on_partition_key

[Branimir Lambov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551684#comment-15551684
 ] 

Branimir Lambov edited comment on CASSANDRA-12666 at 10/6/16 11:35 AM:
---

It is quite hard to understand how this patch helps, as the need for a change 
to inclusiveness appears very arbitrary and unrelated. I would be more explicit 
-- do the {{if needsFiltering}} check as a first line in the method, and 
immediately return an explicitly constructed full {{Range}}.

Could we get the same problem with restrictions on token?


was (Author: blambov):
It is quite hard to understand how this patch helps, as the need for a change 
to inclusiveness appears very arbitrary and unrelated. I would be more explicit 
-- do the {{if needsFiltering}} check as a first line in the file, and 
immediately return an explicitly constructed full {{Range}}.

Could we get the same problem with restrictions on token?

> dtest failure in 
> paging_test.TestPagingData.test_paging_with_filtering_on_partition_key
> ---
>
> Key: CASSANDRA-12666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12666
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/480/testReport/paging_test/TestPagingData/test_paging_with_filtering_on_partition_key
> {code}
> Standard Output
> Unexpected error in node3 log, error: 
> ERROR [Native-Transport-Requests-3] 2016-09-17 00:50:11,543 Message.java:622 
> - Unexpected exception during request; channel = [id: 0x467a4afe, 
> L:/127.0.0.3:9042 - R:/127.0.0.1:59115]
> java.lang.AssertionError: null
>   at 
> org.apache.cassandra.dht.IncludingExcludingBounds.split(IncludingExcludingBounds.java:45)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy.getRestrictedRanges(StorageProxy.java:2368)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$RangeIterator.(StorageProxy.java:1951)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:2235)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.PartitionRangeReadCommand.execute(PartitionRangeReadCommand.java:184)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:66)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.pager.PartitionRangeQueryPager.fetchPage(PartitionRangeQueryPager.java:36)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:328)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:375)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:78)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247) 
> ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:232) 
> ~[main/:na]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:516)
>  [main/:na]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:409)
>  [main/:na]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [main/:na]
>   at 

[jira] [Commented] (CASSANDRA-12666) dtest failure in paging_test.TestPagingData.test_paging_with_filtering_on_partition_key

[Branimir Lambov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551684#comment-15551684
 ] 

Branimir Lambov commented on CASSANDRA-12666:
-

It is quite hard to understand how this patch helps, as the need for a change 
to inclusiveness appears very arbitrary and unrelated. I would be more explicit 
-- do the {{if needsFiltering}} check as a first line in the file, and 
immediately return an explicitly constructed full {{Range}}.

Could we get the same problem with restrictions on token?

> dtest failure in 
> paging_test.TestPagingData.test_paging_with_filtering_on_partition_key
> ---
>
> Key: CASSANDRA-12666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12666
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/480/testReport/paging_test/TestPagingData/test_paging_with_filtering_on_partition_key
> {code}
> Standard Output
> Unexpected error in node3 log, error: 
> ERROR [Native-Transport-Requests-3] 2016-09-17 00:50:11,543 Message.java:622 
> - Unexpected exception during request; channel = [id: 0x467a4afe, 
> L:/127.0.0.3:9042 - R:/127.0.0.1:59115]
> java.lang.AssertionError: null
>   at 
> org.apache.cassandra.dht.IncludingExcludingBounds.split(IncludingExcludingBounds.java:45)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy.getRestrictedRanges(StorageProxy.java:2368)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy$RangeIterator.(StorageProxy.java:1951)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:2235)
>  ~[main/:na]
>   at 
> org.apache.cassandra.db.PartitionRangeReadCommand.execute(PartitionRangeReadCommand.java:184)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:66)
>  ~[main/:na]
>   at 
> org.apache.cassandra.service.pager.PartitionRangeQueryPager.fetchPage(PartitionRangeQueryPager.java:36)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:328)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:375)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:78)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:216)
>  ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247) 
> ~[main/:na]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:232) 
> ~[main/:na]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:516)
>  [main/:na]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:409)
>  [main/:na]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {code}
> Related failures:
> http://cassci.datastax.com/job/trunk_novnode_dtest/480/testReport/paging_test/TestPagingData/test_paging_with_filtering_on_partition_key_on_clustering_columns/
> 

[jira] [Updated] (CASSANDRA-12694) PAXOS Update Corrupted empty row exception

[Stefania (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefania updated CASSANDRA-12694:
-
Reviewer: Sylvain Lebresne  (was: Stefania)

> PAXOS Update Corrupted empty row exception
> --
>
> Key: CASSANDRA-12694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12694
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: 3 node cluster using RF=3 running on cassandra 3.7
>Reporter: Cameron Zemek
>Assignee: Alex Petrov
>
> {noformat}
> cqlsh> create table test.test (test_id TEXT, last_updated TIMESTAMP, 
> message_id TEXT, PRIMARY KEY(test_id));
> update test.test set last_updated = 1474494363669 where test_id = 'test1' if 
> message_id = null;
> {noformat}
> Then nodetool flush on the all 3 nodes.
> {noformat}
> cqlsh> update test.test set last_updated = 1474494363669 where test_id = 
> 'test1' if message_id = null;
> ServerError: 
> {noformat}
> From cassandra log
> {noformat}
> ERROR [SharedPool-Worker-1] 2016-09-23 12:09:13,179 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7a22599e, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:58297]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[main/:na]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:125)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:249)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:87) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse$DataResponse.digest(ReadResponse.java:192)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:80) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:139) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1714)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1663) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1604) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1523) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1497) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1491) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:208)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:239) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:224) 
> ~[main/:na]
> at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
>  [main/:na]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
>  [main/:na]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-12753) Create MV can corrupt C*, blocking all further table actions and startup

[Hazel Bobrins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hazel Bobrins updated CASSANDRA-12753:
--
Description: 
Creating a MV with a protected field name e.g. 'set' results in an error. Post 
this failed MV create all further actions in the keyspace fail and node startup 
fails until the keyspace is dropped.

Tested on a fresh 3.0.9 install single node cluster.

How to reproduce

cassandra@cqlsh:test1> CREATE KEYSPACE test1 WITH replication = {'class': 
'SimpleStrategy', 'replication_factor': 1 } AND durable_writes = 'true';
cassandra@cqlsh:test1> use test1 ;
cassandra@cqlsh:test1> CREATE TABLE main_table ( field1 text, field2 text, 
"set" text, PRIMARY KEY ( field1, field2 ) );
cassandra@cqlsh:test1> CREATE MATERIALIZED VIEW mv1 AS SELECT field2, field1, 
"set" FROM main_table WHERE field1 IS NOT NULL AND field2 IS NOT NULL PRIMARY 
KEY ( field2, field1 ) ;
ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable 
alternative at input 'set' (SELECT field1, field2, [set]...)

## Attached stack traces - 'MV_Create' thrown at this point

cassandra@cqlsh:test1> drop TABLE main_table ;
ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable 
alternative at input 'set' (SELECT field1, field2, [set]...)

## Attached stacke traces - 'Table_drop' thrown at this point


Finally restart Cassandra. Attached stack 'Cass_start' thrown at this point and 
C* does not start.

Dropping the keyspace does work, however, this must obviously be done before 
stopping the node.

We have also tested this on a 4 node cluster, post the MV create all nodes 
report the same issue.

  was:
Creating a MV with a protected field name e.g. 'set' results in an error. Post 
this failed MV create all further actions in the keyspace fail and node startup 
fails until the keyspace is dropped.

Tested on a fresh 3.0.9 install single node cluster.

How to reproduce

cassandra@cqlsh:test1> CREATE KEYSPACE test1 WITH replication = {'class': 
'SimpleStrategy', 'replication_factor': 1 } AND durable_writes = 'true';
cassandra@cqlsh:test1> use test1 ;
cassandra@cqlsh:test1> CREATE TABLE main_table ( field1 text, field2 text, 
"set" text, PRIMARY KEY ( field1, field2 ) );
cassandra@cqlsh:test1> CREATE MATERIALIZED VIEW mv1 AS SELECT field2, field1, 
"set" FROM main_table WHERE field1 IS NOT NULL AND field2 IS NOT NULL PRIMARY 
KEY ( field2, field1 ) ;
ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable 
alternative at input 'set' (SELECT field1, field2, [set]...)

## Attached stack traces - 'MV_Create' thrown at this point

cassandra@cqlsh:test1> drop TABLE main_table ;
ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable 
alternative at input 'set' (SELECT field1, field2, [set]...)

## Attached stacke traces - 'Table_drop' thrown at this point


Finally restart Cassandra. Attach stack 'Cass_start' thrown at this point and 
C* does not start.

Dropping the keyspace does work, however, this must obviously be done before 
stopping the node.

We have also tested this on a 4 node cluster, post the MV create all nodes 
report the same issue.


> Create MV can corrupt C*, blocking all further table actions and startup
> 
>
> Key: CASSANDRA-12753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12753
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: RHEL6.5
> Cas 3.0.9
>Reporter: Hazel Bobrins
>Priority: Critical
> Attachments: Cass_start.txt, MV_Create.txt, table_drop.txt
>
>
> Creating a MV with a protected field name e.g. 'set' results in an error. 
> Post this failed MV create all further actions in the keyspace fail and node 
> startup fails until the keyspace is dropped.
> Tested on a fresh 3.0.9 install single node cluster.
> How to reproduce
> cassandra@cqlsh:test1> CREATE KEYSPACE test1 WITH replication = {'class': 
> 'SimpleStrategy', 'replication_factor': 1 } AND durable_writes = 'true';
> cassandra@cqlsh:test1> use test1 ;
> cassandra@cqlsh:test1> CREATE TABLE main_table ( field1 text, field2 text, 
> "set" text, PRIMARY KEY ( field1, field2 ) );
> cassandra@cqlsh:test1> CREATE MATERIALIZED VIEW mv1 AS SELECT field2, field1, 
> "set" FROM main_table WHERE field1 IS NOT NULL AND field2 IS NOT NULL PRIMARY 
> KEY ( field2, field1 ) ;
> ServerError: java.lang.RuntimeException: 
> java.util.concurrent.ExecutionException: 
> 

[jira] [Created] (CASSANDRA-12753) Create MV can corrupt C*, blocking all further table actions and startup

[Hazel Bobrins (JIRA)]

Hazel Bobrins created CASSANDRA-12753:
-

 Summary: Create MV can corrupt C*, blocking all further table 
actions and startup
 Key: CASSANDRA-12753
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12753
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL6.5
Cas 3.0.9
Reporter: Hazel Bobrins
Priority: Critical
 Attachments: Cass_start.txt, MV_Create.txt, table_drop.txt

Creating a MV with a protected field name e.g. 'set' results in an error. Post 
this failed MV create all further actions in the keyspace fail and node startup 
fails until the keyspace is dropped.

Tested on a fresh 3.0.9 install single node cluster.

How to reproduce

cassandra@cqlsh:test1> CREATE KEYSPACE test1 WITH replication = {'class': 
'SimpleStrategy', 'replication_factor': 1 } AND durable_writes = 'true';
cassandra@cqlsh:test1> use test1 ;
cassandra@cqlsh:test1> CREATE TABLE main_table ( field1 text, field2 text, 
"set" text, PRIMARY KEY ( field1, field2 ) );
cassandra@cqlsh:test1> CREATE MATERIALIZED VIEW mv1 AS SELECT field2, field1, 
"set" FROM main_table WHERE field1 IS NOT NULL AND field2 IS NOT NULL PRIMARY 
KEY ( field2, field1 ) ;
ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable 
alternative at input 'set' (SELECT field1, field2, [set]...)

## Attached stack traces - 'MV_Create' thrown at this point

cassandra@cqlsh:test1> drop TABLE main_table ;
ServerError: java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.SyntaxException: line 1:23 no viable 
alternative at input 'set' (SELECT field1, field2, [set]...)

## Attached stacke traces - 'Table_drop' thrown at this point


Finally restart Cassandra. Attach stack 'Cass_start' thrown at this point and 
C* does not start.

Dropping the keyspace does work, however, this must obviously be done before 
stopping the node.

We have also tested this on a 4 node cluster, post the MV create all nodes 
report the same issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12749) Update a specific property of a UDT in list, from a table.

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551376#comment-15551376
 ] 

Alex Petrov commented on CASSANDRA-12749:
-

There is already an issue for that: [CASSANDRA-7826].

> Update a specific property of a UDT in list, from a table.
> ---
>
> Key: CASSANDRA-12749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12749
> Project: Cassandra
>  Issue Type: Wish
>  Components: CQL
> Environment: Development
>Reporter: Rajashekhar Sheela
>Priority: Critical
> Fix For: 3.0.6
>
>
> I have a table with set as following...
> CREATE TABLE IF NOT EXISTS CustomTemplate (
>   name text,
>   templateId uuid,
>   serviceId uuid,
>   tenants set,
>   templateXml  text,
>   xpath  text,
>   parameters list,
>   PRIMARY KEY (templateId)
> );
> CREATE TYPE IF NOT EXISTS TemplateParameter (
>   name text,
>   label text,
>   type text,
>   displayType text,
>   allowedValues list
> );
> Sample Data:
> cqlsh:skyfall_customtemplate> select * from customtemplate ;
>  templateid   | name| parameters  
>  | 
> serviceid| templatexml | tenants | xpath
> --+-+--+--+-+-+
>  afd01de6-bba9-4417-ab79-6851077f2f84 | testMyTemplate2 | [{name: 'X_PARAM', 
> label: null, type: 'String', displaytype: null, allowedvalues: null}] | 
> 82d565cb-d286-4523-a377-add72af9b23f | xml |null | /xpath
> Requirement is:
> 
> Update "displayType:" of the TemplateParameter whose name='X_PARAM' and 
> templateId=afd01de6-bba9-4417-ab79-6851077f2f84.
> Not able to do this, please let know, how it can be done, if it is already 
> possible.
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12652) Failure in SASIIndexTest.testStaticIndex-compression

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551331#comment-15551331
 ] 

Alex Petrov commented on CASSANDRA-12652:
-

This one is a very low-hanging review fruit: test failures due to incorrect 
cleanup between tests, if anyone would like to take over it.

> Failure in SASIIndexTest.testStaticIndex-compression
> 
>
> Key: CASSANDRA-12652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12652
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Alex Petrov
>
> Stacktrace:
> {code}
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
>   at 
> org.apache.cassandra.index.sasi.SASIIndexTest.testStaticIndex(SASIIndexTest.java:1839)
>   at 
> org.apache.cassandra.index.sasi.SASIIndexTest.testStaticIndex(SASIIndexTest.java:1786)
> {code}
> Example failure:
> http://cassci.datastax.com/job/trunk_testall/1176/testReport/org.apache.cassandra.index.sasi/SASIIndexTest/testStaticIndex_compression/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-12752) Exception encountered during startup (CFMetaData.rebuild failed)

[JIRA]

Jérôme Schneider created CASSANDRA-12752:


 Summary: Exception encountered during startup (CFMetaData.rebuild 
failed)
 Key: CASSANDRA-12752
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12752
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 3.0.7, Debian Jessie. Java version 64 bits : 
1.8.0_91-b14, SSD software raid 1
Reporter: Jérôme Schneider
Priority: Blocker


We have a cluster of 3 cassandra 3.0.7. We have the following problems :
- ssltables was to big to be compress (not enough space left)
- we launch a sstablesplit which seems to work
- after we can't restart cassandra nodes we always have the same stacktrace  
during the start :
{quote}
INFO  [main] 2016-10-05 18:02:47,346 ColumnFamilyStore.java:390 - Initializing 
system_schema.aggregates
INFO  [main] 2016-10-05 18:02:47,353 ColumnFamilyStore.java:390 - Initializing 
system_schema.indexes
ERROR [main] 2016-10-05 18:02:47,420 CassandraDaemon.java:698 - Exception 
encountered during startup
java.lang.AssertionError: null
at 
org.apache.cassandra.db.marshal.CompositeType.getInstance(CompositeType.java:103)
 ~[apache-cassandra-3.0.7.jar:3.0.7]
at org.apache.cassandra.config.CFMetaData.rebuild(CFMetaData.java:313) 
~[apache-cassandra-3.0.7.jar:3.0.7]
at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:292) 
~[apache-cassandra-3.0.7.jar:3.0.7]
at org.apache.cassandra.config.CFMetaData.create(CFMetaData.java:368) 
~[apache-cassandra-3.0.7.jar:3.0.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchTable(SchemaKeyspace.java:954) 
~[apache-cassandra-3.0.7.jar:3.0.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchTables(SchemaKeyspace.java:928) 
~[apache-cassandra-3.0.7.jar:3.0.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:891)
 ~[apache-cassandra-3.0.7.jar:3.0.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:868)
 ~[apache-cassandra-3.0.7.jar:3.0.7]
at 
org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:856)
 ~[apache-cassandra-3.0.7.jar:3.0.7]
at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:136) 
~[apache-cassandra-3.0.7.jar:3.0.7]
at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:126) 
~[apache-cassandra-3.0.7.jar:3.0.7]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:235) 
[apache-cassandra-3.0.7.jar:3.0.7]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:557) 
[apache-cassandra-3.0.7.jar:3.0.7]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:685) 
[apache-cassandra-3.0.7.jar:3.0.7]
{quote}
- it's now impossible to start a cassandra node. I tried to : upgrade to 3.0.9 
(same error), I reset system_schema (cassandra start) and I tried to launch 
sstablescrub on the corrupted keystore (same stacktrace).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-12694) PAXOS Update Corrupted empty row exception

[Alex Petrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551272#comment-15551272
 ] 

Alex Petrov commented on CASSANDRA-12694:
-

bq. I want to fetch all columns but only query the one from columnsToRead()

In both cases ({{all(cfm)}} and {{all(cfm, columns)}}), the output is similar, 
with several exceptions (for example, when only static columns are used in 
condition or only regular columns are used: in these cases we will return only 
them). I've added more tests for such behaviour.
Although after looking at it again I think that new output is better/more 
correct, as we do have a partition and now the output corresponds to that fact 
(in case with {{NOT EXISTS}} in tests. 

You're right that it's better to avoid using {{selection}}, and example with 
{{NOT EXISTS} kind of proves it. As with {{selection}} the output was as if 
partition did not exist at all, but it did exist, even though all the rows were 
deleted.

If you think this is ok, I'll rebase the other versions, too.

|[trunk|https://github.com/ifesdjeen/cassandra/tree/12694-reviewed]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12694-reviewed-dtest/]|[testall|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12694-reviewed-testall/]|

> PAXOS Update Corrupted empty row exception
> --
>
> Key: CASSANDRA-12694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12694
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: 3 node cluster using RF=3 running on cassandra 3.7
>Reporter: Cameron Zemek
>Assignee: Alex Petrov
>
> {noformat}
> cqlsh> create table test.test (test_id TEXT, last_updated TIMESTAMP, 
> message_id TEXT, PRIMARY KEY(test_id));
> update test.test set last_updated = 1474494363669 where test_id = 'test1' if 
> message_id = null;
> {noformat}
> Then nodetool flush on the all 3 nodes.
> {noformat}
> cqlsh> update test.test set last_updated = 1474494363669 where test_id = 
> 'test1' if message_id = null;
> ServerError: 
> {noformat}
> From cassandra log
> {noformat}
> ERROR [SharedPool-Worker-1] 2016-09-23 12:09:13,179 Message.java:611 - 
> Unexpected exception during request; channel = [id: 0x7a22599e, 
> L:/127.0.0.1:9042 - R:/127.0.0.1:58297]
> java.io.IOError: java.io.IOException: Corrupt empty row found in unfiltered 
> partition
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:224)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:212)
>  ~[main/:na]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:125)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:249)
>  ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:87) 
> ~[main/:na]
> at 
> org.apache.cassandra.db.ReadResponse$DataResponse.digest(ReadResponse.java:192)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:80) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:139) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.AbstractReadExecutor.get(AbstractReadExecutor.java:145)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.awaitResultsAndRetryOnDigestMismatch(StorageProxy.java:1714)
>  ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1663) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1604) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1523) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1497) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.readOne(StorageProxy.java:1491) 
> ~[main/:na]
> at 
> org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:249) 
> ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:441)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:416)
>  ~[main/:na]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:208)
>  ~[main/:na]
> at 
> 

[jira] [Commented] (CASSANDRA-12552) CompressedRandomAccessReaderTest.testDataCorruptionDetection fails sporadically

[mck (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551194#comment-15551194
 ] 

mck commented on CASSANDRA-12552:
-

no problem, you beat me to it :-)

> CompressedRandomAccessReaderTest.testDataCorruptionDetection fails 
> sporadically
> ---
>
> Key: CASSANDRA-12552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12552
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> I haven't been able to duplicate the failure myself, but the test uses a 
> randomly generated byte to test corrupted checksums, which I'd expect to fail 
> every 256 test runs or so.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)