[jira] [Reopened] (CASSANDRA-12383) dtest failure in batch_test.TestBatch.logged_batch_doesnt_throw_uae_test

[Joel Knighton (JIRA)]

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

Joel Knighton reopened CASSANDRA-12383:
---

It looks like this is still happening after the test patch was merged:
http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/49/testReport/batch_test/TestBatch/logged_batch_doesnt_throw_uae_test/

> dtest failure in batch_test.TestBatch.logged_batch_doesnt_throw_uae_test
> 
>
> Key: CASSANDRA-12383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12383
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Craig Kodman
>Assignee: Alex Petrov
>  Labels: dtest
> 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/cassandra-3.0_novnode_dtest/282/testReport/batch_test/TestBatch/logged_batch_doesnt_throw_uae_test



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

[jira] [Created] (CASSANDRA-12645) Failure in TimeWindowCompactionStrategyTest.testDropExpiredSSTables-compression

[Joel Knighton (JIRA)]

Joel Knighton created CASSANDRA-12645:
-

 Summary: Failure in 
TimeWindowCompactionStrategyTest.testDropExpiredSSTables-compression
 Key: CASSANDRA-12645
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12645
 Project: Cassandra
  Issue Type: Bug
  Components: Testing
Reporter: Joel Knighton


Stacktrace:
{code}
junit.framework.AssertionFailedError: 
at 
org.apache.cassandra.db.compaction.TimeWindowCompactionStrategyTest.testDropExpiredSSTables(TimeWindowCompactionStrategyTest.java:261)
{code}

Example failure:
http://cassci.datastax.com/job/cassandra-3.9_testall/90/testReport/org.apache.cassandra.db.compaction/TimeWindowCompactionStrategyTest/testDropExpiredSSTables_compression/



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

[jira] [Created] (CASSANDRA-12644) CREATE OR ALTER TABLE

[Jon Haddad (JIRA)]

Jon Haddad created CASSANDRA-12644:
--

 Summary: CREATE OR ALTER TABLE
 Key: CASSANDRA-12644
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12644
 Project: Cassandra
  Issue Type: Bug
Reporter: Jon Haddad


Similar to how tools like Puppet & Chef allow you to specify what you want 
rather than how you want it done, it would be nice to be able to give Cassandra 
this:

{code}CREATE OR ALTER TABLE stuff ( 
id int primary key,
name text,
city text,
state text);{code}

and it would look at the existing schema and work out that it needed to add 
fields that are missing.  This should only work in a non destructive fashion, 
that is, it should not remove fields, indexes, etc.  If a user attempts to 
change a table and the action would be destructive, they should get an error 
that they have to apply those changes explicitly.



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

[jira] [Commented] (CASSANDRA-10099) Improve concurrency in CompactionStrategyManager

[Prateek Agarwal (JIRA)]

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

Prateek Agarwal commented on CASSANDRA-10099:
-

[~jjordan] Yeah, we are thinking of backporting ourselves but wanted to check 
whether it is even compatible with 2.2 version (i believe it wouldn't).

> Improve concurrency in CompactionStrategyManager
> 
>
> Key: CASSANDRA-10099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10099
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Yuki Morishita
>Assignee: Marcus Eriksson
>  Labels: compaction, lcs
> Fix For: 3.6
>
>
> Continue discussion from CASSANDRA-9882.
> CompactionStrategyManager(WrappingCompactionStrategy for <3.0) tracks SSTable 
> changes mainly for separating repaired / unrepaired SSTables (+ LCS manages 
> level).
> This is blocking operation, and can lead to block of flush etc. when 
> determining next background task takes longer.
> Explore the way to mitigate this concurrency issue.



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

[jira] [Comment Edited] (CASSANDRA-11850) cannot use cql since upgrading python to 2.7.11+

[Stefania (JIRA)]

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

Stefania edited comment on CASSANDRA-11850 at 9/15/16 12:53 AM:


You are correct, none of the versions with this fix have been released yet. The 
easiest workaround is, as you said, to downgrade Python. I'm pretty sure 2.7.11 
should also be fine, since I was only able to reproduce this problem with 
2.7.12.

Installing version 3.5.0 or later of the Cassandra python driver is also an 
option, but there were some other minor issues that this patch fixed. 
Therefore, it is recommended to downgrade Python, if at all possible. If this 
is not possible, the driver can be installed by following these 
[instructions|http://datastax.github.io/python-driver/installation.html]. 
Further, cqlsh will only override its internal driver with a version installed 
elsewhere by setting the environment variable {{CQLSH_NO_BUNDLED}} to {{TRUE}}.


was (Author: stefania):
You are correct, none of the versions with this fix have been released yet. The 
easiest workaround is, as you said, to downgrade Python. I'm pretty sure 2.7.11 
should also be fine, since I was only able to reproduce this problem with 
2.7.12.

Installing version 3.5.0 or later of the Cassandra python driver is also an 
option, but there were some other minor issues that this patch fixed. 
Therefore, it is recommended to downgrade Python, if at all possible. If this 
is not possible, the the driver can be installed by following these 
[instructions|http://datastax.github.io/python-driver/installation.html]. 
Further, cqlsh will only override its internal driver with a version installed 
elsewhere by setting the environment variable {{CQLSH_NO_BUNDLED}} to {{TRUE}}.

> cannot use cql since upgrading python to 2.7.11+
> 
>
> Key: CASSANDRA-11850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11850
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Development
>Reporter: Andrew Madison
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.1.16, 2.2.8, 3.0.9, 3.8
>
>
> OS: Debian GNU/Linux stretch/sid 
> Kernel: 4.5.0-2-amd64 #1 SMP Debian 4.5.4-1 (2016-05-16) x86_64 GNU/Linux
> Python version: 2.7.11+ (default, May  9 2016, 15:54:33)
> [GCC 5.3.1 20160429]
> cqlsh --version: cqlsh 5.0.1
> cassandra -v: 3.5 (also occurs with 3.0.6)
> Issue:
> when running cqlsh, it returns the following error:
> cqlsh -u dbarpt_usr01
> Password: *
> Connection error: ('Unable to connect to any servers', {'odbasandbox1': 
> TypeError('ref() does not take keyword arguments',)})
> I cleared PYTHONPATH:
> python -c "import json; print dir(json); print json.__version__"
> ['JSONDecoder', 'JSONEncoder', '__all__', '__author__', '__builtins__', 
> '__doc__', '__file__', '__name__', '__package__', '__path__', '__version__', 
> '_default_decoder', '_default_encoder', 'decoder', 'dump', 'dumps', 
> 'encoder', 'load', 'loads', 'scanner']
> 2.0.9
> Java based clients can connect to Cassandra with no issue. Just CQLSH and 
> Python clients cannot.
> nodetool status also works.
> Thank you for your help.



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

[jira] [Commented] (CASSANDRA-11850) cannot use cql since upgrading python to 2.7.11+

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11850:
--

You are correct, none of the versions with this fix have been released yet. The 
easiest workaround is, as you said, to downgrade Python. I'm pretty sure 2.7.11 
should also be fine, since I was only able to reproduce this problem with 
2.7.12.

Installing version 3.5.0 or later of the Cassandra python driver is also an 
option, but there were some other minor issues that this patch fixed. 
Therefore, it is recommended to downgrade Python, if at all possible. If this 
is not possible, the the driver can be installed by following these 
[instructions|http://datastax.github.io/python-driver/installation.html]. 
Further, cqlsh will only override its internal driver with a version installed 
elsewhere by setting the environment variable {{CQLSH_NO_BUNDLED}} to {{TRUE}}.

> cannot use cql since upgrading python to 2.7.11+
> 
>
> Key: CASSANDRA-11850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11850
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Development
>Reporter: Andrew Madison
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.1.16, 2.2.8, 3.0.9, 3.8
>
>
> OS: Debian GNU/Linux stretch/sid 
> Kernel: 4.5.0-2-amd64 #1 SMP Debian 4.5.4-1 (2016-05-16) x86_64 GNU/Linux
> Python version: 2.7.11+ (default, May  9 2016, 15:54:33)
> [GCC 5.3.1 20160429]
> cqlsh --version: cqlsh 5.0.1
> cassandra -v: 3.5 (also occurs with 3.0.6)
> Issue:
> when running cqlsh, it returns the following error:
> cqlsh -u dbarpt_usr01
> Password: *
> Connection error: ('Unable to connect to any servers', {'odbasandbox1': 
> TypeError('ref() does not take keyword arguments',)})
> I cleared PYTHONPATH:
> python -c "import json; print dir(json); print json.__version__"
> ['JSONDecoder', 'JSONEncoder', '__all__', '__author__', '__builtins__', 
> '__doc__', '__file__', '__name__', '__package__', '__path__', '__version__', 
> '_default_decoder', '_default_encoder', 'decoder', 'dump', 'dumps', 
> 'encoder', 'load', 'loads', 'scanner']
> 2.0.9
> Java based clients can connect to Cassandra with no issue. Just CQLSH and 
> Python clients cannot.
> nodetool status also works.
> Thank you for your help.



--
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=15491917#comment-15491917
 ] 

Stefania commented on CASSANDRA-11534:
--

Rolling from an intermediate commit is fine. I've created a PR against master 
[here|https://github.com/datastax/python-driver/pull/665].

> 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] [Assigned] (CASSANDRA-12642) cqlsh NoHostsAvailable/AuthenticationFailure when sourcing a file with COPY commands

[Stefania (JIRA)]

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

Stefania reassigned CASSANDRA-12642:


Assignee: Stefania

> cqlsh NoHostsAvailable/AuthenticationFailure when sourcing a file with COPY 
> commands
> 
>
> Key: CASSANDRA-12642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12642
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Adam Holmberg
>Assignee: Stefania
>Priority: Minor
>
> In {{cqlsh}}, with authentication enabled, when sourcing a file with {{COPY}} 
> commands in it:
> {noformat}
> test.cql:2:Error for (None, None): Failed to connect to all replicas 
> ['127.0.0.1'] for (None, None), errors: ["NoHostAvailable - ('Unable to 
> connect to any servers', {'127.0.0.1': AuthenticationFailed('Remote end 
> requires authentication.',)})"] (permanently given up after 0 rows and 5 
> attempts)
> {noformat}
> {{cqlsh}} creates a new {{Shell}} without passing all pertinent arguments. 
> When {{copyutil}} creates new cluster connections, they are not initialized 
> correctly.
> This is only for the {{source}} command. As a workaround,  {{cqlsh -f 
> 

[jira] [Commented] (CASSANDRA-10099) Improve concurrency in CompactionStrategyManager

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-10099:
-

You would also want to make sure to check for any follow up changes to the code 
from the patch that have been made in trunk to make sure the patch doesn't have 
bugs fixed later on...

> Improve concurrency in CompactionStrategyManager
> 
>
> Key: CASSANDRA-10099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10099
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Yuki Morishita
>Assignee: Marcus Eriksson
>  Labels: compaction, lcs
> Fix For: 3.6
>
>
> Continue discussion from CASSANDRA-9882.
> CompactionStrategyManager(WrappingCompactionStrategy for <3.0) tracks SSTable 
> changes mainly for separating repaired / unrepaired SSTables (+ LCS manages 
> level).
> This is blocking operation, and can lead to block of flush etc. when 
> determining next background task takes longer.
> Explore the way to mitigate this concurrency issue.



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

[jira] [Commented] (CASSANDRA-10099) Improve concurrency in CompactionStrategyManager

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-10099:
-

This is a pretty invasive and possibly dangerous change to do in a stable 
branch, but you could probably backport it yourself if you don't mind building 
your own jars.

> Improve concurrency in CompactionStrategyManager
> 
>
> Key: CASSANDRA-10099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10099
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Yuki Morishita
>Assignee: Marcus Eriksson
>  Labels: compaction, lcs
> Fix For: 3.6
>
>
> Continue discussion from CASSANDRA-9882.
> CompactionStrategyManager(WrappingCompactionStrategy for <3.0) tracks SSTable 
> changes mainly for separating repaired / unrepaired SSTables (+ LCS manages 
> level).
> This is blocking operation, and can lead to block of flush etc. when 
> determining next background task takes longer.
> Explore the way to mitigate this concurrency issue.



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

[jira] [Commented] (CASSANDRA-12643) Estimated histograms tend to overflow

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-12643:
-

https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:CASSANDRA-12643

It would be nice to know which data it was, but at least seeing the data should 
help us understand this.

> Estimated histograms tend to overflow
> -
>
> Key: CASSANDRA-12643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12643
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>




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

[jira] [Updated] (CASSANDRA-12643) Estimated histograms tend to overflow

[Edward Capriolo (JIRA)]

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

Edward Capriolo updated CASSANDRA-12643:

Status: Awaiting Feedback  (was: Open)

> Estimated histograms tend to overflow
> -
>
> Key: CASSANDRA-12643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12643
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>




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

[jira] [Commented] (CASSANDRA-10099) Improve concurrency in CompactionStrategyManager

[Prateek Agarwal (JIRA)]

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

Prateek Agarwal commented on CASSANDRA-10099:
-

[~krummas] We are facing the same issue with Cassandra 2.2.5. Was curious if 
the same patch can be backported to our 2.2 version?

> Improve concurrency in CompactionStrategyManager
> 
>
> Key: CASSANDRA-10099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10099
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Yuki Morishita
>Assignee: Marcus Eriksson
>  Labels: compaction, lcs
> Fix For: 3.6
>
>
> Continue discussion from CASSANDRA-9882.
> CompactionStrategyManager(WrappingCompactionStrategy for <3.0) tracks SSTable 
> changes mainly for separating repaired / unrepaired SSTables (+ LCS manages 
> level).
> This is blocking operation, and can lead to block of flush etc. when 
> determining next background task takes longer.
> Explore the way to mitigate this concurrency issue.



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

[jira] [Commented] (CASSANDRA-12643) Estimated histograms tend to overflow

[Edward Capriolo (JIRA)]

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

Edward Capriolo commented on CASSANDRA-12643:
-

After enabling a reporter and starting up Cassandra I have observed the 
following stack trace.

{noformat}
java.lang.IllegalStateException: Unable to compute when histogram overflowed
at 
org.apache.cassandra.utils.EstimatedHistogram.percentile(EstimatedHistogram.java:198)
 ~apache-cassandra-3.0.8.jar:3.0.8
at 
org.apache.cassandra.metrics.EstimatedHistogramReservoir$HistogramSnapshot.getValue(EstimatedHistogramReservoir.java:85)
 ~apache-cassandra-3.0.8.jar:3.0.8
at com.codahale.metrics.Snapshot.getMedian(Snapshot.java:38) 
~metrics-core-3.1.0.jar:3.1.0
at 
com.librato.metrics.MetricsLibratoBatch.addSampling(MetricsLibratoBatch.java:144)
 ~metrics-librato-4.1.2.5.jar:na
at 
com.librato.metrics.MetricsLibratoBatch.addHistogram(MetricsLibratoBatch.java:124)
 ~metrics-librato-4.1.2.5.jar:na
at com.librato.metrics.LibratoReporter.report(LibratoReporter.java:167) 
~metrics-librato-4.1.2.5.jar:na
at com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
~metrics-core-3.1.0.jar:3.1.0
at com.librato.metrics.LibratoReporter.report(LibratoReporter.java:127) 
~metrics-librato-4.1.2.5.jar:na
at com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
metrics-core-3.1.0.jar:3.1.0
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
na:1.8.0_101
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) na:1.8.0_101
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 na:1.8.0_101
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 na:1.8.0_101
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
na:1.8.0_101
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
na:1.8.0_101
at java.lang.Thread.run(Thread.java:745) na:1.8.0_101
{noformat}

According to the inline documentation the largest bucket should accommodate 36 
seconds. The server only being alive for a few seconds it seems unlikely that 
these can be overflowed. 

This overflow bubbles up to the report and this prevents data from being 
exported. I poked around and do not understand why a fresh server would 
overflow. I found some nits in the code I can fix and maybe someone with more 
brain power can chime in.

> Estimated histograms tend to overflow
> -
>
> Key: CASSANDRA-12643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12643
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>




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

[jira] [Created] (CASSANDRA-12643) Estimated histograms tend to overflow

[Edward Capriolo (JIRA)]

Edward Capriolo created CASSANDRA-12643:
---

 Summary: Estimated histograms tend to overflow
 Key: CASSANDRA-12643
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12643
 Project: Cassandra
  Issue Type: Bug
Reporter: Edward Capriolo
Assignee: Edward Capriolo






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

[jira] [Commented] (CASSANDRA-12642) cqlsh NoHostsAvailable/AuthenticationFailure when sourcing a file with COPY commands

[Adam Holmberg (JIRA)]

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

Adam Holmberg commented on CASSANDRA-12642:
---

[3.9|https://github.com/apache/cassandra/compare/cassandra-3.9...aholmberg:12642-3.9]
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...aholmberg:12642-2.2]
 / 
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...aholmberg:12642-3.0]

2.2/3.0 are the same; 3.9 had one additional parameter.

> cqlsh NoHostsAvailable/AuthenticationFailure when sourcing a file with COPY 
> commands
> 
>
> Key: CASSANDRA-12642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12642
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Adam Holmberg
>Priority: Minor
>
> In {{cqlsh}}, with authentication enabled, when sourcing a file with {{COPY}} 
> commands in it:
> {noformat}
> test.cql:2:Error for (None, None): Failed to connect to all replicas 
> ['127.0.0.1'] for (None, None), errors: ["NoHostAvailable - ('Unable to 
> connect to any servers', {'127.0.0.1': AuthenticationFailed('Remote end 
> requires authentication.',)})"] (permanently given up after 0 rows and 5 
> attempts)
> {noformat}
> {{cqlsh}} creates a new {{Shell}} without passing all pertinent arguments. 
> When {{copyutil}} creates new cluster connections, they are not initialized 
> correctly.
> This is only for the {{source}} command. As a workaround,  {{cqlsh -f 
> 

[jira] [Created] (CASSANDRA-12642) cqlsh NoHostsAvailable/AuthenticationFailure when sourcing a file with COPY commands

[Adam Holmberg (JIRA)]

Adam Holmberg created CASSANDRA-12642:
-

 Summary: cqlsh NoHostsAvailable/AuthenticationFailure when 
sourcing a file with COPY commands
 Key: CASSANDRA-12642
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12642
 Project: Cassandra
  Issue Type: Bug
Reporter: Adam Holmberg
Priority: Minor


In {{cqlsh}}, with authentication enabled, when sourcing a file with {{COPY}} 
commands in it:
{noformat}
test.cql:2:Error for (None, None): Failed to connect to all replicas 
['127.0.0.1'] for (None, None), errors: ["NoHostAvailable - ('Unable to connect 
to any servers', {'127.0.0.1': AuthenticationFailed('Remote end requires 
authentication.',)})"] (permanently given up after 0 rows and 5 attempts)
{noformat}

{{cqlsh}} creates a new {{Shell}} without passing all pertinent arguments. When 
{{copyutil}} creates new cluster connections, they are not initialized 
correctly.

This is only for the {{source}} command. As a workaround,  {{cqlsh -f 

[jira] [Updated] (CASSANDRA-12605) Timestamp-order searching of sstables does not handle non-frozen UDTs, frozen collections correctly

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-12605:

Reviewer: Benjamin Lerer
  Status: Patch Available  (was: In Progress)

> Timestamp-order searching of sstables does not handle non-frozen UDTs, frozen 
> collections correctly
> ---
>
> Key: CASSANDRA-12605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12605
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>
> {{SinglePartitionReadCommand.queryNeitherCountersNorCollections()}} is used 
> to determine whether we can search sstables in timestamp order.  We cannot 
> use this optimization when there are multicell values (such as unfrozen 
> collections or UDTs).  However, this method only checks 
> {{column.type.isCollection() || column.type.isCounter()}}.  Instead, it 
> should check {{column.type.isMulticell() || column.type.isCounter()}}.
> This has two implications:
> * We are using timestamp-order searching when querying non-frozen UDTs, which 
> can lead to incorrect/stale results being returned.
> * We are not taking advantage of this optimization when querying frozen 
> collections.



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

[jira] [Commented] (CASSANDRA-12605) Timestamp-order searching of sstables does not handle non-frozen UDTs, frozen collections correctly

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-12605:
-

Patch and pending CI runs:

||branch||testall||dtest||
|[CASSANDRA-12605-3.0|https://github.com/thobbs/cassandra/tree/CASSANDRA-12605-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12605-3.0-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12605-3.0-dtest]|
|[CASSANDRA-12605-trunk|https://github.com/thobbs/cassandra/tree/CASSANDRA-12605-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12605-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12605-trunk-dtest]|

> Timestamp-order searching of sstables does not handle non-frozen UDTs, frozen 
> collections correctly
> ---
>
> Key: CASSANDRA-12605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12605
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>
> {{SinglePartitionReadCommand.queryNeitherCountersNorCollections()}} is used 
> to determine whether we can search sstables in timestamp order.  We cannot 
> use this optimization when there are multicell values (such as unfrozen 
> collections or UDTs).  However, this method only checks 
> {{column.type.isCollection() || column.type.isCounter()}}.  Instead, it 
> should check {{column.type.isMulticell() || column.type.isCounter()}}.
> This has two implications:
> * We are using timestamp-order searching when querying non-frozen UDTs, which 
> can lead to incorrect/stale results being returned.
> * We are not taking advantage of this optimization when querying frozen 
> collections.



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

[jira] [Updated] (CASSANDRA-12640) dtest failure in repair_tests.repair_test.TestRepairDataSystemTable.repair_parent_table_test

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-12640:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

> dtest failure in 
> repair_tests.repair_test.TestRepairDataSystemTable.repair_parent_table_test
> 
>
> Key: CASSANDRA-12640
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12640
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Philip Thompson
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/478/testReport/repair_tests.repair_test/TestRepairDataSystemTable/repair_parent_table_test
> {code}
> stderr: WARN  02:48:18,362 No schema agreement from live replicas after 10 s. 
> The schema may not be up to date on some nodes.
> java.lang.RuntimeException: Encountered exception creating schema
>   at 
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpacesNative(SettingsSchema.java:101)
>   at 
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:69)
>   at 
> org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:228)
>   at org.apache.cassandra.stress.StressAction.run(StressAction.java:59)
>   at org.apache.cassandra.stress.Stress.run(Stress.java:143)
>   at org.apache.cassandra.stress.Stress.main(Stress.java:62)
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: 
> Keyspace 'keyspace1' does not exist
>   at 
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
>   at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
>   at 
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
>   at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:63)
>   at 
> org.apache.cassandra.stress.util.JavaDriverClient.execute(JavaDriverClient.java:183)
>   at 
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpacesNative(SettingsSchema.java:86)
>   ... 5 more
> {code}
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 320, in run
> self.setUp()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 32, in 
> wrapped_setUp
> orig_setUp(obj, *args, **kwargs)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1082, in setUp
> self.node1.stress(stress_options=['write', 'n=5K', 'no-warmup', 'cl=ONE', 
> '-schema', 'replication(factor=3)'])
>   File "/home/automaton/src/ccm/ccmlib/node.py", line 1256, in stress
> return handle_external_tool_process(p, ['stress'] + stress_options)
>   File "/home/automaton/src/ccm/ccmlib/node.py", line 1985, in 
> handle_external_tool_process
> raise ToolError(cmd_args, rc, out, err)
> {code}
> There are no logs.



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

[jira] [Updated] (CASSANDRA-12639) dtest failure in user_types_test.TestUserTypes.test_type_as_part_of_pkey

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-12639:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

> dtest failure in user_types_test.TestUserTypes.test_type_as_part_of_pkey
> 
>
> Key: CASSANDRA-12639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12639
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Alex Petrov
>  Labels: dtest
> 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_dtest/1365/testReport/user_types_test/TestUserTypes/test_type_as_part_of_pkey
> {code}
> Error Message
> Regexp didn't match: 'Partition key parts: name must be restricted as other 
> parts are' not found in 'Error from server: code=2200 [Invalid query] 
> message="Cannot execute this query as it might involve data filtering and 
> thus may have unpredictable performance. If you want to execute this query 
> despite the performance unpredictability, use ALLOW FILTERING"'
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/user_types_test.py", line 382, in 
> test_type_as_part_of_pkey
> assert_invalid(session, stmt, 'Partition key parts: name must be 
> restricted as other parts are')
>   File "/home/automaton/cassandra-dtest/tools/assertions.py", line 98, in 
> assert_invalid
> assert_exception(session, query, matching=matching, expected=expected)
>   File "/home/automaton/cassandra-dtest/tools/assertions.py", line 71, in 
> assert_exception
> _assert_exception(session.execute, query, matching=matching, 
> expected=expected)
>   File "/home/automaton/cassandra-dtest/tools/assertions.py", line 60, in 
> _assert_exception
> assert_regexp_matches(str(e), matching)
>   File "/usr/lib/python2.7/unittest/case.py", line 1002, in 
> assertRegexpMatches
> raise self.failureException(msg)
> {code}



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

[jira] [Commented] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-12554:
-

The new patch looks good to me.  I've backported this to 2.2 and started CI 
test runs:

||branch||testall||dtest||
|[CASSANDRA-12554-2.2|https://github.com/thobbs/cassandra/tree/CASSANDRA-12554-2.2]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12554-2.2-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12554-2.2-dtest]|
|[CASSANDRA-12554-3.0|https://github.com/thobbs/cassandra/tree/CASSANDRA-12554-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12554-3.0-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12554-3.0-dtest]|
|[CASSANDRA-12554-trunk|https://github.com/thobbs/cassandra/tree/CASSANDRA-12554-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12554-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-12554-trunk-dtest]|

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: CASSANDRA_12554_3.0.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

[jira] [Updated] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-12554:
--
Status: Patch Available  (was: Awaiting Feedback)

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: CASSANDRA_12554_3.0.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

[jira] [Commented] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-12554:
---

Attaching a patch which only puts the finally block

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: CASSANDRA_12554_3.0.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

[jira] [Updated] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-12554:
--
Attachment: CASSANDRA_12554_3.0.txt

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: CASSANDRA_12554_3.0.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

[jira] [Updated] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-12554:
--
Attachment: (was: PendingRangeRace.txt)

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: CASSANDRA_12554_3.0.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

[jira] [Commented] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[sankalp kohli (JIRA)]

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

sankalp kohli commented on CASSANDRA-12554:
---

You are right on the discard policy. This patch is for 3.0.

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: PendingRangeRace.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

[jira] [Updated] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-12554:

Status: Awaiting Feedback  (was: Open)

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: PendingRangeRace.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

[jira] [Updated] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-12554:

Status: Open  (was: Patch Available)

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: PendingRangeRace.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

[jira] [Commented] (CASSANDRA-12554) updateJobs in PendingRangeCalculatorService should be decremented in finally block

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-12554:
-

bq. Also we dont need to change the setRejectedExecutionHandler in 
CASSANDRA-7390 as we can change the order of calling increment. 

I don't believe this change is correct.  With the {{DiscardPolicy}}, if the 
runnable is rejected it will be silently discarded, so we'll increment the 
counter but never decrement it.

Also, what branch is the patch based on?

> updateJobs in PendingRangeCalculatorService should be decremented in finally 
> block
> --
>
> Key: CASSANDRA-12554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12554
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: sankalp kohli
>Priority: Minor
> Attachments: PendingRangeRace.txt
>
>
> We fixed an issue in CASSANDRA-7390 with MoveTests by adding a count for 
> running jobs. While looking at the code, I can see that decrement of this 
> counter should be done in finally block. 
> Also we dont need to change the setRejectedExecutionHandler in CASSANDRA-7390 
> as we can change the order of calling increment. 



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

cassandra git commit: Ninja: add link to snapshot builds to Development section

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 81f6c784c -> cfedd4d0e


Ninja: add link to snapshot builds to Development section

This was previously on the Downloads page, and needed to be moved
elsewhere.


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

Branch: refs/heads/trunk
Commit: cfedd4d0e157fd7ccae86c22c302b3d1b90657bb
Parents: 81f6c78
Author: Tyler Hobbs 
Authored: Wed Sep 14 13:49:33 2016 -0500
Committer: Tyler Hobbs 
Committed: Wed Sep 14 13:49:59 2016 -0500

--
 doc/source/development/ide.rst | 4 
 1 file changed, 4 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/cfedd4d0/doc/source/development/ide.rst
--
diff --git a/doc/source/development/ide.rst b/doc/source/development/ide.rst
index c52c11a..2986495 100644
--- a/doc/source/development/ide.rst
+++ b/doc/source/development/ide.rst
@@ -42,6 +42,10 @@ This may take a significant amount of time depending on 
whether artifacts have t
 
You can setup multiple working trees for different Cassandra versions from 
the same repository using `git-worktree 
`_.
 
+.. note::
+
+   `Bleeding edge development snapshots 
`_ of Cassandra are 
available from Jenkins continuous integration.
+
 Setting up Cassandra in IntelliJ IDEA
 =
 

[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken

[Christopher Batey (JIRA)]

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

Christopher Batey commented on CASSANDRA-12237:
---

Thanks [~slebresne] i have rebased the branch

> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse 
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5 
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10 
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from 
> {code}PrintWriter{code} and then delegate the call to super as well as a list 
> of other PrintWriters
> The call to super for println comes back into our print method so every line 
> gets logged multiple times as we do the for (PrintStream s: newStreams) many 
> times.
> We can change this to use composition and use our own interface if we want to 
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate 
> stats not working in produced graphs.



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

[jira] [Commented] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-12253:
---

I'm looking at it now - probably don't need to loop in Brandon on this any more.

> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch, 
> 0002-for-proxy-node-not-set-gossip-tokens.patch, 
> 0003-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}



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

[jira] [Updated] (CASSANDRA-8589) Reconciliation in presence of tombstone might yield state data

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-8589:
---
Tester:   (was: Ryan McGuire)

> Reconciliation in presence of tombstone might yield state data
> --
>
> Key: CASSANDRA-8589
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8589
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
> Fix For: 2.1.x, 2.2.x
>
>
> Consider 3 replica A, B, C (so RF=3) and consider that we do the following 
> sequence of actions at {{QUORUM}} where I indicate the replicas acknowledging 
> each operation (and let's assume that a replica that don't ack is a replica 
> that don't get the update):
> {noformat}
> CREATE TABLE test (k text, t int, v int, PRIMARY KEY (k, t))
> INSERT INTO test(k, t, v) VALUES ('k', 0, 0); // acked by A, B and C
> INSERT INTO test(k, t, v) VALUES ('k', 1, 1); // acked by A, B and C
> INSERT INTO test(k, t, v) VALUES ('k', 2, 2); // acked by A, B and C
> DELETE FROM test WHERE k='k' AND t=1; // acked by A and C
> UPDATE test SET v = 3 WHERE k='k' AND t=2;// acked by B and C
> SELECT * FROM test WHERE k='k' LIMIT 2;   // answered by A and B
> {noformat}
> Every operation has achieved quorum, but on the last read, A will respond 
> {{0->0, tombstone 1, 2->2}} and B will respond {{0->0, 1->1}}. As a 
> consequence we'll answer {{0->0, 2->2}} which is incorrect (we should respond 
> {{0->0, 2->3}}).
> Put another way, if we have a limit, every replica honors that limit but 
> since tombstones can "suppress" results from other nodes, we may have some 
> cells for which we actually don't get a quorum of response (even though we 
> globally have a quorum of replica responses).
> In practice, this probably occurs rather rarely and so the "simpler" fix is 
> probably to do something similar to the "short reads protection": detect when 
> this could have happen (based on how replica response are reconciled) and do 
> an additional request in that case. That detection will have potential false 
> positives but I suspect we can be precise enough that those false positives 
> will be very very rare (we should nonetheless track how often this code gets 
> triggered and if we see that it's more often than we think, we could 
> pro-actively bump user limits internally to reduce those occurrences).



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

[jira] [Commented] (CASSANDRA-12225) dtest failure in materialized_views_test.TestMaterializedViews.clustering_column_test

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-12225:


I ran a [multiplexed 
dtest|http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/253/]
 and it failed once with the same error.

I've pushed a new commit to wait for all of the stages to settle before 
continuing; I'm rerunning the [multiplexed 
test|http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/313/]
 to see if there are any new failures.

> dtest failure in 
> materialized_views_test.TestMaterializedViews.clustering_column_test
> -
>
> Key: CASSANDRA-12225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12225
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Carl Yeksigian
>  Labels: dtest
> 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_offheap_dtest/336/testReport/materialized_views_test/TestMaterializedViews/clustering_column_test
> Failed on CassCI build trunk_offheap_dtest #336
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/materialized_views_test.py", line 
> 321, in clustering_column_test
> self.assertEqual(len(result), 2, "Expecting {} users, got {}".format(2, 
> len(result)))
>   File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> "Expecting 2 users, got 1
> {code}



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

[jira] [Commented] (CASSANDRA-12472) Backport CASSANDRA-10756 to 3.0

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-12472:
---

LGTM. Awesome to see all those tests passing.

> Backport CASSANDRA-10756 to 3.0
> ---
>
> Key: CASSANDRA-12472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12472
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Alex Petrov
>
> [CASSANDRA-10756] fixed a problem with timeouts in 
> {{NativeTransportService.testConcurrentDestroys}}.
> This fix was only committed to trunk, but the test still fails for the same 
> reason on 3.0 
> [here|http://cassci.datastax.com/job/cassandra-3.0_testall/612/testReport/junit/org.apache.cassandra.service/NativeTransportServiceTest/testConcurrentDestroys_2/].
>  The fix should cleanly backport to 3.0.



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

[jira] [Updated] (CASSANDRA-12472) Backport CASSANDRA-10756 to 3.0

[Joel Knighton (JIRA)]

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

Joel Knighton updated CASSANDRA-12472:
--
Status: Ready to Commit  (was: Patch Available)

> Backport CASSANDRA-10756 to 3.0
> ---
>
> Key: CASSANDRA-12472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12472
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Joel Knighton
>Assignee: Alex Petrov
>
> [CASSANDRA-10756] fixed a problem with timeouts in 
> {{NativeTransportService.testConcurrentDestroys}}.
> This fix was only committed to trunk, but the test still fails for the same 
> reason on 3.0 
> [here|http://cassci.datastax.com/job/cassandra-3.0_testall/612/testReport/junit/org.apache.cassandra.service/NativeTransportServiceTest/testConcurrentDestroys_2/].
>  The fix should cleanly backport to 3.0.



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

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

[Adam Holmberg (JIRA)]

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

Adam Holmberg commented on CASSANDRA-11534:
---

This approach seems good -- thanks for the patch. We welcome a PR, but since we 
just released the core driver, we may need to just roll from an intermediate 
commit. Will also need to apply to cassandra-test.

> 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-11720) Changing `max_hint_window_in_ms` at runtime

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-11720:
---
Status: Patch Available  (was: Open)

> Changing `max_hint_window_in_ms` at runtime
> ---
>
> Key: CASSANDRA-11720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11720
> Project: Cassandra
>  Issue Type: Wish
>  Components: Coordination
>Reporter: Jens Rantil
>Priority: Minor
>  Labels: lhf
> Attachments: CASSANDRA-11720-trunk.patch
>
>
> Scenario: A larger node (in terms of data it holds) goes down. You realize 
> that it will take slightly more than `max_hint_window_in_ms` to fix it. You 
> have a the disk space to store some additional hints.
> Proposal: Support changing `max_hint_window_in_ms` at runtime. The change 
> doesn't have to be persisted somewhere. I'm thinking similar to changing the 
> `compactionthroughput` etc. using `nodetool`.
> Workaround: Change the value in the configuration file and do a rolling 
> restart of all the nodes.



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

[jira] [Commented] (CASSANDRA-11720) Changing `max_hint_window_in_ms` at runtime

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi commented on CASSANDRA-11720:


Hello,

I fixed this issue. Below is a sample result.

{code}
$ ./bin/nodetool getmaxhintwindow
Current max hint window: 1080 ms

$ ./bin/nodetool setmaxhintwindow 0

$ ./bin/nodetool getmaxhintwindow  
Current max hint window: 0 ms
{code}

Could someone review the attached patch?
I worked in trunk branch.

Thank you.

> Changing `max_hint_window_in_ms` at runtime
> ---
>
> Key: CASSANDRA-11720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11720
> Project: Cassandra
>  Issue Type: Wish
>  Components: Coordination
>Reporter: Jens Rantil
>Priority: Minor
>  Labels: lhf
> Attachments: CASSANDRA-11720-trunk.patch
>
>
> Scenario: A larger node (in terms of data it holds) goes down. You realize 
> that it will take slightly more than `max_hint_window_in_ms` to fix it. You 
> have a the disk space to store some additional hints.
> Proposal: Support changing `max_hint_window_in_ms` at runtime. The change 
> doesn't have to be persisted somewhere. I'm thinking similar to changing the 
> `compactionthroughput` etc. using `nodetool`.
> Workaround: Change the value in the configuration file and do a rolling 
> restart of all the nodes.



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

[jira] [Updated] (CASSANDRA-11720) Changing `max_hint_window_in_ms` at runtime

[Hiroyuki Nishi (JIRA)]

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

Hiroyuki Nishi updated CASSANDRA-11720:
---
Attachment: CASSANDRA-11720-trunk.patch

> Changing `max_hint_window_in_ms` at runtime
> ---
>
> Key: CASSANDRA-11720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11720
> Project: Cassandra
>  Issue Type: Wish
>  Components: Coordination
>Reporter: Jens Rantil
>Priority: Minor
>  Labels: lhf
> Attachments: CASSANDRA-11720-trunk.patch
>
>
> Scenario: A larger node (in terms of data it holds) goes down. You realize 
> that it will take slightly more than `max_hint_window_in_ms` to fix it. You 
> have a the disk space to store some additional hints.
> Proposal: Support changing `max_hint_window_in_ms` at runtime. The change 
> doesn't have to be persisted somewhere. I'm thinking similar to changing the 
> `compactionthroughput` etc. using `nodetool`.
> Workaround: Change the value in the configuration file and do a rolling 
> restart of all the nodes.



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

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

[Berenguer Blasi (JIRA)]

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

Berenguer Blasi updated CASSANDRA-12598:

Status: Patch Available  (was: Open)

> 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
> 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-12598) BailErrorStragery alike for ANTLR grammar parsing

[Berenguer Blasi (JIRA)]

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

Berenguer Blasi commented on CASSANDRA-12598:
-

Branch available here: 
[link|https://github.com/bereng/cassandra/tree/CASSANDRA-12598-trunk_2]

Test all results available here 
[link|https://cassci.datastax.com/view/Dev/view/bereng/job/bereng-CASSANDRA-12598-trunk_2-testall/2/]
Dtest resultst available here 
[link|https://cassci.datastax.com/view/Dev/view/bereng/job/bereng-CASSANDRA-12598-trunk_2-dtest/6/]
 (Failure looks unrelated, previous commit fails on a different test also)

> 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
> 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-12060) Establish consistent distinction between non-existing partition and NULL value for LWTs on static columns

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-12060:
-

Sorry, my wording was ambiguous. That was only required in my branch, so I was 
only trying to justify why I put it there. To give a bit more background: for 
2.x version to work and distinguish between "existing container and null value" 
and "non existing container" we had to read out at least one row, which was 
leading to change in this output. To keep things consistent between versions, I 
made 3.x returns same. 

This is not required after the behaviour changes you've introduced, so we're 
good.

> Establish consistent distinction between non-existing partition and NULL 
> value for LWTs on static columns
> -
>
> Key: CASSANDRA-12060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12060
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>
> When executing following CQL commands: 
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1' };
> USE test;
> CREATE TABLE testtable (a int, b int, s1 int static, s2 int static, v int, 
> PRIMARY KEY (a, b));
> INSERT INTO testtable (a,b,s1,s2,v) VALUES (2,2,2,null,2);
> DELETE s1 FROM testtable WHERE a = 2 IF s2 IN (10,20,30);
> {code}
> The output is different between {{2.x}} and {{3.x}}:
> 2.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied] | s2
> ---+--
>  False | null
> {code}
> 3.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> {{2.x}} would although return same result if executed on a partition that 
> does not exist at all:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 5 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> It _might_ be related to static column LWTs, as I could not reproduce same 
> behaviour with non-static column LWTs. The most recent change was 
> [CASSANDRA-10532], which enabled LWT operations on static columns with 
> partition keys only. -Another possible relation is [CASSANDRA-9842], which 
> removed distinction between {{null}} column and non-existing row.- (striked 
> through since same happens on pre-[CASSANDRA-9842] code.



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

[jira] [Comment Edited] (CASSANDRA-12060) Establish consistent distinction between non-existing partition and NULL value for LWTs on static columns

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-12060 at 9/14/16 12:56 PM:
---

Thanks for reviewing the patch and for elaborate comment.

I agree that having the behaviour consistent with the regular columns makes 
most sense. 

bq. I'm not sure I understand the reason for the change in 
CQL3CasRequest.columnsToRead() 

This was added to make sure that output in 3.x is same as in 2.x: 

{code}
assertRows(execute("BEGIN BATCH " +
   "UPDATE %1$s SET v='foobar' WHERE id=0 AND k='k1'; " 
+
   "UPDATE %1$s SET v='barfoo' WHERE id=0 AND k='k2'; " 
+
   "UPDATE %1$s SET version=3 WHERE id=0 IF version=1; 
" +
   "APPLY BATCH "),
   row(false, 0, "k1", 2));
// vs
// row(false, 0, null, 2));
{code}

bq. I'm not fond of using null for empty partitions since we can just test with 
isEmpty() directly.

Agree. This makes it much cleaner. 

bq. I think the code would be easier to follow if we separated static 
conditions in CQL3CasRequest

True, it is much easier to follow now. Special-casing static clause was quite 
counter-intuitive.

I've ran the dtests locally and they're failing, but they're mostly cosmetic 
(condition is being applied correctly, just returned results differ a bit). Do 
we want to keep the resultset format for LWTs completely same as it was in 
2.x?..

I would also leave {{testConditionalUpdatesWithNonExistingValues}} test to make 
sure we cover both behaviours, given we've had quite a few iterations, so we 
could keep this behaviour well-documented.


was (Author: ifesdjeen):
Thanks for reviewing the patch and for elaborate comment.

I agree that having the behaviour consistent with the regular columns makes 
most sense. 

bq. I'm not sure I understand the reason for the change in 
CQL3CasRequest.columnsToRead() 

This was added to make sure that output in 3.x is same as in 2.x: 

{code}
assertRows(execute("BEGIN BATCH " +
   "UPDATE %1$s SET v='foobar' WHERE id=0 AND k='k1'; " 
+
   "UPDATE %1$s SET v='barfoo' WHERE id=0 AND k='k2'; " 
+
   "UPDATE %1$s SET version=3 WHERE id=0 IF version=1; 
" +
   "APPLY BATCH "),
   row(false, 0, "k1", 2));
// vs
// row(false, 0, null, 2));
{code}

bq. I'm not fond of using null for empty partitions since we can just test with 
isEmpty() directly.

Agree. This makes it much cleaner. 

bq. I think the code would be easier to follow if we separated static 
conditions in CQL3CasRequest

True, it is much easier to follow now. Special-casing static clause was quite 
counter-intuitive.

I've ran the dtests locally and they're failing, but they're mostly cosmetic 
(condition is being applied correctly, just returned results differ a bit). Do 
we want to keep the resultset format for LWTs completely same as it was in 
2.x?..

> Establish consistent distinction between non-existing partition and NULL 
> value for LWTs on static columns
> -
>
> Key: CASSANDRA-12060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12060
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>
> When executing following CQL commands: 
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1' };
> USE test;
> CREATE TABLE testtable (a int, b int, s1 int static, s2 int static, v int, 
> PRIMARY KEY (a, b));
> INSERT INTO testtable (a,b,s1,s2,v) VALUES (2,2,2,null,2);
> DELETE s1 FROM testtable WHERE a = 2 IF s2 IN (10,20,30);
> {code}
> The output is different between {{2.x}} and {{3.x}}:
> 2.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied] | s2
> ---+--
>  False | null
> {code}
> 3.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> {{2.x}} would although return same result if executed on a partition that 
> does not exist at all:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 5 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> It _might_ be related to static column LWTs, as I could not reproduce same 
> behaviour with non-static column LWTs. The most recent change was 
> [CASSANDRA-10532], which enabled LWT operations on static columns with 
> partition keys only. -Another possible relation is [CASSANDRA-9842], which 
> removed distinction between {{null}} column and non-existing row.- (striked 
> through 

[jira] [Commented] (CASSANDRA-12060) Establish consistent distinction between non-existing partition and NULL value for LWTs on static columns

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-12060:
--

bq. This was added to make sure that output in 3.x is same as in 2.x

Slightly confused here. I did noticed that the output of that test differed 
between your branch and after having reverted the changes to 
{{columnsToRead()}}, but it looks that it's our version that was inconsistent 
with 2.x. Namely, your branch returns {{row(false, 0, "k1", 2)}} but it seems 
both 
[2.1|https://github.com/apache/cassandra/blob/cassandra-2.1/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java#L229]
 and 
[2.2|https://github.com/apache/cassandra/blob/cassandra-2.2/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java#L229]
 returns {{row(false, 0, null, 2)}} instead. Am I not looking at the right 
place/missing something?


> Establish consistent distinction between non-existing partition and NULL 
> value for LWTs on static columns
> -
>
> Key: CASSANDRA-12060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12060
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>
> When executing following CQL commands: 
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1' };
> USE test;
> CREATE TABLE testtable (a int, b int, s1 int static, s2 int static, v int, 
> PRIMARY KEY (a, b));
> INSERT INTO testtable (a,b,s1,s2,v) VALUES (2,2,2,null,2);
> DELETE s1 FROM testtable WHERE a = 2 IF s2 IN (10,20,30);
> {code}
> The output is different between {{2.x}} and {{3.x}}:
> 2.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied] | s2
> ---+--
>  False | null
> {code}
> 3.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> {{2.x}} would although return same result if executed on a partition that 
> does not exist at all:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 5 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> It _might_ be related to static column LWTs, as I could not reproduce same 
> behaviour with non-static column LWTs. The most recent change was 
> [CASSANDRA-10532], which enabled LWT operations on static columns with 
> partition keys only. -Another possible relation is [CASSANDRA-9842], which 
> removed distinction between {{null}} column and non-existing row.- (striked 
> through since same happens on pre-[CASSANDRA-9842] code.



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

[jira] [Comment Edited] (CASSANDRA-12060) Establish consistent distinction between non-existing partition and NULL value for LWTs on static columns

[Alex Petrov (JIRA)]

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

Alex Petrov edited comment on CASSANDRA-12060 at 9/14/16 12:41 PM:
---

Thanks for reviewing the patch and for elaborate comment.

I agree that having the behaviour consistent with the regular columns makes 
most sense. 

bq. I'm not sure I understand the reason for the change in 
CQL3CasRequest.columnsToRead() 

This was added to make sure that output in 3.x is same as in 2.x: 

{code}
assertRows(execute("BEGIN BATCH " +
   "UPDATE %1$s SET v='foobar' WHERE id=0 AND k='k1'; " 
+
   "UPDATE %1$s SET v='barfoo' WHERE id=0 AND k='k2'; " 
+
   "UPDATE %1$s SET version=3 WHERE id=0 IF version=1; 
" +
   "APPLY BATCH "),
   row(false, 0, "k1", 2));
// vs
// row(false, 0, null, 2));
{code}

bq. I'm not fond of using null for empty partitions since we can just test with 
isEmpty() directly.

Agree. This makes it much cleaner. 

bq. I think the code would be easier to follow if we separated static 
conditions in CQL3CasRequest

True, it is much easier to follow now. Special-casing static clause was quite 
counter-intuitive.

I've ran the dtests locally and they're failing, but they're mostly cosmetic 
(condition is being applied correctly, just returned results differ a bit). Do 
we want to keep the resultset format for LWTs completely same as it was in 
2.x?..


was (Author: ifesdjeen):
I agree that having the behaviour consistent with the regular columns makes 
most sense. 

bq. I'm not sure I understand the reason for the change in 
CQL3CasRequest.columnsToRead() 

This was added to make sure that output in 3.x is same as in 2.x: 

{code}
assertRows(execute("BEGIN BATCH " +
   "UPDATE %1$s SET v='foobar' WHERE id=0 AND k='k1'; " 
+
   "UPDATE %1$s SET v='barfoo' WHERE id=0 AND k='k2'; " 
+
   "UPDATE %1$s SET version=3 WHERE id=0 IF version=1; 
" +
   "APPLY BATCH "),
   row(false, 0, "k1", 2));
// vs
// row(false, 0, null, 2));
{code}

bq. I'm not fond of using null for empty partitions since we can just test with 
isEmpty() directly.

Agree. This makes it much cleaner. 

bq. I think the code would be easier to follow if we separated static 
conditions in CQL3CasRequest

True, it is much easier to follow now. Special-casing static clause was quite 
counter-intuitive.

I've ran the dtests locally and they're failing, but they're mostly cosmetic 
(condition is being applied correctly, just returned results differ a bit). Do 
we want to keep the resultset format for LWTs completely same as it was in 
2.x?..

> Establish consistent distinction between non-existing partition and NULL 
> value for LWTs on static columns
> -
>
> Key: CASSANDRA-12060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12060
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>
> When executing following CQL commands: 
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1' };
> USE test;
> CREATE TABLE testtable (a int, b int, s1 int static, s2 int static, v int, 
> PRIMARY KEY (a, b));
> INSERT INTO testtable (a,b,s1,s2,v) VALUES (2,2,2,null,2);
> DELETE s1 FROM testtable WHERE a = 2 IF s2 IN (10,20,30);
> {code}
> The output is different between {{2.x}} and {{3.x}}:
> 2.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied] | s2
> ---+--
>  False | null
> {code}
> 3.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> {{2.x}} would although return same result if executed on a partition that 
> does not exist at all:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 5 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> It _might_ be related to static column LWTs, as I could not reproduce same 
> behaviour with non-static column LWTs. The most recent change was 
> [CASSANDRA-10532], which enabled LWT operations on static columns with 
> partition keys only. -Another possible relation is [CASSANDRA-9842], which 
> removed distinction between {{null}} column and non-existing row.- (striked 
> through since same happens on pre-[CASSANDRA-9842] code.



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

[jira] [Commented] (CASSANDRA-12060) Establish consistent distinction between non-existing partition and NULL value for LWTs on static columns

[Alex Petrov (JIRA)]

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

Alex Petrov commented on CASSANDRA-12060:
-

I agree that having the behaviour consistent with the regular columns makes 
most sense. 

bq. I'm not sure I understand the reason for the change in 
CQL3CasRequest.columnsToRead() 

This was added to make sure that output in 3.x is same as in 2.x: 

{code}
assertRows(execute("BEGIN BATCH " +
   "UPDATE %1$s SET v='foobar' WHERE id=0 AND k='k1'; " 
+
   "UPDATE %1$s SET v='barfoo' WHERE id=0 AND k='k2'; " 
+
   "UPDATE %1$s SET version=3 WHERE id=0 IF version=1; 
" +
   "APPLY BATCH "),
   row(false, 0, "k1", 2));
// vs
// row(false, 0, null, 2));
{code}

bq. I'm not fond of using null for empty partitions since we can just test with 
isEmpty() directly.

Agree. This makes it much cleaner. 

bq. I think the code would be easier to follow if we separated static 
conditions in CQL3CasRequest

True, it is much easier to follow now. Special-casing static clause was quite 
counter-intuitive.

I've ran the dtests locally and they're failing, but they're mostly cosmetic 
(condition is being applied correctly, just returned results differ a bit). Do 
we want to keep the resultset format for LWTs completely same as it was in 
2.x?..

> Establish consistent distinction between non-existing partition and NULL 
> value for LWTs on static columns
> -
>
> Key: CASSANDRA-12060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12060
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>
> When executing following CQL commands: 
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'datacenter1': '1' };
> USE test;
> CREATE TABLE testtable (a int, b int, s1 int static, s2 int static, v int, 
> PRIMARY KEY (a, b));
> INSERT INTO testtable (a,b,s1,s2,v) VALUES (2,2,2,null,2);
> DELETE s1 FROM testtable WHERE a = 2 IF s2 IN (10,20,30);
> {code}
> The output is different between {{2.x}} and {{3.x}}:
> 2.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied] | s2
> ---+--
>  False | null
> {code}
> 3.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> {{2.x}} would although return same result if executed on a partition that 
> does not exist at all:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 5 IF s2 = 5;
>  [applied]
> ---
>  False
> {code}
> It _might_ be related to static column LWTs, as I could not reproduce same 
> behaviour with non-static column LWTs. The most recent change was 
> [CASSANDRA-10532], which enabled LWT operations on static columns with 
> partition keys only. -Another possible relation is [CASSANDRA-9842], which 
> removed distinction between {{null}} column and non-existing row.- (striked 
> through since same happens on pre-[CASSANDRA-9842] code.



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

[jira] [Commented] (CASSANDRA-11850) cannot use cql since upgrading python to 2.7.11+

[Anastasios Zouzias (JIRA)]

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

Anastasios Zouzias commented on CASSANDRA-11850:


I run into this problem yesterday.

As of today, Cassandra versions 2.1.16, 2.2.8, 3.0.9, 3.8 (which solve this 
issue) are not released. A workaround is to downgrade python 2.7 to version 
2.7.10 (tested for Cassandra 2.2.7)

> cannot use cql since upgrading python to 2.7.11+
> 
>
> Key: CASSANDRA-11850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11850
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Development
>Reporter: Andrew Madison
>Assignee: Stefania
>  Labels: cqlsh
> Fix For: 2.1.16, 2.2.8, 3.0.9, 3.8
>
>
> OS: Debian GNU/Linux stretch/sid 
> Kernel: 4.5.0-2-amd64 #1 SMP Debian 4.5.4-1 (2016-05-16) x86_64 GNU/Linux
> Python version: 2.7.11+ (default, May  9 2016, 15:54:33)
> [GCC 5.3.1 20160429]
> cqlsh --version: cqlsh 5.0.1
> cassandra -v: 3.5 (also occurs with 3.0.6)
> Issue:
> when running cqlsh, it returns the following error:
> cqlsh -u dbarpt_usr01
> Password: *
> Connection error: ('Unable to connect to any servers', {'odbasandbox1': 
> TypeError('ref() does not take keyword arguments',)})
> I cleared PYTHONPATH:
> python -c "import json; print dir(json); print json.__version__"
> ['JSONDecoder', 'JSONEncoder', '__all__', '__author__', '__builtins__', 
> '__doc__', '__file__', '__name__', '__package__', '__path__', '__version__', 
> '_default_decoder', '_default_encoder', 'decoder', 'dump', 'dumps', 
> 'encoder', 'load', 'loads', 'scanner']
> 2.0.9
> Java based clients can connect to Cassandra with no issue. Just CQLSH and 
> Python clients cannot.
> nodetool status also works.
> Thank you for your help.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-9318:
-

bq. It's possible I'm totally missing a point you and Stefania are trying to 
make, but it seems to me to be the only reasonable way. The timeout is a 
deadline the user asks us to respect, it's the whole point of it, so it should 
always be respected as strictly as possible.

I didn't follow the two issues mentioned above: if that's the end goal, I agree 
we should be strict with it.

bq. that discussion seems to suggest that back-pressure would make it harder 
for C* to respect a reasonable timeout. I'll admit that sounds 
counter-intuitive to me as a functioning back-pressure should make it easier by 
smoothing things over when there is too much pressure.

The load is smoothed on the server, then it depends on how many replicas are 
"in trouble" and how much aggressive clients are. As an example, say the 
timeout is 2s, the request incoming rate at the coordinator is 1000/s, the 
processing rate at replica A is 50/s and at replica B is 1000/s, then with 
CL.ONE (assuming the coordinator is not part of the replica group for 
simplicity):
1) If back-pressure is disabled, we get no client timeouts, but ~900 mutations 
dropped on replica A.
2) If back-pressure is enabled, the back-pressure rate limiting at the 
coordinator is set at 50/s (assuming the SLOW configuration) to smooth the load 
between servers, which means ~900 mutations will end up in client timeouts, and 
it will be the client responsibility to back down to a saner ingestion rate; 
that is, if it keeps ingesting at a higher rate, there's nothing we can do to 
smooth its side of the equation.

In case #2, the client timeout can be seen as a signal for the client to slow 
down, so I'm fine with that (we also hinted in the past at adding more 
back-pressure related information to the exception, but it seems this requires 
a change to the native protocol?). 

That said, this is a bit of an edge case: most of the time, when there is such 
difference between replica responsiveness, it's because of transient 
short-lived events such as GC or compaction spikes, and the back-pressure 
algorithm will not catch that, as it's meant to react to continuous overloading.

On the other hand, when the node is continuously overloaded by clients, most of 
the time all replicas will suffer from that, and the back-pressure will smooth 
out the load; in such case, the rate of client timeouts shouldn't really change 
much, but I'll do another test with such new changes.

Hope this helps clarifying things a little bit.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Commented] (CASSANDRA-12060) Establish consistent distinction between non-existing partition and NULL value for LWTs on static columns

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-12060:
--

I'll have to apologize here because while reviewing this I'm realizing that 
I've been confused and have pushed for the wrong thing.

My confusion had to do with the fact that CQL doesn't behave as I though it 
did. Let me explain. This ticket and CASSANDRA-9842 are about what differences 
CAS queries with conditions on static columns make between existing and 
non-existing partitions. For that, my guideline was to make it consistent with 
how CAS queries with conditions on regular columns differenciate between 
existing and non-existing rows, and that where I was wrong.

Let's consider the following example:
{noformat}
CREATE TABLE test (k int, t int, v int, PRIMARY KEY (k, t));
SELECT v FROM test WHERE k = 0 AND t = 0;
>  v
> --
>
> (0 rows)
INSERT INTO test(k, t) VALUES (0, 0);
SELECT v FROM test WHERE k = 0 AND t = 0;
>  v
> --
>  null
>
> (1 rows)
UPDATE test SET v = 42 WHERE k = 0 AND t = 1 IF v = 1;  // Note we try updating 
another row
>  [applied]
> ---
>  False
UPDATE test SET v = 42 WHERE k = 0 AND t = 0 IF v = 1; // The row we've 
inserted before, but v is null
>  [applied] | v
> ---+--
>  False | null
{noformat}
Both in SELECT and in CAS queries result set, we make a difference between a 
row existing or not existing. For some reason, I though this difference 
somewhat carried on to whether a {{IF v = null}} would apply (or any {{IF v != 
}} condition). I was sure that it was applied if the row existed but 
had no value for {{v}} but did *not* applied if the row didn't existed at all. 
In other words, what I _though_ we had was:
{noformat}
UPDATE test SET v = 42 WHERE k = 0 AND t = 1 IF v = null; // Trying to updated 
a non existing row
>  [applied]
> ---
>  False
UPDATE test SET v = 42 WHERE k = 0 AND t = 0 IF v = null; // The row exist and 
v is null
>  [applied]
> ---
>   True
{noformat}
and I advocated we did the same for static columns and existing/non-existing 
partitions. But that's *not* how it works and the first query above does apply. 
That is, even though we always make a difference in result sets between 
existing row (but with null value) and non-existing row, we don't make one when 
evaluating if a {{IF v = null}} condition applies.

So anyway, what semantic would be better in theory doesn't matter much. The way 
{{IF v = null}} currently works for normal column is that it makes no 
difference between the row existing (and having no value for v) or not existing 
and it's probably too late to change that, so we should make that work 
consistently for static column and hence you should just have ignored me on 
this ticket since that's how it works in 3.0 after CASSANDRA-9842.

With that all said, we still should do what this ticket initiall sets to do: we 
should make that existing versus not existing partition difference for static 
columns in CAS result sets because that's how it works for rows/normal columns 
and we should be consistent.

Doing that last part requires most of the linked patch, though I have the 
following remarks on said patch:
* I'm not sure I understand the reason for the change in 
{{CQL3CasRequest.columnsToRead()}}. In particular, the comment talks about 
having to query a row, but that method is about which columns we bother 
fetching, not which row we query.
* I'm not fond of using {{null}} for empty partitions since we can just test 
with {{isEmpty()}} directly. Granted, the current code is confusing as 
{{appliesTo()}} test for {{null}} even though it's neither passed currently and 
that's really oversight from CASSANDRA-8099. I think we should stick to 
{{isEmpty()}} but remove the useless code.
* Regarding querying the first row of a partition when we only have static 
conditions, I think the code would be easier to follow if we separated static 
conditions in {{CQL3CasRequest}}. In fact, once we do that, we can also use 
names queries for "normal" conditions (instead of doing slices of one row, the 
former being potentially more optimized), which is not all that related to this 
patch tbh, but is kind of an oversight of the code so we might as well fix it 
while we're at it.

Anyway, as I felt bad about the back and forth on this, I took the liberty to 
made the changes related to what's above:
| [12060-3.0-v2|https://github.com/pcmanus/cassandra/commits/12060-3.0-v2] | 
[utests|http://cassci.datastax.com/job/pcmanus-12060-3.0-v2-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-12060-3.0-v2-dtest] |
| [12060-trunk-v2|https://github.com/pcmanus/cassandra/commits/12060-trunk-v2] 
| [utests|http://cassci.datastax.com/job/pcmanus-12060-trunk-v2-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-12060-trunk-v2-dtest] |


> 

[jira] [Updated] (CASSANDRA-12499) Row cache does not cache partitions on tables without clustering keys

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-12499:
-
Status: Open  (was: Patch Available)

> Row cache does not cache partitions on tables without clustering keys
> -
>
> Key: CASSANDRA-12499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12499
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: Performance
>
> {code}
> MLSEA-JJIRSA01:~ jjirsa$ ccm start
> MLSEA-JJIRSA01:~ jjirsa$ echo "DESCRIBE TABLE test.test; " | ccm node1 cqlsh
> CREATE TABLE test.test (
> id int PRIMARY KEY,
> v text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': '100'}
> 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';
> MLSEA-JJIRSA01:~ jjirsa$ ccm node1 nodetool info | grep Row
> Row Cache  : entries 0, size 0 bytes, capacity 100 MiB, 0 hits, 0 
> requests, NaN recent hit rate, 0 save period in seconds
> MLSEA-JJIRSA01:~ jjirsa$ echo "INSERT INTO test.test(id,v) VALUES(1, 'a'); " 
> | ccm node1 cqlsh
> MLSEA-JJIRSA01:~ jjirsa$ echo "SELECT * FROM test.test WHERE id=1; " | ccm 
> node1 cqlsh
>  id | v
> +---
>   1 | a
> (1 rows)
> MLSEA-JJIRSA01:~ jjirsa$ ccm node1 nodetool info | grep Row
> Row Cache  : entries 0, size 0 bytes, capacity 100 MiB, 0 hits, 0 
> requests, NaN recent hit rate, 0 save period in seconds
> MLSEA-JJIRSA01:~ jjirsa$ echo "SELECT * FROM test.test WHERE id=1; " | ccm 
> node1 cqlsh
>  id | v
> +---
>   1 | a
> (1 rows)
> MLSEA-JJIRSA01:~ jjirsa$ ccm node1 nodetool info | grep Row
> Row Cache  : entries 0, size 0 bytes, capacity 100 MiB, 0 hits, 0 
> requests, NaN recent hit rate, 0 save period in seconds
> MLSEA-JJIRSA01:~ jjirsa$
> {code}



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

[jira] [Assigned] (CASSANDRA-12590) Segfault reading secondary index

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe reassigned CASSANDRA-12590:
---

Assignee: Sam Tunnicliffe

> Segfault reading secondary index
> 
>
> Key: CASSANDRA-12590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12590
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: Occurs on Cassandra 3.5 and 3.7
>Reporter: Cameron Zemek
>Assignee: Sam Tunnicliffe
>
> Getting segfaults when reading secondary index as follows:
> J 9272 C2 
> org.apache.cassandra.dht.LocalPartitioner$LocalToken.compareTo(Lorg/apache/cassandra/dht/Token;)I
>  (53 bytes) @ 0x7fd7354749b7 [0x7fd735474840+0x177]
> J 5661 C2 org.apache.cassandra.db.DecoratedKey.compareTo(Ljava/lang/Object;)I 
> (9 bytes) @ 0x7fd7351b35b8 [0x7fd7351b3440+0x178]
> J 14205 C2 
> java.util.concurrent.ConcurrentSkipListMap.doGet(Ljava/lang/Object;)Ljava/lang/Object;
>  (142 bytes) @ 0x7fd736404dd8 [0x7fd736404cc0+0x118]
> J 17764 C2 
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(Lorg/apache/cassandra/db/ColumnFamilyStore;)Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;
>  (635 bytes) @ 0x7fd736e09638 [0x7fd736e08720+0xf18]
> J 17808 C2 
> org.apache.cassandra.index.internal.CassandraIndexSearcher.search(Lorg/apache/cassandra/db/ReadExecutionController;)Lorg/apache/cassandra/db/partitions/UnfilteredPartitionIterator;
>  (68 bytes) @ 0x7fd736e01a48 [0x7fd736e012a0+0x7a8]
> J 14217 C2 
> org.apache.cassandra.db.ReadCommand.executeLocally(Lorg/apache/cassandra/db/ReadExecutionController;)Lorg/apache/cassandra/db/partitions/UnfilteredPartitionIterator;
>  (219 bytes) @ 0x7fd736417c1c [0x7fd736416fa0+0xc7c]
> J 14585 C2 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow()V 
> (337 bytes) @ 0x7fd736541e6c [0x7fd736541d60+0x10c]
> J 14584 C2 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run()V 
> (48 bytes) @ 0x7fd7357957b4 [0x7fd735795760+0x54]
> J 9648% C2 org.apache.cassandra.concurrent.SEPWorker.run()V (253 bytes) @ 
> 0x7fd735938d8c [0x7fd7359356e0+0x36ac]
> Which I have translated to the codepath:
> org.apache.cassandra.dht.LocalPartitioner (Line 139)
> org.apache.cassandra.db.DecoratedKey (Line 85)
> java.util.concurrent.ConcurrentSkipListMap (Line 794)
> org.apache.cassandra.db.SinglePartitionReadCommand (Line 498)
> org.apache.cassandra.index.internal.CassandraIndexSearcher (Line 60)
> org.apache.cassandra.db.ReadCommand (Line 367)



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

[jira] [Commented] (CASSANDRA-12237) Cassandra stress graphing is broken

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-12237:
--

Sorry for the delay in committing this but I was about to and there is now a 
bunch of merge conflict and I don't feel too confident with either the patch or 
the stress code. Would you mind rebasing?

> Cassandra stress graphing is broken
> ---
>
> Key: CASSANDRA-12237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12237
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Christopher Batey
>Assignee: Christopher Batey
> Fix For: 3.x
>
>
> Cassandra stress relies on a tmp file with the stress output so it can parse 
> it and put it the the graph html.
> However the contents of this file is now broken:
> {code}
> Sleeping 2s...Sleeping 2s...
> Sleeping 2s...
> Warming up WRITE with 5 iterations...Warming up WRITE with 5 
> iterations...
> Warming up WRITE with 5 iterations...
> Running WRITE with 500 threads 10 secondsRunning WRITE with 500 threads 10 
> seconds
> Running WRITE with 500 threads 10 seconds
> ...
> {code}
> This is as we create a {code}MultiPrintStream{code} that inherits from 
> {code}PrintWriter{code} and then delegate the call to super as well as a list 
> of other PrintWriters
> The call to super for println comes back into our print method so every line 
> gets logged multiple times as we do the for (PrintStream s: newStreams) many 
> times.
> We can change this to use composition and use our own interface if we want to 
> use a composite for logging the results
> This results in the parsing of this file not quite working and the aggregate 
> stats not working in produced graphs.



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

[jira] [Commented] (CASSANDRA-12590) Segfault reading secondary index

[Cameron Zemek (JIRA)]

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

Cameron Zemek commented on CASSANDRA-12590:
---

Hey Sam.

It was previously on 3.5 then upgraded to 3.7. So don't have anything on 
earlier versions of 3.x

{quote}
How feasible is it for you to deploy a patched version and monitor for 
re-occurrences?
{quote}

Yeah I already deployed patched version with my suggested fix some days ago and 
since then have had 0 Last written key exceptions and 0 segfaults.

In another environment I have deployed your suggested change (since it 
generates less garbage) and so far no occurrences either.

I definitely think we on the right track here. Do you have any ideas on how we 
could make a test that reproduces the issue? Do you think the segfault is when 
it reads a byte buffer that points to memory that Cassandra no longer owns 
cause it freed it?

> Segfault reading secondary index
> 
>
> Key: CASSANDRA-12590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12590
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: Occurs on Cassandra 3.5 and 3.7
>Reporter: Cameron Zemek
>
> Getting segfaults when reading secondary index as follows:
> J 9272 C2 
> org.apache.cassandra.dht.LocalPartitioner$LocalToken.compareTo(Lorg/apache/cassandra/dht/Token;)I
>  (53 bytes) @ 0x7fd7354749b7 [0x7fd735474840+0x177]
> J 5661 C2 org.apache.cassandra.db.DecoratedKey.compareTo(Ljava/lang/Object;)I 
> (9 bytes) @ 0x7fd7351b35b8 [0x7fd7351b3440+0x178]
> J 14205 C2 
> java.util.concurrent.ConcurrentSkipListMap.doGet(Ljava/lang/Object;)Ljava/lang/Object;
>  (142 bytes) @ 0x7fd736404dd8 [0x7fd736404cc0+0x118]
> J 17764 C2 
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(Lorg/apache/cassandra/db/ColumnFamilyStore;)Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;
>  (635 bytes) @ 0x7fd736e09638 [0x7fd736e08720+0xf18]
> J 17808 C2 
> org.apache.cassandra.index.internal.CassandraIndexSearcher.search(Lorg/apache/cassandra/db/ReadExecutionController;)Lorg/apache/cassandra/db/partitions/UnfilteredPartitionIterator;
>  (68 bytes) @ 0x7fd736e01a48 [0x7fd736e012a0+0x7a8]
> J 14217 C2 
> org.apache.cassandra.db.ReadCommand.executeLocally(Lorg/apache/cassandra/db/ReadExecutionController;)Lorg/apache/cassandra/db/partitions/UnfilteredPartitionIterator;
>  (219 bytes) @ 0x7fd736417c1c [0x7fd736416fa0+0xc7c]
> J 14585 C2 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow()V 
> (337 bytes) @ 0x7fd736541e6c [0x7fd736541d60+0x10c]
> J 14584 C2 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run()V 
> (48 bytes) @ 0x7fd7357957b4 [0x7fd735795760+0x54]
> J 9648% C2 org.apache.cassandra.concurrent.SEPWorker.run()V (253 bytes) @ 
> 0x7fd735938d8c [0x7fd7359356e0+0x36ac]
> Which I have translated to the codepath:
> org.apache.cassandra.dht.LocalPartitioner (Line 139)
> org.apache.cassandra.db.DecoratedKey (Line 85)
> java.util.concurrent.ConcurrentSkipListMap (Line 794)
> org.apache.cassandra.db.SinglePartitionReadCommand (Line 498)
> org.apache.cassandra.index.internal.CassandraIndexSearcher (Line 60)
> org.apache.cassandra.db.ReadCommand (Line 367)



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

svn commit: r1760665 - in /cassandra/site: publish/community/ publish/doc/3.7/configuration/ publish/doc/3.7/operating/ publish/doc/latest/configuration/ publish/doc/latest/operating/ publish/download

[slebresne]

Author: slebresne
Date: Wed Sep 14 09:42:28 2016
New Revision: 1760665

URL: http://svn.apache.org/viewvc?rev=1760665=rev
Log:
Don't convert newlines in markdown to  tags, it looks bad

Modified:
cassandra/site/publish/community/index.html
cassandra/site/publish/doc/3.7/configuration/cassandra_config_file.html
cassandra/site/publish/doc/3.7/operating/metrics.html
cassandra/site/publish/doc/latest/configuration/cassandra_config_file.html
cassandra/site/publish/doc/latest/operating/metrics.html
cassandra/site/publish/download/index.html
cassandra/site/src/_config.yml

Modified: cassandra/site/publish/community/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/community/index.html?rev=1760665=1760664=1760665=diff
==
--- cassandra/site/publish/community/index.html (original)
+++ cassandra/site/publish/community/index.html Wed Sep 14 09:42:28 2016
@@ -98,13 +98,13 @@
 Discussion and questions on Cassandra’s usage and development happens 
mainly on the following mailing lists:
 
 
-  http://www.mail-archive.com/user@cassandra.apache.org/;>Users: 
General mailing list for user questions and discussions. This is also where new 
releases are announced
+  http://www.mail-archive.com/user@cassandra.apache.org/;>Users: 
General mailing list for user questions and discussions. This is also where new 
releases are announced
 (subscribe
 | unsubscribe
 | https://lists.apache.org/list.html?u...@cassandra.apache.org;>Archives).
-  http://www.mail-archive.com/dev@cassandra.apache.org/;>Developers: 
Questions and discussions related to Cassandra development
+  http://www.mail-archive.com/dev@cassandra.apache.org/;>Developers: 
Questions and discussions related to Cassandra development
 (subscribe
 | unsubscribe
 | https://lists.apache.org/list.html?d...@cassandra.apache.org;>Archives).
-  http://www.mail-archive.com/commits@cassandra.apache.org/;>Commits: 
Notification on commits done to the source
-repository and on https://issues.apache.org/jira/browse/CASSANDRA;>JIRA updates. This 
is a fairly noisy mailing list
-mostly useful for Cassandra developers and those who would like to keep close 
tabs on Cassandra’s development
+  http://www.mail-archive.com/commits@cassandra.apache.org/;>Commits: 
Notification on commits done to the source
+repository and on https://issues.apache.org/jira/browse/CASSANDRA;>JIRA updates. This 
is a fairly noisy mailing list
+mostly useful for Cassandra developers and those who would like to keep close 
tabs on Cassandra’s development
 (subscribe
 | unsubscribe
 | https://lists.apache.org/list.html?commits@cassandra.apache.org;>Archives).
 
 
@@ -120,29 +120,29 @@ mostly useful for Cassandra developers a
 
 Stack Overflow
 
-You can also check the http://stackoverflow.com/questions/tagged/cassandra;>QA about using 
Cassandra on Stack
+You can also check the http://stackoverflow.com/questions/tagged/cassandra;>QA about using 
Cassandra on Stack
 Overflow.
 
 News, articles and user groups
 
-You can find a number of news, articles and use cases, as well a links to 
Cassandra user groups on the http://planetcassandra.org/;>Planet
+You can find a number of news, articles and use cases, as well a links to 
Cassandra user groups on the http://planetcassandra.org/;>Planet
 Cassandra (not endorsed by Apache).
 
 Dead Trees
 
 
-  http://shop.oreilly.com/product/0636920043041.do;>Cassandra: 
The Definitive Guide, 2nd Edition, by Jeff Carpenter and
+  http://shop.oreilly.com/product/0636920043041.do;>Cassandra: 
The Definitive Guide, 2nd Edition, by Jeff Carpenter and
 Eben Hewitt. Updated for Cassandra 3.0
 
 
 Reporting bugs
 
-If you encounter a problem with Cassandra, the first places to ask for help 
are the user mailing list
+If you encounter a problem with Cassandra, the first places to ask for help 
are the user mailing list
 and the #cassandra IRC 
channel.
 
-If, after having asked for help, you suspect that you have found a bug in 
Cassandra, you should report it by opening a
-ticket through the https://issues.apache.org/jira/browse/CASSANDRA;>Apache Cassandra 
JIRA. Please provide as much
-details as you can on your problem, and don’t forget to indicate which 
version of Cassandra you are running and on which
+If, after having asked for help, you suspect that you have found a bug in 
Cassandra, you should report it by opening a
+ticket through the https://issues.apache.org/jira/browse/CASSANDRA;>Apache Cassandra 
JIRA. Please provide as much
+details as you can on your problem, and don’t forget to indicate which 
version of Cassandra you are running and on which
 environment.
 
   

Modified: 
cassandra/site/publish/doc/3.7/configuration/cassandra_config_file.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/doc/3.7/configuration/cassandra_config_file.html?rev=1760665=1760664=1760665=diff

[jira] [Commented] (CASSANDRA-11985) 2.0.x leaks file handles (Again)

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-11985:
--

bq. but it will be great if you can tell which version of Cassandra did your 
team has made changes

We've made many changes related to tracking open files, some of it in 2.1 and 
some in 2.2 only. My advise would be to upgrade to 2.2.7, but you can also 
upgrade to 2.1.15 and see if it's enough to solve that particular problem for 
you if you prefer.

> 2.0.x leaks file handles (Again)
> 
>
> Key: CASSANDRA-11985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11985
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Unix kernel-2.6.32-431.56.1.el6.x86_64, Cassandra 2.0.14
>Reporter: Amit Singh Chowdhery
>Priority: Critical
>  Labels: Compaction
>
> We are running Cassandra 2.0.14 in production environment and disk usage is 
> very high. On investigating it further we found that there are around 4-5 
> files(~ 150 GB) in stuck mode.
> Command Fired : lsof /var/lib/cassandra | grep -i deleted 
> Output : 
> java12158 cassandra  308r   REG   8,16  34396638044 12727268 
> /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-16481-Data.db
>  (deleted)
> java12158 cassandra  327r   REG   8,16 101982374806 12715102 
> /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-126861-Data.db
>  (deleted)
> java12158 cassandra  339r   REG   8,16  12966304784 12714010 
> /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-213548-Data.db
>  (deleted)
> java12158 cassandra  379r   REG   8,16  15323318036 12714957 
> /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-182936-Data.db
>  (deleted)
> we are not able to see these files in any directory. This is somewhat similar 
> to CASSANDRA-6275 which is fixed but still issue is there on higher version. 
> Also in logs no error related to compaction is reported.
> so could any one of you please provide any suggestion how to counter this. 
> Restarting Cassandra is one solution but this issue keeps on occurring so we 
> cannot restart production machine is not recommended so frequently.
> Also we know that this version is not supported but there is high probability 
> that it can occur in higher version too.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-9318:
-

bq. If back pressure kicks in, then it may be that mutations are applied by all 
replicas but the application receives a timeout nonetheless.

That's *not* specific to back-pressure and can perfectly happen today and 
that's fine. Again, if your application *require* that the server answers 
within say 500ms, the server should do so and not randomly fail that deadline 
because back-pressure kicks-in. If the deadline you set as a user is too low 
and you get timeouts too often, then it's your problem and you should either 
reconsider your deadline because it's unrealistic, or increase your cluster 
capacity. But I genuinely don't understand how not doing what the user 
explicitly asks us to do would ever make sense.

bq. 1) We keep the timeout strict and change the back-pressure implementation 
to wait at most the given timeout, and fail otherwise.

It's possible I'm totally missing a point you and Stefania are trying to make, 
but it seems to me to be the only reasonable way. The timeout is a deadline the 
user asks us to respect, it's the whole point of it, so it should always be 
respected as strictly as possible. If the user sets it too low, his mistake 
(and don't get me wrong, we should certainly educate user to avoid that mistake 
through documentation as much as possible).

More generally though, that discussion seems to suggest that back-pressure 
would make it harder for C* to respect a reasonable timeout. I'll admit that 
sounds counter-intuitive to me as a functioning back-pressure should make it 
_easier_ by smoothing things over when there is too much pressure.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Commented] (CASSANDRA-12590) Segfault reading secondary index

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-12590:
-

bq. memtable_allocation_type: offheap_objects

So using direct, off heap memory as opposed to slabs. This feature was dropped 
from early 3.x versions and only re-introduced in 3.4 by CASSANDRA-9472. Did 
the cluster(s) exhibiting this problem ever run a 3.x < 3.4 and if so, do you 
know if the issue manifested then also? 

bq. unfortunately it is not easy to reproduce

:) pretty much what I was expecting. How feasible is it for you to deploy a 
patched version and monitor for re-occurrences?

> Segfault reading secondary index
> 
>
> Key: CASSANDRA-12590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12590
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
> Environment: Occurs on Cassandra 3.5 and 3.7
>Reporter: Cameron Zemek
>
> Getting segfaults when reading secondary index as follows:
> J 9272 C2 
> org.apache.cassandra.dht.LocalPartitioner$LocalToken.compareTo(Lorg/apache/cassandra/dht/Token;)I
>  (53 bytes) @ 0x7fd7354749b7 [0x7fd735474840+0x177]
> J 5661 C2 org.apache.cassandra.db.DecoratedKey.compareTo(Ljava/lang/Object;)I 
> (9 bytes) @ 0x7fd7351b35b8 [0x7fd7351b3440+0x178]
> J 14205 C2 
> java.util.concurrent.ConcurrentSkipListMap.doGet(Ljava/lang/Object;)Ljava/lang/Object;
>  (142 bytes) @ 0x7fd736404dd8 [0x7fd736404cc0+0x118]
> J 17764 C2 
> org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(Lorg/apache/cassandra/db/ColumnFamilyStore;)Lorg/apache/cassandra/db/rows/UnfilteredRowIterator;
>  (635 bytes) @ 0x7fd736e09638 [0x7fd736e08720+0xf18]
> J 17808 C2 
> org.apache.cassandra.index.internal.CassandraIndexSearcher.search(Lorg/apache/cassandra/db/ReadExecutionController;)Lorg/apache/cassandra/db/partitions/UnfilteredPartitionIterator;
>  (68 bytes) @ 0x7fd736e01a48 [0x7fd736e012a0+0x7a8]
> J 14217 C2 
> org.apache.cassandra.db.ReadCommand.executeLocally(Lorg/apache/cassandra/db/ReadExecutionController;)Lorg/apache/cassandra/db/partitions/UnfilteredPartitionIterator;
>  (219 bytes) @ 0x7fd736417c1c [0x7fd736416fa0+0xc7c]
> J 14585 C2 
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow()V 
> (337 bytes) @ 0x7fd736541e6c [0x7fd736541d60+0x10c]
> J 14584 C2 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run()V 
> (48 bytes) @ 0x7fd7357957b4 [0x7fd735795760+0x54]
> J 9648% C2 org.apache.cassandra.concurrent.SEPWorker.run()V (253 bytes) @ 
> 0x7fd735938d8c [0x7fd7359356e0+0x36ac]
> Which I have translated to the codepath:
> org.apache.cassandra.dht.LocalPartitioner (Line 139)
> org.apache.cassandra.db.DecoratedKey (Line 85)
> java.util.concurrent.ConcurrentSkipListMap (Line 794)
> org.apache.cassandra.db.SinglePartitionReadCommand (Line 498)
> org.apache.cassandra.index.internal.CassandraIndexSearcher (Line 60)
> org.apache.cassandra.db.ReadCommand (Line 367)



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-9318:
-

[~slebresne], I do understand your concerns. I see [~Stefania] largely answered 
them already, but it all depends on how strict we want to be in regards to 
CASSANDRA-12256 and CASSANDRA-2848, so I propose one of the following:
1) We keep the timeout strict and change the back-pressure implementation to 
wait at most the given timeout, and fail otherwise.
2) We add a back-pressure configuration parameter to have the users choose if 
they want a strict timeout even in case of back-pressure, or they want it 
"adaptive".

Thoughts?



> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Commented] (CASSANDRA-11985) 2.0.x leaks file handles (Again)

[Amit Singh Chowdhery (JIRA)]

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

Amit Singh Chowdhery commented on CASSANDRA-11985:
--

Thanks a lot Sylvain Lebresne for the update, 

but it will be great if you can tell which version of Cassandra did your team 
has made changes so that we can give upgrade advice to customer who are running 
this system in Production. It will of great help to us.

Hoping to see positive reply from you.

> 2.0.x leaks file handles (Again)
> 
>
> Key: CASSANDRA-11985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11985
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Unix kernel-2.6.32-431.56.1.el6.x86_64, Cassandra 2.0.14
>Reporter: Amit Singh Chowdhery
>Priority: Critical
>  Labels: Compaction
>
> We are running Cassandra 2.0.14 in production environment and disk usage is 
> very high. On investigating it further we found that there are around 4-5 
> files(~ 150 GB) in stuck mode.
> Command Fired : lsof /var/lib/cassandra | grep -i deleted 
> Output : 
> java12158 cassandra  308r   REG   8,16  34396638044 12727268 
> /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-16481-Data.db
>  (deleted)
> java12158 cassandra  327r   REG   8,16 101982374806 12715102 
> /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-126861-Data.db
>  (deleted)
> java12158 cassandra  339r   REG   8,16  12966304784 12714010 
> /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-213548-Data.db
>  (deleted)
> java12158 cassandra  379r   REG   8,16  15323318036 12714957 
> /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-182936-Data.db
>  (deleted)
> we are not able to see these files in any directory. This is somewhat similar 
> to CASSANDRA-6275 which is fixed but still issue is there on higher version. 
> Also in logs no error related to compaction is reported.
> so could any one of you please provide any suggestion how to counter this. 
> Restarting Cassandra is one solution but this issue keeps on occurring so we 
> cannot restart production machine is not recommended so frequently.
> Also we know that this version is not supported but there is high probability 
> that it can occur in higher version too.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9318:
-

If back pressure kicks in, then it may be that mutations are applied by all 
replicas but the application receives a timeout nonetheless. The timeout may 
even be already expired after back-pressure is applied but before sending 
mutations to the replicas. So in this case, I think it would make sense to have 
a timeout long enough to take into account the effects of back-pressure when 
the system is overloaded.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Issue Comment Deleted] (CASSANDRA-12232) Add +=/-= shortcut syntax

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-12232:

Comment: was deleted

(was: As a bonus, we're getting shortcut syntax for counters as well "for 
free". I've covered this path with tests as well.

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

> Add +=/-= shortcut syntax
> -
>
> Key: CASSANDRA-12232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12232
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
>Priority: Minor
>
> For collections and counters, the current syntax to add/remove elements is:
> {noformat}
> UPDATE foo SET myCollection = myCollection + ...;
> {noformat}
> which is fine, though it's already tad annoying to have to repeat 
> {{myCollection}}. 
> But moving forward, with tickets CASSANDRA-7826, we'll start being able to 
> add to nested collections and we'll end up with queries like:
> {noformat}
> UPDATE foo SET myCollection['someElement']['otherElemnt'] = 
> myCollection['someElement']['otherElemnt'] + ...;
> {noformat}
> where the repetition is starting to be really annoying and it makes the query 
> less readable.
> It's trivial however to add a {{+=}}/{{-=}} shortcut syntax which would read 
> instead:
> {noformat}
> UPDATE foo SET myCollection['someElement']['otherElemnt'] += ...;
> {noformat}
> As this would just be syntactic sugar, it only requires a few minor addition 
> to the grammar and this would be completely optional: if some users prefer 
> the verbose syntax, that's fine.
> Also note that while this will be even more useful after things like 
> CASSANDRA-7826, it's already a nice to have today so it's not dependent on 
> that latter ticket in any way.



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

[jira] [Updated] (CASSANDRA-12232) Add +=/-= shortcut syntax

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-12232:

Status: Open  (was: Patch Available)

> Add +=/-= shortcut syntax
> -
>
> Key: CASSANDRA-12232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12232
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
>Priority: Minor
>
> For collections and counters, the current syntax to add/remove elements is:
> {noformat}
> UPDATE foo SET myCollection = myCollection + ...;
> {noformat}
> which is fine, though it's already tad annoying to have to repeat 
> {{myCollection}}. 
> But moving forward, with tickets CASSANDRA-7826, we'll start being able to 
> add to nested collections and we'll end up with queries like:
> {noformat}
> UPDATE foo SET myCollection['someElement']['otherElemnt'] = 
> myCollection['someElement']['otherElemnt'] + ...;
> {noformat}
> where the repetition is starting to be really annoying and it makes the query 
> less readable.
> It's trivial however to add a {{+=}}/{{-=}} shortcut syntax which would read 
> instead:
> {noformat}
> UPDATE foo SET myCollection['someElement']['otherElemnt'] += ...;
> {noformat}
> As this would just be syntactic sugar, it only requires a few minor addition 
> to the grammar and this would be completely optional: if some users prefer 
> the verbose syntax, that's fine.
> Also note that while this will be even more useful after things like 
> CASSANDRA-7826, it's already a nice to have today so it's not dependent on 
> that latter ticket in any way.



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

[jira] [Updated] (CASSANDRA-12202) LongLeveledCompactionStrategyTest flapping in 2.1, 2.2, 3.0

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson updated CASSANDRA-12202:

Status: Patch Available  (was: Open)

> LongLeveledCompactionStrategyTest flapping in 2.1, 2.2, 3.0
> ---
>
> Key: CASSANDRA-12202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12202
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> We actually fixed this for 3.7+ in CASSANDRA-11657, need to backport that fix 
> to 2.1+



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-9318:
-

bq. If we don't do this, then users have to manually increase the timeout when 
enabling back-pressure, by an amount of time that is not known a priori.

Why? Again, we want the timeout to mean, in the context of CASSANDRA-12256 and 
CASSANDRA-2848, is an upper on the server answering to the application (even if 
that means giving up). In other words, the timeout is about what the 
application needs, and that shouldn't be influenced by having back-pressure on 
or not. Besides, back-pressure should be largely transparent from the user 
point of view, at least as long as nothing goes too bad (and it should 
hopefully make things better otherwise, not worse), so it makes no sense from 
the user point of view  to have to bump the timeout just because back-pressure 
is enabled.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9318:
-

bq.  I don't why having that being violated when back-pressure would make 
sense. It just seem like a gotcha for users that I'd rather avoid.

If we don't do this, then users have to manually increase the timeout when 
enabling back-pressure, by an amount of time that is not known a priori. So 
both scenarios are not ideal.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Updated] (CASSANDRA-12641) False positive when checking if the user is root

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne updated CASSANDRA-12641:
-
Priority: Minor  (was: Major)

> False positive when checking if the user is root
> 
>
> Key: CASSANDRA-12641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12641
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Matt Wringe
>Priority: Minor
>
> Cassandra will fail to start if it thinks its running as the Root user. It 
> does so by checking if the users uid or gid is 0:
> https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L269
> The problem is that a gid of 0 doesn't really mean anything in terms of 
> security. It does not mean that the user has root privileges or any other 
> special permissions.
> If you are running in an environment where the group id is 0 (such as certain 
> containerized environments) then you can run into this false positive and 
> have to add the -R option to by pass the check.
> It would be nice to be able to just run Cassandra in these environments 
> without having to add the -R option.



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

[jira] [Commented] (CASSANDRA-12202) LongLeveledCompactionStrategyTest flapping in 2.1, 2.2, 3.0

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-12202:
-

last failure was that I didnt send the mutations to the correct cf - fixed and 
repushed to the branches above, 
[multiplexed|http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-12202-2.2-multiplex-testall/]
 run was fine (it says it failed, but no tests actually failed). Also 
retriggered the standard test runs

> LongLeveledCompactionStrategyTest flapping in 2.1, 2.2, 3.0
> ---
>
> Key: CASSANDRA-12202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12202
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> We actually fixed this for 3.7+ in CASSANDRA-11657, need to backport that fix 
> to 2.1+



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-9318:
-

bq. with back-pressure enabled the time spent paused in back-pressure is not 
counted against

I don't understand that rational. The goal of CASSANDRA-12256 is to make sure 
client can rely on the timeout being an upper bound on when they get an answer 
from the server. I don't why having that being violated when back-pressure 
would make sense. It just seem like a gotcha for users that I'd rather avoid.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9318:
-

Sounds good, thanks.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-9318:
-

bq. queryStartNanoTime was introduced by CASSANDRA-12256

Yep, I was just looking at that.

bq. Should we increase the timeout by the amount of time spent waiting for the 
backpressure strategy

Yes, this seems the best solution, plus documenting it, that is the fact that 
with back-pressure enabled the time spent paused in back-pressure is not 
counted against.

bq. Also, it should not be changed if the backpressure strategy is disabled.

I changed it regardless in the previous solution for consistency, but I agree 
that post CASSANDRA-12256 it should be changed only in case of back-pressure.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Updated] (CASSANDRA-12232) Add +=/-= shortcut syntax

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-12232:

Status: Patch Available  (was: Open)

As a bonus, we're getting shortcut syntax for counters as well "for free". I've 
covered this path with tests as well.

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

> Add +=/-= shortcut syntax
> -
>
> Key: CASSANDRA-12232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12232
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Sylvain Lebresne
>Assignee: Alex Petrov
>Priority: Minor
>
> For collections and counters, the current syntax to add/remove elements is:
> {noformat}
> UPDATE foo SET myCollection = myCollection + ...;
> {noformat}
> which is fine, though it's already tad annoying to have to repeat 
> {{myCollection}}. 
> But moving forward, with tickets CASSANDRA-7826, we'll start being able to 
> add to nested collections and we'll end up with queries like:
> {noformat}
> UPDATE foo SET myCollection['someElement']['otherElemnt'] = 
> myCollection['someElement']['otherElemnt'] + ...;
> {noformat}
> where the repetition is starting to be really annoying and it makes the query 
> less readable.
> It's trivial however to add a {{+=}}/{{-=}} shortcut syntax which would read 
> instead:
> {noformat}
> UPDATE foo SET myCollection['someElement']['otherElemnt'] += ...;
> {noformat}
> As this would just be syntactic sugar, it only requires a few minor addition 
> to the grammar and this would be completely optional: if some users prefer 
> the verbose syntax, that's fine.
> Also note that while this will be even more useful after things like 
> CASSANDRA-7826, it's already a nice to have today so it's not dependent on 
> that latter ticket in any way.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9318:
-

bq. Alright, looks like queryStartNanoTime replaced the old start variable in 
the latest rebase, let me fix that and check/rerun tests.

I understand now.  {{queryStartNanoTime}} was introduced by CASSANDRA-12256, it 
comes all the way from {{QueryProcessor}}. I think the aim was to to take into 
account the full query processing time from the client point of view, including 
CQL parsing and so forth. Should we increase the timeout by the amount of time 
spent waiting for the backpressure strategy rather than resetting the start 
time? Also, it should not be changed if the backpressure strategy is disabled.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Assigned] (CASSANDRA-12417) Built-in AVG aggregate is much less useful than it should be

[Alex Petrov (JIRA)]

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

Alex Petrov reassigned CASSANDRA-12417:
---

Assignee: Alex Petrov

> Built-in AVG aggregate is much less useful than it should be
> 
>
> Key: CASSANDRA-12417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12417
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Branimir Lambov
>Assignee: Alex Petrov
>
> For fixed-size integer types overflow is all but guaranteed to happen, 
> yielding incorrect result. While for sum it is somewhat acceptable as the 
> result cannot fit the type, this is not the case for average.
> As the result of average is always within the scope of the source type, 
> failing to produce it only signifies a bad implementation. Yes, one can solve 
> this by type-casting, but do we really want to always have to be telling 
> people that the correct spelling of the average function is 
> {{cast(avg(cast(value as bigint))) as int)}}, especially if this is so 
> trivial to fix?
> Additionally, the straightforward addition we use for floating point versions 
> is not a good choice numerically for larger numbers of values. We should 
> switch to a more stable version, e.g. iterative mean using {{avg = avg + 
> (value - avg) / count}}.



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

[jira] [Updated] (CASSANDRA-12573) SASI index. Incorrect results for '%foo%bar%'-like search pattern.

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-12573:

Labels: sasi  (was: )

> SASI index. Incorrect results for '%foo%bar%'-like search pattern. 
> ---
>
> Key: CASSANDRA-12573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12573
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Alex Petrov
>Priority: Critical
>  Labels: sasi
>
> We use Cassandra 3.7 and have faced a strange behaviour of SELECT requests 
> with "LIKE '%foo%bar%'" constraints on a column with SASI index.
> Below are few experiments that show this behaviour.
> Experiment 1:
> {noformat}
> drop keyspace if exists kmv;
> create keyspace if not exists kmv WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor':'1'} ;
> use kmv;
> CREATE TABLE if not exists kmv (id int primary key, c1 text, c2 text);
> CREATE CUSTOM INDEX ON kmv.kmv  ( c2 ) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {
>  'mode': 'CONTAINS'
> };
> insert into kmv (id, c1, c2) values (1, 'f21', 'qwe') ;
> insert into kmv (id, c1, c2) values (2, 'f22', 'qweasd') ;
> insert into kmv (id, c1, c2) values (3, 'f23', 'qwea1') ;
> insert into kmv (id, c1, c2) values (4, 'f24', '1qwe') ;
> insert into kmv (id, c1, c2) values (5, 'f25', 'asdqwe') ;
> select c2 from kmv.kmv where c2 like '%w%a%';
> {noformat}
> Expected result: qweasd, qwea1.
> Actual result: no rows.
> Experiment 2 (NOTE: definition of index is changed):
> {noformat}
> drop keyspace if exists kmv;
> create keyspace if not exists kmv WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor':'1'} ;
> use kmv;
> CREATE TABLE if not exists kmv (id int primary key, c1 text, c2 text);
> CREATE CUSTOM INDEX ON kmv.kmv  ( c2 ) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {
>  'mode': 'CONTAINS',
>  'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer',
>  'analyzed': 'true'
> };
> insert into kmv (id, c1, c2) values (1, 'f21', 'qwe') ;
> insert into kmv (id, c1, c2) values (2, 'f22', 'qweasd') ;
> insert into kmv (id, c1, c2) values (3, 'f23', 'qwea1') ;
> insert into kmv (id, c1, c2) values (4, 'f24', '1qwe') ;
> insert into kmv (id, c1, c2) values (5, 'f25', 'asdqwe') ;
> select c2 from kmv.kmv where c2 like '%w%a%';
> {noformat}
> Expected result: qweasd, qwea1.
> Actual result: asdqwe, qweasd, qwea1.
> Experiment 3 (NOTE: primary key is compound now and inserted data was 
> changed):
> {noformat}
> drop keyspace if exists kmv;
> create keyspace if not exists kmv WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor':'1'} ;
> use kmv;
> CREATE TABLE if not exists kmv (id int, c1 text, c2 text, PRIMARY KEY(id, 
> c1));
> CREATE CUSTOM INDEX ON kmv.kmv  ( c2 ) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {
>  'mode': 'CONTAINS',
>  'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer',
>  'analyzed': 'true'
> };
> insert into kmv (id, c1, c2) values (1, 'f21', 'qwe') ;
> insert into kmv (id, c1, c2) values (1, 'f22', 'qweasd') ;
> insert into kmv (id, c1, c2) values (1, 'f23', 'qwea1') ;
> insert into kmv (id, c1, c2) values (1, 'f24', '1qwe') ;
> insert into kmv (id, c1, c2) values (1, 'f25', 'asdqwe') ;
> select c2 from kmv.kmv where c2 like '%w%a%';
> {noformat}
> Expected result: qweasd, qwea1.
> Actual result: qwe, qweasd, qwea1, 1qwe, asdqwe.
> Experiment 4 (NOTE: search criteria is changed):
> {noformat}
> drop keyspace if exists kmv;
> create keyspace if not exists kmv WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor':'1'} ;
> use kmv;
> CREATE TABLE if not exists kmv (id int, c1 text, c2 text, PRIMARY KEY(id, 
> c1));
> CREATE CUSTOM INDEX ON kmv.kmv  ( c2 ) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {
>  'mode': 'CONTAINS',
>  'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer',
>  'analyzed': 'true'
> };
> insert into kmv (id, c1, c2) values (1, 'f21', 'qwe') ;
> insert into kmv (id, c1, c2) values (1, 'f22', 'qweasd') ;
> insert into kmv (id, c1, c2) values (1, 'f23', 'qwea1') ;
> insert into kmv (id, c1, c2) values (1, 'f24', '1qwe') ;
> insert into kmv (id, c1, c2) values (1, 'f25', 'asdqwe') ;
> select c2 from kmv.kmv where c2 like '%w22%a%';
> {noformat}
> Expected result: no rows.
> Actual result: qweasd, qwea1, asdqwe.



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

[jira] [Assigned] (CASSANDRA-12573) SASI index. Incorrect results for '%foo%bar%'-like search pattern.

[Alex Petrov (JIRA)]

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

Alex Petrov reassigned CASSANDRA-12573:
---

Assignee: Alex Petrov

> SASI index. Incorrect results for '%foo%bar%'-like search pattern. 
> ---
>
> Key: CASSANDRA-12573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12573
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Alex Petrov
>Priority: Critical
>  Labels: sasi
>
> We use Cassandra 3.7 and have faced a strange behaviour of SELECT requests 
> with "LIKE '%foo%bar%'" constraints on a column with SASI index.
> Below are few experiments that show this behaviour.
> Experiment 1:
> {noformat}
> drop keyspace if exists kmv;
> create keyspace if not exists kmv WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor':'1'} ;
> use kmv;
> CREATE TABLE if not exists kmv (id int primary key, c1 text, c2 text);
> CREATE CUSTOM INDEX ON kmv.kmv  ( c2 ) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {
>  'mode': 'CONTAINS'
> };
> insert into kmv (id, c1, c2) values (1, 'f21', 'qwe') ;
> insert into kmv (id, c1, c2) values (2, 'f22', 'qweasd') ;
> insert into kmv (id, c1, c2) values (3, 'f23', 'qwea1') ;
> insert into kmv (id, c1, c2) values (4, 'f24', '1qwe') ;
> insert into kmv (id, c1, c2) values (5, 'f25', 'asdqwe') ;
> select c2 from kmv.kmv where c2 like '%w%a%';
> {noformat}
> Expected result: qweasd, qwea1.
> Actual result: no rows.
> Experiment 2 (NOTE: definition of index is changed):
> {noformat}
> drop keyspace if exists kmv;
> create keyspace if not exists kmv WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor':'1'} ;
> use kmv;
> CREATE TABLE if not exists kmv (id int primary key, c1 text, c2 text);
> CREATE CUSTOM INDEX ON kmv.kmv  ( c2 ) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {
>  'mode': 'CONTAINS',
>  'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer',
>  'analyzed': 'true'
> };
> insert into kmv (id, c1, c2) values (1, 'f21', 'qwe') ;
> insert into kmv (id, c1, c2) values (2, 'f22', 'qweasd') ;
> insert into kmv (id, c1, c2) values (3, 'f23', 'qwea1') ;
> insert into kmv (id, c1, c2) values (4, 'f24', '1qwe') ;
> insert into kmv (id, c1, c2) values (5, 'f25', 'asdqwe') ;
> select c2 from kmv.kmv where c2 like '%w%a%';
> {noformat}
> Expected result: qweasd, qwea1.
> Actual result: asdqwe, qweasd, qwea1.
> Experiment 3 (NOTE: primary key is compound now and inserted data was 
> changed):
> {noformat}
> drop keyspace if exists kmv;
> create keyspace if not exists kmv WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor':'1'} ;
> use kmv;
> CREATE TABLE if not exists kmv (id int, c1 text, c2 text, PRIMARY KEY(id, 
> c1));
> CREATE CUSTOM INDEX ON kmv.kmv  ( c2 ) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {
>  'mode': 'CONTAINS',
>  'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer',
>  'analyzed': 'true'
> };
> insert into kmv (id, c1, c2) values (1, 'f21', 'qwe') ;
> insert into kmv (id, c1, c2) values (1, 'f22', 'qweasd') ;
> insert into kmv (id, c1, c2) values (1, 'f23', 'qwea1') ;
> insert into kmv (id, c1, c2) values (1, 'f24', '1qwe') ;
> insert into kmv (id, c1, c2) values (1, 'f25', 'asdqwe') ;
> select c2 from kmv.kmv where c2 like '%w%a%';
> {noformat}
> Expected result: qweasd, qwea1.
> Actual result: qwe, qweasd, qwea1, 1qwe, asdqwe.
> Experiment 4 (NOTE: search criteria is changed):
> {noformat}
> drop keyspace if exists kmv;
> create keyspace if not exists kmv WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor':'1'} ;
> use kmv;
> CREATE TABLE if not exists kmv (id int, c1 text, c2 text, PRIMARY KEY(id, 
> c1));
> CREATE CUSTOM INDEX ON kmv.kmv  ( c2 ) USING 
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {
>  'mode': 'CONTAINS',
>  'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer',
>  'analyzed': 'true'
> };
> insert into kmv (id, c1, c2) values (1, 'f21', 'qwe') ;
> insert into kmv (id, c1, c2) values (1, 'f22', 'qweasd') ;
> insert into kmv (id, c1, c2) values (1, 'f23', 'qwea1') ;
> insert into kmv (id, c1, c2) values (1, 'f24', '1qwe') ;
> insert into kmv (id, c1, c2) values (1, 'f25', 'asdqwe') ;
> select c2 from kmv.kmv where c2 like '%w22%a%';
> {noformat}
> Expected result: no rows.
> Actual result: qweasd, qwea1, asdqwe.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-9318:
-

bq. This method initializes the variable but where is it read?

Alright, looks like {{queryStartNanoTime}} replaced the old {{start}} variable 
in the latest rebase, let me fix that and check/rerun tests.

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-9318:
-

bq. The latest rebase brought several changes and conflicts so I was waiting 
for the jenkins test results to fix any related test failures: let me do that 
and rerun the suite.

OK

bq. It is used here. Or am I missing something?

This method initializes the variable but where is it read?

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [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] [Assigned] (CASSANDRA-12571) cqlsh lost the ability to have a request wait indefinitely

[Stefania (JIRA)]

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

Stefania reassigned CASSANDRA-12571:


Assignee: Stefania

> cqlsh lost the ability to have a request wait indefinitely
> --
>
> Key: CASSANDRA-12571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12571
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Cassandra 3.7
>Reporter: Nate Sanders
>Assignee: Stefania
>Priority: Minor
>
> In commit c7f0032912798b5e53b64d8391e3e3d7e4121165, when client_timeout 
> became request_timeout, the logic was changed so that you can no longer use a 
> timeout of None, despite the docs saying that you can:
> https://docs.datastax.com/en/cql/3.3/cql/cql_reference/cqlshUsingCqlshrc.html#cqlshUsingCqlshrc__request-timeout



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

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

[Stefania (JIRA)]

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

Stefania reassigned CASSANDRA-12014:


Assignee: Stefania

> 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] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator

[Sergio Bossa (JIRA)]

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

Sergio Bossa commented on CASSANDRA-9318:
-

Thanks [~Stefania]. 

The latest rebase brought several changes and conflicts so I was waiting for 
the jenkins test results to fix any related test failures: let me do that and 
rerun the suite.

Regarding:

bq. Is this commit complete? It looks like AbstractWriteResponseHandler.start 
is not used.

It is used 
[here|https://github.com/apache/cassandra/commit/ad729f2d1758ec8c4add7b71ce3c3a680f5beb6d#diff-71f06c193f5b5e270cf8ac695164f43aR1307].
 Or am I missing something?

> Bound the number of in-flight requests at the coordinator
> -
>
> Key: CASSANDRA-9318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths, Streaming and Messaging
>Reporter: Ariel Weisberg
>Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png, 
> limit.btm, no_backpressure.png
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



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

[jira] [Updated] (CASSANDRA-12430) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_writing_with_token_boundaries

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-12430:
-
Component/s: Testing

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_writing_with_token_boundaries
> --
>
> Key: CASSANDRA-12430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12430
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Craig Kodman
>Assignee: Stefania
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/787/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_writing_with_token_boundaries
> Failed on CassCI build cassandra-3.0_dtest build #787
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 1022, in test_writing_with_token_boundaries
> self._test_writing_with_token_boundaries(1, None, 200)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 1059, in _test_writing_with_token_boundaries
> self.assertItemsEqual(csv_values, result)
>   File "/usr/lib/python2.7/unittest/case.py", line 901, in assertItemsEqual
> self.fail(msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "Element counts were not equal:\nFirst has 0, Second has 1:  ('130', 
> -4364617663693876050L)\nFirst has 0, Second has 1:  ('1504', 
> -4313346088993828066L)\nFirst has 0, Second has 1:  ('1657', 
> -4298243044528711865L)\nFirst has 0, Second has 1:  ('1908', 
> -4357762565998238890L)\nFirst has 0, Second has 1:  ('196', 
> -4311842292754600676L)\nFirst has 0, Second has 1:  ('2069', 
> -4364398944370882217L)\nFirst has 0, Second has 1:  ('2840', 
> -4341639477649832153L)\nFirst has 0, Second has 1:  ('2887', 
> -4318016824479819783L)\nFirst has 0, Second has 1:  ('2899', 
> -4302748366908469185L)\nFirst has 0, Second has 1:  ('2928', 
> -4320094196758787736L)\nFirst has 0, Second has 1:  ('2985', 
> -4314356124534988584L)\nFirst has 0, Second has 1:  ('3684', 
> -4338074463992249966L)\nFirst has 0, Second has 1:  ('371', 
> -4314424123257001171L)\nFirst has 0, Second has 1:  ('3726', 
> -4327342039280507889L)\nFirst has 0, Second has 1:  ('3767', 
> -4314615789624913427L)\nFirst has 0, Second has 1:  ('3837', 
> -4345782419910891107L)\nFirst has 0, Second has 1:  ('3917', 
> -4288469607605675346L)\nFirst has 0, Second has 1:  ('4023', 
> -4327319429102869913L)\nFirst has 0, Second has 1:  ('4340', 
> -4364719196309290555L)\nFirst has 0, Second has 1:  ('4775', 
> -4334399295585005795L)\nFirst has 0, Second has 1:  ('480', 
> -4297721626756162038L)\nFirst has 0, Second has 1:  ('4927', 
> -4363012199808638126L)\nFirst has 0, Second has 1:  ('5227', 
> -4322405738833807588L)\nFirst has 0, Second has 1:  ('564', 
> -4294201317243228473L)\nFirst has 0, Second has 1:  ('585', 
> -435900129350319L)\nFirst has 0, Second has 1:  ('5869', 
> -4350305245827564608L)\nFirst has 0, Second has 1:  ('6907', 
> -4350623491924194304L)\nFirst has 0, Second has 1:  ('709', 
> -4304008865600291097L)\nFirst has 0, Second has 1:  ('7415', 
> -4315752378065264743L)\nFirst has 0, Second has 1:  ('7476', 
> -4300546270541034340L)\nFirst has 0, Second has 1:  ('7805', 
> -4344641724309508742L)\nFirst has 0, Second has 1:  ('7922', 
> -4363605089028496367L)\nFirst has 0, Second has 1:  ('8026', 
> -4319008002233878821L)\nFirst has 0, Second has 1:  ('8180', 
> -4361912691055780971L)\nFirst has 0, Second has 1:  ('8371', 
> -4309172311179179912L)\nFirst has 0, Second has 1:  ('8988', 
> -432609343783541L)\nFirst has 0, Second has 1:  ('9492', 
> -4347264403260361686L)\nFirst has 0, Second has 1:  ('9783', 
> -4329297319597600121L)\nFirst has 0, Second has 1:  ('9911', 
> -4320490295580904236L)\n >> begin captured logging << 
> \ndtest: DEBUG: cluster ccm directory: 
> /tmp/dtest-2v8O54\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: Exporting to csv file: /tmp/tmpDS47Vq\ndtest: DEBUG: 
> Exporting to csv file: /tmp/tmpQvnl6e\ndtest: DEBUG: Exporting to csv file: 
> /tmp/tmpfEEiAz\ndtest: DEBUG: Exporting to csv file: /tmp/tmpc7T8av\ndtest: 
> DEBUG: Exporting to csv file: 

[jira] [Updated] (CASSANDRA-12430) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_writing_with_token_boundaries

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-12430:
-
 Reviewer: DS Test Eng
Fix Version/s: (was: 3.0.x)
   Status: Patch Available  (was: In Progress)

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_writing_with_token_boundaries
> --
>
> Key: CASSANDRA-12430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12430
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Craig Kodman
>Assignee: Stefania
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/787/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_writing_with_token_boundaries
> Failed on CassCI build cassandra-3.0_dtest build #787
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 1022, in test_writing_with_token_boundaries
> self._test_writing_with_token_boundaries(1, None, 200)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 1059, in _test_writing_with_token_boundaries
> self.assertItemsEqual(csv_values, result)
>   File "/usr/lib/python2.7/unittest/case.py", line 901, in assertItemsEqual
> self.fail(msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "Element counts were not equal:\nFirst has 0, Second has 1:  ('130', 
> -4364617663693876050L)\nFirst has 0, Second has 1:  ('1504', 
> -4313346088993828066L)\nFirst has 0, Second has 1:  ('1657', 
> -4298243044528711865L)\nFirst has 0, Second has 1:  ('1908', 
> -4357762565998238890L)\nFirst has 0, Second has 1:  ('196', 
> -4311842292754600676L)\nFirst has 0, Second has 1:  ('2069', 
> -4364398944370882217L)\nFirst has 0, Second has 1:  ('2840', 
> -4341639477649832153L)\nFirst has 0, Second has 1:  ('2887', 
> -4318016824479819783L)\nFirst has 0, Second has 1:  ('2899', 
> -4302748366908469185L)\nFirst has 0, Second has 1:  ('2928', 
> -4320094196758787736L)\nFirst has 0, Second has 1:  ('2985', 
> -4314356124534988584L)\nFirst has 0, Second has 1:  ('3684', 
> -4338074463992249966L)\nFirst has 0, Second has 1:  ('371', 
> -4314424123257001171L)\nFirst has 0, Second has 1:  ('3726', 
> -4327342039280507889L)\nFirst has 0, Second has 1:  ('3767', 
> -4314615789624913427L)\nFirst has 0, Second has 1:  ('3837', 
> -4345782419910891107L)\nFirst has 0, Second has 1:  ('3917', 
> -4288469607605675346L)\nFirst has 0, Second has 1:  ('4023', 
> -4327319429102869913L)\nFirst has 0, Second has 1:  ('4340', 
> -4364719196309290555L)\nFirst has 0, Second has 1:  ('4775', 
> -4334399295585005795L)\nFirst has 0, Second has 1:  ('480', 
> -4297721626756162038L)\nFirst has 0, Second has 1:  ('4927', 
> -4363012199808638126L)\nFirst has 0, Second has 1:  ('5227', 
> -4322405738833807588L)\nFirst has 0, Second has 1:  ('564', 
> -4294201317243228473L)\nFirst has 0, Second has 1:  ('585', 
> -435900129350319L)\nFirst has 0, Second has 1:  ('5869', 
> -4350305245827564608L)\nFirst has 0, Second has 1:  ('6907', 
> -4350623491924194304L)\nFirst has 0, Second has 1:  ('709', 
> -4304008865600291097L)\nFirst has 0, Second has 1:  ('7415', 
> -4315752378065264743L)\nFirst has 0, Second has 1:  ('7476', 
> -4300546270541034340L)\nFirst has 0, Second has 1:  ('7805', 
> -4344641724309508742L)\nFirst has 0, Second has 1:  ('7922', 
> -4363605089028496367L)\nFirst has 0, Second has 1:  ('8026', 
> -4319008002233878821L)\nFirst has 0, Second has 1:  ('8180', 
> -4361912691055780971L)\nFirst has 0, Second has 1:  ('8371', 
> -4309172311179179912L)\nFirst has 0, Second has 1:  ('8988', 
> -432609343783541L)\nFirst has 0, Second has 1:  ('9492', 
> -4347264403260361686L)\nFirst has 0, Second has 1:  ('9783', 
> -4329297319597600121L)\nFirst has 0, Second has 1:  ('9911', 
> -4320490295580904236L)\n >> begin captured logging << 
> \ndtest: DEBUG: cluster ccm directory: 
> /tmp/dtest-2v8O54\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: Exporting to csv file: /tmp/tmpDS47Vq\ndtest: DEBUG: 
> Exporting to csv file: /tmp/tmpQvnl6e\ndtest: DEBUG: Exporting to csv file: 
> 

[jira] [Commented] (CASSANDRA-12430) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_writing_with_token_boundaries

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-12430:
--

Thanks [~jkni]! 

It's an OperationTimedOut error for one of the pages that caused some records 
to be missing:

{code}
dtest: DEBUG: Exporting tokens 100 - None for 1 records to 
csv file: /tmp/tmpKZOxfD
dtest: DEBUG: COPY ks.testtokens TO '/tmp/tmpKZOxfD'WITH BEGINTOKEN = 
'100'
dtest: DEBUG: Using CQL driver: 
Using connect timeout: 5 seconds
Using 'utf-8' encoding
Using ssl: False
:2:Error for (2350569513275064150, 4339695056833745219): 
OperationTimedOut - errors={'127.0.0.1': 'Client request timeout. See 
Session.execute[_async](timeout)'}, last_host=127.0.0.1 (permanently given up 
after 1000 rows and 1 attempts)
:2:Exported 8 ranges out of 9 total ranges, some records might be missing

dtest: DEBUG: Detected 4 core(s)
Using 3 child processes

Starting copy of ks.testtokens with columns [a].
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Created connection to ('127.0.0.1',) with page size 1000 and timeout 10 seconds 
per page
Created connection to ('127.0.0.1',) with page size 1000 and timeout 10 seconds 
per page
Created connection to ('127.0.0.1',) with page size 1000 and timeout 10 seconds 
per page
OperationTimedOut - errors={'127.0.0.1': 'Client request timeout. See 
Session.execute[_async](timeout)'}, last_host=127.0.0.1
Processed: 4440 rows; Rate: 440 rows/s; Avg. rate: 440 rows/s

4440 rows exported to 1 files in 10.088 seconds.
{code}

Increasing the page timeout should be sufficient to fix this, the pull request 
is [here|https://github.com/riptano/cassandra-dtest/pull/1317].

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_writing_with_token_boundaries
> --
>
> Key: CASSANDRA-12430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12430
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Craig Kodman
>Assignee: Stefania
>  Labels: dtest
> Fix For: 3.0.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/787/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_writing_with_token_boundaries
> Failed on CassCI build cassandra-3.0_dtest build #787
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 1022, in test_writing_with_token_boundaries
> self._test_writing_with_token_boundaries(1, None, 200)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 1059, in _test_writing_with_token_boundaries
> self.assertItemsEqual(csv_values, result)
>   File "/usr/lib/python2.7/unittest/case.py", line 901, in assertItemsEqual
> self.fail(msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "Element counts were not equal:\nFirst has 0, Second has 1:  ('130', 
> -4364617663693876050L)\nFirst has 0, Second has 1:  ('1504', 
> -4313346088993828066L)\nFirst has 0, Second has 1:  ('1657', 
> -4298243044528711865L)\nFirst has 0, Second has 1:  ('1908', 
> -4357762565998238890L)\nFirst has 0, Second has 1:  ('196', 
> -4311842292754600676L)\nFirst has 0, Second has 1:  ('2069', 
> -4364398944370882217L)\nFirst has 0, Second has 1:  ('2840', 
> -4341639477649832153L)\nFirst has 0, Second has 1:  ('2887', 
> -4318016824479819783L)\nFirst has 0, Second has 1:  ('2899', 
> -4302748366908469185L)\nFirst has 0, Second has 1:  ('2928', 
> -4320094196758787736L)\nFirst has 0, Second has 1:  ('2985', 
> -4314356124534988584L)\nFirst has 0, Second has 1:  ('3684', 
> -4338074463992249966L)\nFirst has 0, Second has 1:  ('371', 
> -4314424123257001171L)\nFirst has 0, Second has 1:  ('3726', 
> -4327342039280507889L)\nFirst has 0, Second has 1:  ('3767', 
> -4314615789624913427L)\nFirst has 0, Second has 1:  ('3837', 
> -4345782419910891107L)\nFirst has 0, Second has 1:  ('3917', 
> -4288469607605675346L)\nFirst has 0, Second has 1:  ('4023', 
> -4327319429102869913L)\nFirst has 0, Second has 1:  ('4340', 
> -4364719196309290555L)\nFirst has 0, Second has 1:  ('4775', 
> -4334399295585005795L)\nFirst has 0, Second has 1:  ('480', 
> -4297721626756162038L)\nFirst has 0, Second has 1:  ('4927', 
> -4363012199808638126L)\nFirst has 0, Second has 1:  ('5227', 
> -4322405738833807588L)\nFirst has 0, Second has 1:  ('564', 
> -4294201317243228473L)\nFirst has 0, Second has 1:  ('585', 
> -435900129350319L)\nFirst has 0, Second has 1: