[jira] [Commented] (CASSANDRA-13464) Failed to create Materialized view with a specific token range

[Damien Stevenson (JIRA)]

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

Damien Stevenson commented on CASSANDRA-13464:
--

I have taken the liberty to update [~krishna.koneru]'s patch and make changes 
based on the comments from [~jasonstack].

Note: I have removed the _testViewAlterBaseTable_ unit test as it no logger 
makes sense with the changes from CASSANDRA-11500. More specifically:
{noformat}
7. Disallow drop of columns on base tables with MVs because we cannot tell if 
the dropped column is keeping a view row alive (will be fixed on 
CASSANDRA-13826){noformat}
Please have another look and let me know what you think. Thanks.


||Patch||CircleCI||
|[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...damien-instaclustr:13464-mv-token-3.0]|[CirclCI-3.0|https://circleci.com/gh/damien-instaclustr/cassandra/90]|
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...damien-instaclustr:13464-mv-token-3.11]|[CirclCI-3.11|https://circleci.com/gh/damien-instaclustr/cassandra/88]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...damien-instaclustr:13464-mv-token-trunk]|[CirclCI-3.11|https://circleci.com/gh/damien-instaclustr/cassandra/85]|

> Failed to create Materialized view with a specific token range
> --
>
> Key: CASSANDRA-13464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13464
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Natsumi Kojima
>Assignee: Krishna Dattu Koneru
>Priority: Minor
>  Labels: materializedviews
>
> Failed to create Materialized view with a specific token range.
> Example :
> {code:java}
> $ ccm create "MaterializedView" -v 3.0.13
> $ ccm populate  -n 3
> $ ccm start
> $ ccm status
> Cluster: 'MaterializedView'
> ---
> node1: UP
> node3: UP
> node2: UP
> $ccm node1 cqlsh
> Connected to MaterializedView at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.13 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy', 
> 'replication_factor':3};
> cqlsh> CREATE TABLE test.test ( id text PRIMARY KEY , value1 text , value2 
> text, value3 text);
> $ccm node1 ring test 
> Datacenter: datacenter1
> ==
> AddressRackStatus State   LoadOwns
> Token
>   
> 3074457345618258602
> 127.0.0.1  rack1   Up Normal  64.86 KB100.00% 
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  86.49 KB100.00% 
> -3074457345618258603
> 127.0.0.3  rack1   Up Normal  89.04 KB100.00% 
> 3074457345618258602
> $ ccm node1 cqlsh
> cqlsh> INSERT INTO test.test (id, value1 , value2, value3 ) VALUES ('aaa', 
> 'aaa', 'aaa' ,'aaa');
> cqlsh> INSERT INTO test.test (id, value1 , value2, value3 ) VALUES ('bbb', 
> 'bbb', 'bbb' ,'bbb');
> cqlsh> SELECT token(id),id,value1 FROM test.test;
>  system.token(id) | id  | value1
> --+-+
>  -4737872923231490581 | aaa |aaa
>  -3071845237020185195 | bbb |bbb
> (2 rows)
> cqlsh> CREATE MATERIALIZED VIEW test.test_view AS SELECT value1, id FROM 
> test.test WHERE id IS NOT NULL AND value1 IS NOT NULL AND TOKEN(id) > 
> -9223372036854775808 AND TOKEN(id) < -3074457345618258603 PRIMARY KEY(value1, 
> id) WITH CLUSTERING ORDER BY (id ASC);
> ServerError: java.lang.ClassCastException: 
> org.apache.cassandra.cql3.TokenRelation cannot be cast to 
> org.apache.cassandra.cql3.SingleColumnRelation
> {code}
> Stacktrace :
> {code:java}
> INFO  [MigrationStage:1] 2017-04-19 18:32:48,131 ColumnFamilyStore.java:389 - 
> Initializing test.test
> WARN  [SharedPool-Worker-1] 2017-04-19 18:44:07,263 FBUtilities.java:337 - 
> Trigger directory doesn't exist, please create it and try again.
> ERROR [SharedPool-Worker-1] 2017-04-19 18:46:10,072 QueryMessage.java:128 - 
> Unexpected error during query
> java.lang.ClassCastException: org.apache.cassandra.cql3.TokenRelation cannot 
> be cast to org.apache.cassandra.cql3.SingleColumnRelation
>   at 
> org.apache.cassandra.db.view.View.relationsToWhereClause(View.java:275) 
> ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.cql3.statements.CreateViewStatement.announceMigration(CreateViewStatement.java:219)
>  ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:93)
>  ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 

[jira] [Comment Edited] (CASSANDRA-14417) nodetool import cleanup/fixes

[Jordan West (JIRA)]

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

Jordan West edited comment on CASSANDRA-14417 at 5/16/18 3:59 AM:
--

* The output when {{extended=false}}, {{checkOwnsTokens=true}} is still debug 
(because the message was removed and the exception is logged as debug). I see 
it changed when extended=true. Verifier#L217.
 * While cleaning things up, should 
{{ColumnFamilyStore#findBestDiskAndInvalidateCaches}} be refactored to use 
{{KeyIterator}} as well?
 * EDIT: Also, just noticed the failing dtest. Seems to be in an area 
related-ish to these changes but I am not familiar enough with it yet to know 
if its related or just a flaky test. (EDIT: it failed here on a branch without 
this change https://circleci.com/gh/jrwest/cassandra/86#tests/containers/66)


was (Author: jrwest):
* The output when {{extended=false}}, {{checkOwnsTokens=true}} is still debug 
(because the message was removed and the exception is logged as debug). I see 
it changed when extended=true. Verifier#L217.
 * While cleaning things up, should 
{{ColumnFamilyStore#findBestDiskAndInvalidateCaches}} be refactored to use 
{{KeyIterator}} as well?
 * EDIT: Also, just noticed the failing dtest. Seems to be in an area 
related-ish to these changes but I am not familiar enough with it yet to know 
if its related or just a flaky test. 

> nodetool import cleanup/fixes
> -
>
> Key: CASSANDRA-14417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14417
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> * We shouldn't expose importNewSSTables in both StorageServiceMBean and 
> CFSMbean
> * Allow a quicker token check without doing an extended verify
> * Introduce an ImportOptions class to avoid passing in 100 booleans in 
> importNewSSTables



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14446) Cassandra will not start on JRE 10

[Mila Rodriguez (JIRA)]

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

Mila Rodriguez commented on CASSANDRA-14446:


Well it's a pity that's _not what the error message says._ If Cassandra is 
restricted to Java 8 or below, then this should clearly be documented in such a 
way that doesn't appear to just be un-updated documentation.

> Cassandra will not start on JRE 10
> --
>
> Key: CASSANDRA-14446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14446
> Project: Cassandra
>  Issue Type: Bug
> Environment: JDK 10.0.1
>Reporter: Mila Rodriguez
>Priority: Major
>
> Clean install of Windows 10 Home 64 bit, JDK 10.0.1, Cassandra 3.11.2.
> Attempted to start Cassandra for the first time:
>  
> {code:java}
> PS C:\javatools> cassandra -f
> *-*
> *-*
> WARNING! Automatic page file configuration detected.
>  It is recommended that you disable swap when running Cassandra
>  for performance and stability reasons.
> *-*
> *-*
> Failed 64-bit check. Re-running to get version from 32-bit
> *-*
> *-*
> Cassandra 3.0 and later require Java 8u40 or later.
> {code}
>  
> Result of `java -version` check:
> {code:java}
> PS C:\javatools> java -version
> java version "10.0.1" 2018-04-17
> Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode){code}
> My guess would be that the change in versioning scheme ("10.0.1" instead of 
> something a la "1.8.0_40") is what is causing this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14298) cqlshlib tests broken on b.a.o

[Patrick Bannister (JIRA)]

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

Patrick Bannister edited comment on CASSANDRA-14298 at 5/16/18 3:05 AM:


I've made a lot of progress porting cqlshlib to Python 3. Along the way I've 
been taking notes on all the areas that I think would require extra effort for 
cross compatibility with Python 2.

I don't have a complete plan yet, but I have some observations.

In terms of level of effort and complexity, this is not going to be as simple 
as running 2to3 and then adding a few imports from future and six. However, we 
won't need to rearchitect the library either. So far I've found that existing 
classes and functions work with just a few tweaks to their implementation, 
mostly around IO and strings vs. bytes.

The biggest challenge, regardless of whether we go straight Python 3 or 
cross-compatible, is going to be adequately testing the result. The cqlshlib 
unittests and the cqlsh_tests have been useful to help find bugs, but I'm not 
confident that our tests have enough code coverage to exercise everything. We 
would need a strategy for more comprehensive testing.

Some specifics:
 * The SaferScanner class in saferscanner.py requires a slightly different 
implementation in Python 2 vs. Python 3, because of changes in the internals of 
the re module for regular expressions.
 * copyutil.py, formatting.py, and displaying.py have needed the most work so 
far, since they have a lot of IO and serialization.
 * The formatter for blobs in formatting.py needs a different implementation in 
Python 2 vs. Python 3, because of changes in the behavior of binascii.hexlify.
 * On the dtests side, there are several tests that fail intermittently due to 
different sorting between expected results and observed results. The result of 
these tests is flaky depending on what randomly occurring sort happens to come 
out of the test. I've been able to get these tests to pass consistently by 
sorting results just before asserting equality.
 * Another notable dtest issue: in the cqlsh_copy_tests, the bulk_round_trip 
tests that use the blogposts profile are failing because of a limitation of the 
Python csv.reader, which is used in cqlshlib3 and in the bulk_round_trip tests. 
Python's csv.reader chokes on newlines and null characters, but the 
cassandra-stress tool's Strings Generator subclass generates both of these 
things in text fields. (Edit: this may be a combination of misuse on my part of 
csv.reader, plus a failure to properly port formatting of text data.)


was (Author: ptbannister):
I've made a lot of progress porting cqlshlib to Python 3. Along the way I've 
been taking notes on all the areas that I think would require extra effort for 
cross compatibility with Python 2.

I don't have a complete plan yet, but I have some observations.

In terms of level of effort and complexity, this is not going to be as simple 
as running 2to3 and then adding a few imports from future and six. However, we 
won't need to rearchitect the library either. So far I've found that existing 
classes and functions work with just a few tweaks to their implementation, 
mostly around IO and strings vs. bytes.

The biggest challenge, regardless of whether we go straight Python 3 or 
cross-compatible, is going to be adequately testing the result. The cqlshlib 
unittests and the cqlsh_tests have been useful to help find bugs, but I'm not 
confident that our tests have enough code coverage to exercise everything. We 
would need a strategy for more comprehensive testing.

Some specifics:
 * The SaferScanner class in saferscanner.py requires a slightly different 
implementation in Python 2 vs. Python 3, because of changes in the internals of 
the re module for regular expressions.
 * copyutil.py, formatting.py, and displaying.py have needed the most work so 
far, since they have a lot of IO and serialization.
 * The formatter for blobs in formatting.py needs a different implementation in 
Python 2 vs. Python 3, because of changes in the behavior of binascii.hexlify.
 * On the dtests side, there are several tests that fail intermittently due to 
different sorting between expected results and observed results. The result of 
these tests is flaky depending on what randomly occurring sort happens to come 
out of the test. I've been able to get these tests to pass consistently by 
sorting results just before asserting equality.
 * Another notable dtest issue: in the cqlsh_copy_tests, the bulk_round_trip 
tests that use the blogposts profile are failing because of a limitation of the 
Python csv.reader, which is used in cqlshlib3 and in the bulk_round_trip tests. 
Python's csv.reader chokes on newlines and null characters, but the 
cassandra-stress tool's Strings Generator subclass generates both of these 
things in text fields.

> cqlshlib tests broken 

[jira] [Resolved] (CASSANDRA-14446) Cassandra will not start on JRE 10

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan resolved CASSANDRA-14446.
-
Resolution: Duplicate

> Cassandra will not start on JRE 10
> --
>
> Key: CASSANDRA-14446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14446
> Project: Cassandra
>  Issue Type: Bug
> Environment: JDK 10.0.1
>Reporter: Mila Rodriguez
>Priority: Major
>
> Clean install of Windows 10 Home 64 bit, JDK 10.0.1, Cassandra 3.11.2.
> Attempted to start Cassandra for the first time:
>  
> {code:java}
> PS C:\javatools> cassandra -f
> *-*
> *-*
> WARNING! Automatic page file configuration detected.
>  It is recommended that you disable swap when running Cassandra
>  for performance and stability reasons.
> *-*
> *-*
> Failed 64-bit check. Re-running to get version from 32-bit
> *-*
> *-*
> Cassandra 3.0 and later require Java 8u40 or later.
> {code}
>  
> Result of `java -version` check:
> {code:java}
> PS C:\javatools> java -version
> java version "10.0.1" 2018-04-17
> Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode){code}
> My guess would be that the change in versioning scheme ("10.0.1" instead of 
> something a la "1.8.0_40") is what is causing this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14446) Cassandra will not start on JRE 10

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-14446:
-

JDK’s > 8 are not supported. See CASSANDRA-9608 and related tickets.

> Cassandra will not start on JRE 10
> --
>
> Key: CASSANDRA-14446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14446
> Project: Cassandra
>  Issue Type: Bug
> Environment: JDK 10.0.1
>Reporter: Mila Rodriguez
>Priority: Major
>
> Clean install of Windows 10 Home 64 bit, JDK 10.0.1, Cassandra 3.11.2.
> Attempted to start Cassandra for the first time:
>  
> {code:java}
> PS C:\javatools> cassandra -f
> *-*
> *-*
> WARNING! Automatic page file configuration detected.
>  It is recommended that you disable swap when running Cassandra
>  for performance and stability reasons.
> *-*
> *-*
> Failed 64-bit check. Re-running to get version from 32-bit
> *-*
> *-*
> Cassandra 3.0 and later require Java 8u40 or later.
> {code}
>  
> Result of `java -version` check:
> {code:java}
> PS C:\javatools> java -version
> java version "10.0.1" 2018-04-17
> Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode){code}
> My guess would be that the change in versioning scheme ("10.0.1" instead of 
> something a la "1.8.0_40") is what is causing this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14446) Cassandra will not start on JRE 10

[Mila Rodriguez (JIRA)]

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

Mila Rodriguez commented on CASSANDRA-14446:


Note that JDK 10.0.1 is what Oracle _recommends_ you install when you go to the 
JDK installation page, so it's not like you have to go digging around for it or 
anything.

> Cassandra will not start on JRE 10
> --
>
> Key: CASSANDRA-14446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14446
> Project: Cassandra
>  Issue Type: Bug
> Environment: JDK 10.0.1
>Reporter: Mila Rodriguez
>Priority: Major
>
> Clean install of Windows 10 Home 64 bit, JDK 10.0.1, Cassandra 3.11.2.
> Attempted to start Cassandra for the first time:
>  
> {code:java}
> PS C:\javatools> cassandra -f
> *-*
> *-*
> WARNING! Automatic page file configuration detected.
>  It is recommended that you disable swap when running Cassandra
>  for performance and stability reasons.
> *-*
> *-*
> Failed 64-bit check. Re-running to get version from 32-bit
> *-*
> *-*
> Cassandra 3.0 and later require Java 8u40 or later.
> {code}
>  
> Result of `java -version` check:
> {code:java}
> PS C:\javatools> java -version
> java version "10.0.1" 2018-04-17
> Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode){code}
> My guess would be that the change in versioning scheme ("10.0.1" instead of 
> something a la "1.8.0_40") is what is causing this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-14446) Cassandra will not start on JRE 10

[Mila Rodriguez (JIRA)]

Mila Rodriguez created CASSANDRA-14446:
--

 Summary: Cassandra will not start on JRE 10
 Key: CASSANDRA-14446
 URL: https://issues.apache.org/jira/browse/CASSANDRA-14446
 Project: Cassandra
  Issue Type: Bug
 Environment: JDK 10.0.1
Reporter: Mila Rodriguez


Clean install of Windows 10 Home 64 bit, JDK 10.0.1, Cassandra 3.11.2.

Attempted to start Cassandra for the first time:

 
{code:java}
PS C:\javatools> cassandra -f
*-*
*-*
WARNING! Automatic page file configuration detected.
 It is recommended that you disable swap when running Cassandra
 for performance and stability reasons.
*-*
*-*
Failed 64-bit check. Re-running to get version from 32-bit
*-*
*-*
Cassandra 3.0 and later require Java 8u40 or later.
{code}
 

Result of `java -version` check:
{code:java}
PS C:\javatools> java -version
java version "10.0.1" 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode){code}


My guess would be that the change in versioning scheme ("10.0.1" instead of 
something a la "1.8.0_40") is what is causing this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o

[Patrick Bannister (JIRA)]

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

Patrick Bannister commented on CASSANDRA-14298:
---

I've made a lot of progress porting cqlshlib to Python 3. Along the way I've 
been taking notes on all the areas that I think would require extra effort for 
cross compatibility with Python 2.

I don't have a complete plan yet, but I have some observations.

In terms of level of effort and complexity, this is not going to be as simple 
as running 2to3 and then adding a few imports from future and six. However, we 
won't need to rearchitect the library either. So far I've found that existing 
classes and functions work with just a few tweaks to their implementation, 
mostly around IO and strings vs. bytes.

The biggest challenge, regardless of whether we go straight Python 3 or 
cross-compatible, is going to be adequately testing the result. The cqlshlib 
unittests and the cqlsh_tests have been useful to help find bugs, but I'm not 
confident that our tests have enough code coverage to exercise everything. We 
would need a strategy for more comprehensive testing.

Some specifics:
 * The SaferScanner class in saferscanner.py requires a slightly different 
implementation in Python 2 vs. Python 3, because of changes in the internals of 
the re module for regular expressions.
 * copyutil.py, formatting.py, and displaying.py have needed the most work so 
far, since they have a lot of IO and serialization.
 * The formatter for blobs in formatting.py needs a different implementation in 
Python 2 vs. Python 3, because of changes in the behavior of binascii.hexlify.
 * On the dtests side, there are several tests that fail intermittently due to 
different sorting between expected results and observed results. The result of 
these tests is flaky depending on what randomly occurring sort happens to come 
out of the test. I've been able to get these tests to pass consistently by 
sorting results just before asserting equality.
 * Another notable dtest issue: in the cqlsh_copy_tests, the bulk_round_trip 
tests that use the blogposts profile are failing because of a limitation of the 
Python csv.reader, which is used in cqlshlib3 and in the bulk_round_trip tests. 
Python's csv.reader chokes on newlines and null characters, but the 
cassandra-stress tool's Strings Generator subclass generates both of these 
things in text fields.

> cqlshlib tests broken on b.a.o
> --
>
> Key: CASSANDRA-14298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14298
> Project: Cassandra
>  Issue Type: Bug
>  Components: Build, Testing
>Reporter: Stefan Podkowinski
>Assignee: Patrick Bannister
>Priority: Major
>  Labels: cqlsh, dtest
> Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, 
> cqlsh_tests_notes.md
>
>
> It appears that cqlsh-tests on builds.apache.org on all branches stopped 
> working since we removed nosetests from the system environment. See e.g. 
> [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console].
>  Looks like we either have to make nosetests available again or migrate to 
> pytest as we did with dtests. Giving pytest a quick try resulted in many 
> errors locally, but I haven't inspected them in detail yet. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14417) nodetool import cleanup/fixes

[Jordan West (JIRA)]

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

Jordan West edited comment on CASSANDRA-14417 at 5/15/18 11:19 PM:
---

* The output when {{extended=false}}, {{checkOwnsTokens=true}} is still debug 
(because the message was removed and the exception is logged as debug). I see 
it changed when extended=true. Verifier#L217.
 * While cleaning things up, should 
{{ColumnFamilyStore#findBestDiskAndInvalidateCaches}} be refactored to use 
{{KeyIterator}} as well?
 * EDIT: Also, just noticed the failing dtest. Seems to be in an area 
related-ish to these changes but I am not familiar enough with it yet to know 
if its related or just a flaky test. 


was (Author: jrwest):
* The output when {{extended=false}}, {{checkOwnsTokens=true}} is still debug 
(because the message was removed and the exception is logged as debug). I see 
it changed when extended=true. Verifier#L217.
 * While cleaning things up, should 
{{ColumnFamilyStore#findBestDiskAndInvalidateCaches}} be refactored to use 
{{KeyIterator}} as well?

> nodetool import cleanup/fixes
> -
>
> Key: CASSANDRA-14417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14417
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> * We shouldn't expose importNewSSTables in both StorageServiceMBean and 
> CFSMbean
> * Allow a quicker token check without doing an extended verify
> * Introduce an ImportOptions class to avoid passing in 100 booleans in 
> importNewSSTables



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14417) nodetool import cleanup/fixes

[Jordan West (JIRA)]

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

Jordan West commented on CASSANDRA-14417:
-

* The output when {{extended=false}}, {{checkOwnsTokens=true}} is still debug 
(because the message was removed and the exception is logged as debug). I see 
it changed when extended=true. Verifier#L217.
 * While cleaning things up, should 
{{ColumnFamilyStore#findBestDiskAndInvalidateCaches}} be refactored to use 
{{KeyIterator}} as well?

> nodetool import cleanup/fixes
> -
>
> Key: CASSANDRA-14417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14417
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> * We shouldn't expose importNewSSTables in both StorageServiceMBean and 
> CFSMbean
> * Allow a quicker token check without doing an extended verify
> * Introduce an ImportOptions class to avoid passing in 100 booleans in 
> importNewSSTables



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-10726:
-

I reworked the patch after the recent read repair chance changes 
[here|https://github.com/bdeggleston/cassandra/tree/10726-v4], with dtests 
[here|https://github.com/bdeggleston/cassandra-dtest/tree/10726-v2], and a 
green test run 
[here|https://circleci.com/workflow-run/8e150317-aaf1-43db-b3ba-36327f05b7db]

> Read repair inserts should not be blocking
> --
>
> Key: CASSANDRA-10726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination
>Reporter: Richard Low
>Assignee: Blake Eggleston
>Priority: Major
> Fix For: 4.x
>
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-14407) Transient Replication: Add support for correct reads when transient replication is in use

[Blake Eggleston (JIRA)]

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

Blake Eggleston reassigned CASSANDRA-14407:
---

Assignee: Blake Eggleston

> Transient Replication: Add support for correct reads when transient 
> replication is in use
> -
>
> Key: CASSANDRA-14407
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14407
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination
>Reporter: Ariel Weisberg
>Assignee: Blake Eggleston
>Priority: Major
> Fix For: 4.0
>
>
> Digest reads should never be sent to transient replicas.
> Mismatches with results from transient replicas shouldn't trigger read repair.
> Read repair should never attempt to repair a transient replica.
> Reads should always include at least one full replica. They should also 
> prefer transient replicas where possible.
> Range scans must ensure the entire scanned range performs replica selection 
> that satisfies the requirement that every range scanned includes one full 
> replica.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14437) SSTableLoader does not work when "internode_encryption : all" is set

[Paul Cheon (JIRA)]

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

Paul Cheon commented on CASSANDRA-14437:


I tried sstableloader from a node which is not in the cluster, but it could not 
connect to any cluster node 

{noformat}
pcheon@tor-paul-cas002:~/test$ sstableloader -v -d 10.1.10.203 
office_audit/log/ -f /etc/cassandra/cassandra.yaml -u pcheon -pw `cat .secret`
WARN  19:27:44,533 Small commitlog volume detected at 
/var/lib/cassandra/commitlog; setting commitlog_total_space_in_mb to 2316.  You 
can override this in cassandra.yaml
WARN  19:27:44,542 Small cdc volume detected at /var/lib/cassandra/cdc_raw; 
setting cdc_total_space_in_mb to 1158.  You can override this in cassandra.yaml
WARN  19:27:44,652 Only 7.232GiB free across all data volumes. Consider adding 
more capacity to your cluster or removing obsolete snapshots
WARN  19:27:46,784 Error while computing token map for keyspace 
vdc_ca_cdval_prdrel with datacenter tor: could not achieve replication factor 3 
(found 1 replicas only), check your keyspace replication settings.
Established connection to initial hosts
Opening sstables and calculating sections to stream
Streaming relevant part of 
/home/pcheon/test/office_audit/log/mc-1083-big-Data.db 
/home/pcheon/test/office_audit/log/mc-1100-big-Data.db 
/home/pcheon/test/office_audit/log/mc-1101-big-Data.db 
/home/pcheon/test/office_audit/log/mc-257-big-Data.db 
/home/pcheon/test/office_audit/log/mc-984-big-Data.db  to [/10.1.10.201, 
/10.1.10.203, /10.1.10.202]
ERROR 19:27:51,281 [Stream #0e5a8a40-5876-11e8-90c3-61730bfdf719] Streaming 
error occurred on session with peer 10.1.10.203
java.net.SocketException: Invalid argument or cannot assign requested address
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_112]
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) 
~[na:1.8.0_112]
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
 ~[na:1.8.0_112]
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) 
~[na:1.8.0_112]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) 
~[na:1.8.0_112]
at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_112]
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) 
~[na:1.8.0_112]
at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:495) 
~[na:1.8.0_112]
at 
sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:169)
 ~[na:1.8.0_112]
at 
org.apache.cassandra.security.SSLFactory.getSocket(SSLFactory.java:81) 
~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.tools.BulkLoadConnectionFactory.createConnection(BulkLoadConnectionFactory.java:56)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.streaming.StreamSession.createConnection(StreamSession.java:282)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.streaming.ConnectionHandler.initiate(ConnectionHandler.java:86)
 ~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.streaming.StreamSession.start(StreamSession.java:269) 
~[apache-cassandra-3.11.2.jar:3.11.2]
at 
org.apache.cassandra.streaming.StreamCoordinator$StreamSessionConnector.run(StreamCoordinator.java:263)
 [apache-cassandra-3.11.2.jar:3.11.2]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_112]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_112]
at 
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
 [apache-cassandra-3.11.2.jar:3.11.2]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_112]
ERROR 19:27:51,286 [Stream #0e5a8a40-5876-11e8-90c3-61730bfdf719] Streaming 
error occurred on session with peer 10.1.10.202
java.net.SocketException: Invalid argument or cannot assign requested address
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_112]
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) 
~[na:1.8.0_112]
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
 ~[na:1.8.0_112]
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) 
~[na:1.8.0_112]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) 
~[na:1.8.0_112]
at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_112]
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) 
~[na:1.8.0_112]
at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:495) 
~[na:1.8.0_112]
at 
sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:169)
 

[jira] [Commented] (CASSANDRA-14073) Prevent replacement nodes from skipping bootstrapping without allow_unsafe_replace:true

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-14073:


[~bdeggleston] Please make sure you read CASSANDRA-5836 for context


> Prevent replacement nodes from skipping bootstrapping without 
> allow_unsafe_replace:true
> ---
>
> Key: CASSANDRA-14073
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14073
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Vincent White
>Assignee: Vincent White
>Priority: Minor
>  Labels: bootstrap, patch
> Fix For: 3.11.x
>
>
> I've noticed that when replacing a node with replace_address it can skip 
> bootstrapping if it is listed in its own seed list. This probably shouldn't 
> be allowed without the allow_unsafe_replace option set to true as is required 
> when using auto_bootstrap: false in combination with replace_address. Patch 
> [here|https://github.com/vincewhite/cassandra/commits/replace_address_seed_list]
>  and an attempt at a dtest 
> [here|https://github.com/vincewhite/cassandra-dtest/commits/unsafe_replace]. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14073) Prevent replacement nodes from skipping bootstrapping without allow_unsafe_replace:true

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-14073:
-

Seems like this is also an issue in 3.0 and trunk. Could you provide patches 
for them as well?

> Prevent replacement nodes from skipping bootstrapping without 
> allow_unsafe_replace:true
> ---
>
> Key: CASSANDRA-14073
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14073
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Vincent White
>Assignee: Vincent White
>Priority: Minor
>  Labels: bootstrap, patch
> Fix For: 3.11.x
>
>
> I've noticed that when replacing a node with replace_address it can skip 
> bootstrapping if it is listed in its own seed list. This probably shouldn't 
> be allowed without the allow_unsafe_replace option set to true as is required 
> when using auto_bootstrap: false in combination with replace_address. Patch 
> [here|https://github.com/vincewhite/cassandra/commits/replace_address_seed_list]
>  and an attempt at a dtest 
> [here|https://github.com/vincewhite/cassandra-dtest/commits/unsafe_replace]. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-8460) Make it possible to move non-compacting sstables to slow/big storage in DTCS

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-8460:
---
Reviewer:   (was: Blake Eggleston)

> Make it possible to move non-compacting sstables to slow/big storage in DTCS
> 
>
> Key: CASSANDRA-8460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8460
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Lerh Chuan Low
>Priority: Major
>  Labels: doc-impacting, dtcs
> Fix For: 4.x
>
>
> It would be nice if we could configure DTCS to have a set of extra data 
> directories where we move the sstables once they are older than 
> max_sstable_age_days. 
> This would enable users to have a quick, small SSD for hot, new data, and big 
> spinning disks for data that is rarely read and never compacted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14073) Prevent replacement nodes from skipping bootstrapping without allow_unsafe_replace:true

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-14073:

Reviewer: Blake Eggleston

> Prevent replacement nodes from skipping bootstrapping without 
> allow_unsafe_replace:true
> ---
>
> Key: CASSANDRA-14073
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14073
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Vincent White
>Assignee: Vincent White
>Priority: Minor
>  Labels: bootstrap, patch
> Fix For: 3.11.x
>
>
> I've noticed that when replacing a node with replace_address it can skip 
> bootstrapping if it is listed in its own seed list. This probably shouldn't 
> be allowed without the allow_unsafe_replace option set to true as is required 
> when using auto_bootstrap: false in combination with replace_address. Patch 
> [here|https://github.com/vincewhite/cassandra/commits/replace_address_seed_list]
>  and an attempt at a dtest 
> [here|https://github.com/vincewhite/cassandra-dtest/commits/unsafe_replace]. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14437) SSTableLoader does not work when "internode_encryption : all" is set

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-14437:
--

Seems that because it's trying to bind on port 7001 and you're running it from 
an existing node that is already bound on 7001 it might have problems. I have 
no idea why {{internode_encryption: none}} is working however.

Try running {{sstableloader}} from a node not in the cluster, otherwise use 
 to bind on a different port. Unfortunately configuration 
of port for internode communication is only going to be available in 4.0.

> SSTableLoader does not work when "internode_encryption : all" is set
> 
>
> Key: CASSANDRA-14437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14437
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Paul Cheon
>Priority: Major
> Fix For: 3.11.2
>
>
> I am trying to use sstableloader to restore snapshot.
> If "internode_encryption :  all" is set, then it does not work and complain 
> with below error messages.  I initiated sstableloader from 10.1.10.203 
> (yvr-paul-cas003), so 10.1.10.203 worked fine, but the the other two nodes 
> (10.1.10.201 & 10.1.10.202 failed)
> {noformat}
> pcheon@yvr-paul-cas003:~/t$ sstableloader -v -d 10.1.10.203 office_audit/log/ 
> -f /etc/cassandra/cassandra.yaml -u pcheon -pw `cat .secret`
> WARN  17:23:45,166 Small commitlog volume detected at 
> /var/lib/cassandra/commitlog; setting commitlog_total_space_in_mb to 2316.  
> You can override this in cassandra.yaml
> WARN  17:23:45,170 Small cdc volume detected at /var/lib/cassandra/cdc_raw; 
> setting cdc_total_space_in_mb to 1158.  You can override this in 
> cassandra.yaml
> WARN  17:23:45,285 Only 5.318GiB free across all data volumes. Consider 
> adding more capacity to your cluster or removing obsolete snapshots
> Established connection to initial hosts
> Opening sstables and calculating sections to stream
> Streaming relevant part of 
> /home/pcheon/t/office_audit/log/mc-1083-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-1100-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-1101-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-257-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-984-big-Data.db  to [/10.1.10.201, 
> /10.1.10.203, /10.1.10.202]
> ERROR 17:23:49,460 [Stream #938baee0-4e2d-11e8-9be0-ebc69ba4b87f] Streaming 
> error occurred on session with peer 10.1.10.201
> java.net.SocketException: Invalid argument or cannot assign requested address
>   at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) 
> ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
>  ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) 
> ~[na:1.8.0_112]
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) 
> ~[na:1.8.0_112]
>   at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_112]
>   at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) 
> ~[na:1.8.0_112]
>   at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:495) 
> ~[na:1.8.0_112]
>   at 
> sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:169)
>  ~[na:1.8.0_112]
>   at 
> org.apache.cassandra.security.SSLFactory.getSocket(SSLFactory.java:81) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.tools.BulkLoadConnectionFactory.createConnection(BulkLoadConnectionFactory.java:56)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamSession.createConnection(StreamSession.java:282)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler.initiate(ConnectionHandler.java:86)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamSession.start(StreamSession.java:269) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamCoordinator$StreamSessionConnector.run(StreamCoordinator.java:263)
>  [apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_112]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_112]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.2.jar:3.11.2]
>   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_112]
> ERROR 17:23:49,458 [Stream #938baee0-4e2d-11e8-9be0-ebc69ba4b87f] 

[jira] [Comment Edited] (CASSANDRA-14437) SSTableLoader does not work when "internode_encryption : all" is set

[Paul Cheon (JIRA)]

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

Paul Cheon edited comment on CASSANDRA-14437 at 5/15/18 4:52 PM:
-

The content of yaml file is exact same except the node keystore file 
{code}
  keystore: "/etc/ssl/visier/10.1.119.203.jks"
{code}

The keystore password is same though.  Just the certificate inside of the 
keystore is generated with the IP address of each node

Trust keystore is same file in every node






was (Author: paul.ch...@visiercorp.com):
The content of yaml file is exact same except the node keystore file 
{code}
  keystore: "/etc/ssl/visier/10.1.119.203.jks"
{code}

The keystore password is same though.  Just the certificate inside of the 
keystore is generated with the IP address of each node



> SSTableLoader does not work when "internode_encryption : all" is set
> 
>
> Key: CASSANDRA-14437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14437
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Paul Cheon
>Priority: Major
> Fix For: 3.11.2
>
>
> I am trying to use sstableloader to restore snapshot.
> If "internode_encryption :  all" is set, then it does not work and complain 
> with below error messages.  I initiated sstableloader from 10.1.10.203 
> (yvr-paul-cas003), so 10.1.10.203 worked fine, but the the other two nodes 
> (10.1.10.201 & 10.1.10.202 failed)
> {noformat}
> pcheon@yvr-paul-cas003:~/t$ sstableloader -v -d 10.1.10.203 office_audit/log/ 
> -f /etc/cassandra/cassandra.yaml -u pcheon -pw `cat .secret`
> WARN  17:23:45,166 Small commitlog volume detected at 
> /var/lib/cassandra/commitlog; setting commitlog_total_space_in_mb to 2316.  
> You can override this in cassandra.yaml
> WARN  17:23:45,170 Small cdc volume detected at /var/lib/cassandra/cdc_raw; 
> setting cdc_total_space_in_mb to 1158.  You can override this in 
> cassandra.yaml
> WARN  17:23:45,285 Only 5.318GiB free across all data volumes. Consider 
> adding more capacity to your cluster or removing obsolete snapshots
> Established connection to initial hosts
> Opening sstables and calculating sections to stream
> Streaming relevant part of 
> /home/pcheon/t/office_audit/log/mc-1083-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-1100-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-1101-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-257-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-984-big-Data.db  to [/10.1.10.201, 
> /10.1.10.203, /10.1.10.202]
> ERROR 17:23:49,460 [Stream #938baee0-4e2d-11e8-9be0-ebc69ba4b87f] Streaming 
> error occurred on session with peer 10.1.10.201
> java.net.SocketException: Invalid argument or cannot assign requested address
>   at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) 
> ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
>  ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) 
> ~[na:1.8.0_112]
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) 
> ~[na:1.8.0_112]
>   at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_112]
>   at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) 
> ~[na:1.8.0_112]
>   at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:495) 
> ~[na:1.8.0_112]
>   at 
> sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:169)
>  ~[na:1.8.0_112]
>   at 
> org.apache.cassandra.security.SSLFactory.getSocket(SSLFactory.java:81) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.tools.BulkLoadConnectionFactory.createConnection(BulkLoadConnectionFactory.java:56)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamSession.createConnection(StreamSession.java:282)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler.initiate(ConnectionHandler.java:86)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamSession.start(StreamSession.java:269) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamCoordinator$StreamSessionConnector.run(StreamCoordinator.java:263)
>  [apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_112]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_112]
>   at 
> 

[jira] [Commented] (CASSANDRA-14437) SSTableLoader does not work when "internode_encryption : all" is set

[Paul Cheon (JIRA)]

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

Paul Cheon commented on CASSANDRA-14437:


The content of yaml file is exact same except the node keystore file 
{code}
  keystore: "/etc/ssl/visier/10.1.119.203.jks"
{code}

The keystore password is same though.  Just the certificate inside of the 
keystore is generated with the IP address of each node



> SSTableLoader does not work when "internode_encryption : all" is set
> 
>
> Key: CASSANDRA-14437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14437
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Paul Cheon
>Priority: Major
> Fix For: 3.11.2
>
>
> I am trying to use sstableloader to restore snapshot.
> If "internode_encryption :  all" is set, then it does not work and complain 
> with below error messages.  I initiated sstableloader from 10.1.10.203 
> (yvr-paul-cas003), so 10.1.10.203 worked fine, but the the other two nodes 
> (10.1.10.201 & 10.1.10.202 failed)
> {noformat}
> pcheon@yvr-paul-cas003:~/t$ sstableloader -v -d 10.1.10.203 office_audit/log/ 
> -f /etc/cassandra/cassandra.yaml -u pcheon -pw `cat .secret`
> WARN  17:23:45,166 Small commitlog volume detected at 
> /var/lib/cassandra/commitlog; setting commitlog_total_space_in_mb to 2316.  
> You can override this in cassandra.yaml
> WARN  17:23:45,170 Small cdc volume detected at /var/lib/cassandra/cdc_raw; 
> setting cdc_total_space_in_mb to 1158.  You can override this in 
> cassandra.yaml
> WARN  17:23:45,285 Only 5.318GiB free across all data volumes. Consider 
> adding more capacity to your cluster or removing obsolete snapshots
> Established connection to initial hosts
> Opening sstables and calculating sections to stream
> Streaming relevant part of 
> /home/pcheon/t/office_audit/log/mc-1083-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-1100-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-1101-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-257-big-Data.db 
> /home/pcheon/t/office_audit/log/mc-984-big-Data.db  to [/10.1.10.201, 
> /10.1.10.203, /10.1.10.202]
> ERROR 17:23:49,460 [Stream #938baee0-4e2d-11e8-9be0-ebc69ba4b87f] Streaming 
> error occurred on session with peer 10.1.10.201
> java.net.SocketException: Invalid argument or cannot assign requested address
>   at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) 
> ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
>  ~[na:1.8.0_112]
>   at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) 
> ~[na:1.8.0_112]
>   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) 
> ~[na:1.8.0_112]
>   at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_112]
>   at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) 
> ~[na:1.8.0_112]
>   at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:495) 
> ~[na:1.8.0_112]
>   at 
> sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:169)
>  ~[na:1.8.0_112]
>   at 
> org.apache.cassandra.security.SSLFactory.getSocket(SSLFactory.java:81) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.tools.BulkLoadConnectionFactory.createConnection(BulkLoadConnectionFactory.java:56)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamSession.createConnection(StreamSession.java:282)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.ConnectionHandler.initiate(ConnectionHandler.java:86)
>  ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamSession.start(StreamSession.java:269) 
> ~[apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> org.apache.cassandra.streaming.StreamCoordinator$StreamSessionConnector.run(StreamCoordinator.java:263)
>  [apache-cassandra-3.11.2.jar:3.11.2]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_112]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_112]
>   at 
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
>  [apache-cassandra-3.11.2.jar:3.11.2]
>   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_112]
> ERROR 17:23:49,458 [Stream #938baee0-4e2d-11e8-9be0-ebc69ba4b87f] Streaming 
> error occurred on session with peer 10.1.10.202
> java.net.SocketException: Invalid argument or cannot assign requested address
>   at 

[jira] [Commented] (CASSANDRA-14415) Performance regression in queries for distinct keys

[Samuel Klock (JIRA)]

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

Samuel Klock commented on CASSANDRA-14415:
--

Thanks.  NPE in 3.11 and {{IOException}} in trunk sounds very reasonable.  The 
patches now reflect that feedback.

||Patch||Tests||
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...akasklock:CASSANDRA-14415-Use-seek-for-skipBytes-3.11.2]
 |[link|https://circleci.com/gh/akasklock/cassandra/12] |
|[trunk|https://github.com/apache/cassandra/compare/trunk...akasklock:CASSANDRA-14415-Use-seek-for-skipBytes-trunk]
 |[link|https://circleci.com/gh/akasklock/cassandra/13] |

* All of the tests for trunk passed in this run.
* The patch for 3.11 should also apply to 3.0, but as noted above, we're not 
confident it would be useful without CASSANDRA-10657, at least for the workflow 
we're concerned about in this issue.

> Performance regression in queries for distinct keys
> ---
>
> Key: CASSANDRA-14415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14415
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Samuel Klock
>Assignee: Samuel Klock
>Priority: Major
>  Labels: performance
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Running Cassandra 3.0.16, we observed a major performance regression 
> affecting {{SELECT DISTINCT keys}}-style queries against certain tables.  
> Based on some investigation (guided by some helpful feedback from Benjamin on 
> the dev list), we tracked the regression down to two problems.
>  * One is that Cassandra was reading more data from disk than was necessary 
> to satisfy the query.  This was fixed under CASSANDRA-10657 in a later 3.x 
> release.
>  * If the fix for CASSANDRA-10657 is incorporated, the other is this code 
> snippet in {{RebufferingInputStream}}:
> {code:java}
>     @Override
>     public int skipBytes(int n) throws IOException
>     {
>     if (n < 0)
>     return 0;
>     int requested = n;
>     int position = buffer.position(), limit = buffer.limit(), remaining;
>     while ((remaining = limit - position) < n)
>     {
>     n -= remaining;
>     buffer.position(limit);
>     reBuffer();
>     position = buffer.position();
>     limit = buffer.limit();
>     if (position == limit)
>     return requested - n;
>     }
>     buffer.position(position + n);
>     return requested;
>     }
> {code}
> The gist of it is that to skip bytes, the stream needs to read those bytes 
> into memory then throw them away.  In our tests, we were spending a lot of 
> time in this method, so it looked like the chief drag on performance.
> We noticed that the subclass of {{RebufferingInputStream}} in use for our 
> queries, {{RandomAccessReader}} (over compressed sstables), implements a 
> {{seek()}} method.  Overriding {{skipBytes()}} in it to use {{seek()}} 
> instead was sufficient to fix the performance regression.
> The performance difference is significant for tables with large values.  It's 
> straightforward to evaluate with very simple key-value tables, e.g.:
> {{CREATE TABLE testtable (key TEXT PRIMARY KEY, value BLOB);}}
> We did some basic experimentation with the following variations (all in a 
> single-node 3.11.2 cluster with off-the-shelf settings running on a dev 
> workstation):
>  * small values (1 KB, 100,000 entries), somewhat larger values (25 KB, 
> 10,000 entries), and much larger values (1 MB, 10,000 entries);
>  * compressible data (a single byte repeated) and uncompressible data (output 
> from {{openssl rand $bytes}}); and
>  * with and without sstable compression.  (With compression, we use 
> Cassandra's defaults.)
> The difference is most conspicuous for tables with large, uncompressible data 
> and sstable decompression (which happens to describe the use case that 
> triggered our investigation).  It is smaller but still readily apparent for 
> tables with effective compression.  For uncompressible data without 
> compression enabled, there is no appreciable difference.
> Here's what the performance looks like without our patch for the 1-MB entries 
> (times in seconds, five consecutive runs for each data set, all exhausting 
> the results from a {{SELECT DISTINCT key FROM ...}} query with a page size of 
> 24):
> {noformat}
> working on compressible
> 5.21180510521
> 5.10270500183
> 5.22311806679
> 4.6732840538
> 4.84219098091
> working on uncompressible_uncompressed
> 55.0423607826
> 0.769015073776
> 0.850513935089
> 0.713396072388
> 0.62596988678
> working on uncompressible
> 413.292617083
> 231.345913887
> 449.524993896
> 425.135111094
> 243.469946861
> {noformat}
> and with the fix:
> {noformat}
> 

[jira] [Commented] (CASSANDRA-14418) Cassandra not starting when using enhanced startup scripts in windows

[Shyam Phirke (JIRA)]

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

Shyam Phirke commented on CASSANDRA-14418:
--

And thank you very much guys for help.

> Cassandra not starting when using enhanced startup scripts in windows
> -
>
> Key: CASSANDRA-14418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14418
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Shyam Phirke
>Assignee: Shyam Phirke
>Priority: Major
> Fix For: 4.0, 3.0.17, 3.11.3
>
>
> I am using Apache Cassandra 3.11.2 with my application. 
> My application is getting installed under C:/Program Files/My 
> Application/Some Folder/.
> And cassandra C:/Program Files/My Application/Some Folder/cassandra.
> So when I am using enhanced startup scripts cassandra not getting up and 
> running and I am getting below error:
> "Error: Could not find or load main class Files\My"
> One of the solution I got is moving cassandra to another location where 
> location path does not contain spaces. But this is not good way of getting 
> this problem resolved.
> After doing detailed analysis of all the scripts I found the solution below:
> Inside file cassandra-env.ps1 at line number 380:
> Replace line:
> $env:JVM_OPTS = "$env:JVM_OPTS 
> -XX:CompileCommandFile=$env:CASSANDRA_CONF\hotspot_compiler"
> with line
> $env:JVM_OPTS = "$env:JVM_OPTS 
> -XX:CompileCommandFile=""$env:CASSANDRA_CONF\hotspot_compiler"""
> Fix here is the double quotes added before $env:CASSANDRA_CONF and at the end.
> At other places this case is well handled. But missed at this place.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14418) Cassandra not starting when using enhanced startup scripts in windows

[Shyam Phirke (JIRA)]

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

Shyam Phirke commented on CASSANDRA-14418:
--

Any idea about 3.11.3 release date?

> Cassandra not starting when using enhanced startup scripts in windows
> -
>
> Key: CASSANDRA-14418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14418
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Shyam Phirke
>Assignee: Shyam Phirke
>Priority: Major
> Fix For: 4.0, 3.0.17, 3.11.3
>
>
> I am using Apache Cassandra 3.11.2 with my application. 
> My application is getting installed under C:/Program Files/My 
> Application/Some Folder/.
> And cassandra C:/Program Files/My Application/Some Folder/cassandra.
> So when I am using enhanced startup scripts cassandra not getting up and 
> running and I am getting below error:
> "Error: Could not find or load main class Files\My"
> One of the solution I got is moving cassandra to another location where 
> location path does not contain spaces. But this is not good way of getting 
> this problem resolved.
> After doing detailed analysis of all the scripts I found the solution below:
> Inside file cassandra-env.ps1 at line number 380:
> Replace line:
> $env:JVM_OPTS = "$env:JVM_OPTS 
> -XX:CompileCommandFile=$env:CASSANDRA_CONF\hotspot_compiler"
> with line
> $env:JVM_OPTS = "$env:JVM_OPTS 
> -XX:CompileCommandFile=""$env:CASSANDRA_CONF\hotspot_compiler"""
> Fix here is the double quotes added before $env:CASSANDRA_CONF and at the end.
> At other places this case is well handled. But missed at this place.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-14126) don't work udf javascripts

[Horia Mocioi (JIRA)]

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

Horia Mocioi edited comment on CASSANDRA-14126 at 5/15/18 12:36 PM:


[Alex 
Lourie|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=alourie] The 
keyspace and table are created as before. The only thing that I changed was the 
function and that one is in my previous comment.


was (Author: umcanl):
The keyspace and table are created as before. The only thing that I changed was 
the function and that one is in my previous comment.

> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Denis Pershin
>Assignee: Alex Lourie
>Priority: Minor
>  Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy', 
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL 
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return 
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A  (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
>  line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'testkeyspace.first_int[set]' failed: 
> java.security.AccessControlException: access denied: 
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set) 
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS 
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A  (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
>   File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
>   File 
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
>  line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure] 
> message="execution of 'testkeyspace.first_int[set]' failed: 
> java.security.AccessControlException: access denied: 
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13669) Error when starting cassandra: Unable to make UUID from 'aa' (SASI index)

[JIRA]

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

Andrés de la Peña commented on CASSANDRA-13669:
---

bq. [~adelapena] do you mind having a look?

Sure, I'll take a look ASAP.

> Error when starting cassandra: Unable to make UUID from 'aa' (SASI index)
> -
>
> Key: CASSANDRA-13669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13669
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: Tested on:
> * macOS Sierra 10.12.5
> * Ubuntu 14.04.5 LTS
>Reporter: Lukasz Biedrycki
>Assignee: ZhaoYang
>Priority: Critical
>  Labels: sasi
> Fix For: 3.11.x
>
>
> Recently I experienced a problem that prevents me to restart cassandra.
> I narrowed it down to SASI Index when added on uuid field.
> Steps to reproduce:
> 1. start cassandra (./bin/cassandra -f)
> 2. create keyspace, table, index and add data:
> {noformat}
> CREATE KEYSPACE testkeyspace
> WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} 
>AND durable_writes = true;
> use testkeyspace ;
> CREATE TABLE testtable (
>col1 uuid,
>col2 uuid,
>ts timeuuid,
>col3 uuid,
>PRIMARY KEY((col1, col2), ts) ) with clustering order by (ts desc);
> CREATE CUSTOM INDEX col3_testtable_idx ON testtable(col3)
> USING 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer', 'mode': 
> 'PREFIX'};
> INSERT INTO testtable(col1, col2, ts, col3)
> VALUES(898e0014-6161-11e7-b9b7-238ea83bd70b,
>898e0014-6161-11e7-b9b7-238ea83bd70b,
>now(), 898e0014-6161-11e7-b9b7-238ea83bd70b);
> {noformat}
> 3. restart cassandra
> It crashes with an error (sorry it's huge):
> {noformat}
> DEBUG 09:09:20 Writing Memtable-testtable@1005362073(0.075KiB serialized 
> bytes, 1 ops, 0%/0% of on/off-heap limit), flushed range = 
> (min(-9223372036854775808), max(9223372036854775807)]
> ERROR 09:09:20 Exception in thread 
> Thread[PerDiskMemtableFlushWriter_0:1,5,main]
> org.apache.cassandra.serializers.MarshalException: Unable to make UUID from 
> 'aa'
>   at 
> org.apache.cassandra.db.marshal.UUIDType.fromString(UUIDType.java:118) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer.hasNext(StandardAnalyzer.java:168)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.index.sasi.disk.PerSSTableIndexWriter$Index.add(PerSSTableIndexWriter.java:208)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.index.sasi.disk.PerSSTableIndexWriter.lambda$nextUnfilteredCluster$0(PerSSTableIndexWriter.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at java.util.Collections$SingletonSet.forEach(Collections.java:4767) 
> ~[na:1.8.0_131]
>   at 
> org.apache.cassandra.index.sasi.disk.PerSSTableIndexWriter.nextUnfilteredCluster(PerSSTableIndexWriter.java:119)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.ColumnIndex.lambda$add$1(ColumnIndex.java:233) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_131]
>   at org.apache.cassandra.db.ColumnIndex.add(ColumnIndex.java:233) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:107) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:169)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:458)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Memtable$FlushRunnable.call(Memtable.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Memtable$FlushRunnable.call(Memtable.java:380) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]
> Exception (java.lang.RuntimeException) encountered during startup: 
> java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
> java.util.concurrent.ExecutionException: 
> org.apache.cassandra.serializers.MarshalException: Unable to make 

[jira] [Updated] (CASSANDRA-13669) Error when starting cassandra: Unable to make UUID from 'aa' (SASI index)

[JIRA]

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

Andrés de la Peña updated CASSANDRA-13669:
--
Reproduced In: 3.11.1, 3.11.0, 4.0  (was: 3.11.0, 3.11.1, 4.0)
 Reviewer: Andrés de la Peña

> Error when starting cassandra: Unable to make UUID from 'aa' (SASI index)
> -
>
> Key: CASSANDRA-13669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13669
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
> Environment: Tested on:
> * macOS Sierra 10.12.5
> * Ubuntu 14.04.5 LTS
>Reporter: Lukasz Biedrycki
>Assignee: ZhaoYang
>Priority: Critical
>  Labels: sasi
> Fix For: 3.11.x
>
>
> Recently I experienced a problem that prevents me to restart cassandra.
> I narrowed it down to SASI Index when added on uuid field.
> Steps to reproduce:
> 1. start cassandra (./bin/cassandra -f)
> 2. create keyspace, table, index and add data:
> {noformat}
> CREATE KEYSPACE testkeyspace
> WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} 
>AND durable_writes = true;
> use testkeyspace ;
> CREATE TABLE testtable (
>col1 uuid,
>col2 uuid,
>ts timeuuid,
>col3 uuid,
>PRIMARY KEY((col1, col2), ts) ) with clustering order by (ts desc);
> CREATE CUSTOM INDEX col3_testtable_idx ON testtable(col3)
> USING 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {'analyzer_class': 
> 'org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer', 'mode': 
> 'PREFIX'};
> INSERT INTO testtable(col1, col2, ts, col3)
> VALUES(898e0014-6161-11e7-b9b7-238ea83bd70b,
>898e0014-6161-11e7-b9b7-238ea83bd70b,
>now(), 898e0014-6161-11e7-b9b7-238ea83bd70b);
> {noformat}
> 3. restart cassandra
> It crashes with an error (sorry it's huge):
> {noformat}
> DEBUG 09:09:20 Writing Memtable-testtable@1005362073(0.075KiB serialized 
> bytes, 1 ops, 0%/0% of on/off-heap limit), flushed range = 
> (min(-9223372036854775808), max(9223372036854775807)]
> ERROR 09:09:20 Exception in thread 
> Thread[PerDiskMemtableFlushWriter_0:1,5,main]
> org.apache.cassandra.serializers.MarshalException: Unable to make UUID from 
> 'aa'
>   at 
> org.apache.cassandra.db.marshal.UUIDType.fromString(UUIDType.java:118) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.index.sasi.analyzer.StandardAnalyzer.hasNext(StandardAnalyzer.java:168)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.index.sasi.disk.PerSSTableIndexWriter$Index.add(PerSSTableIndexWriter.java:208)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.index.sasi.disk.PerSSTableIndexWriter.lambda$nextUnfilteredCluster$0(PerSSTableIndexWriter.java:132)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at java.util.Collections$SingletonSet.forEach(Collections.java:4767) 
> ~[na:1.8.0_131]
>   at 
> org.apache.cassandra.index.sasi.disk.PerSSTableIndexWriter.nextUnfilteredCluster(PerSSTableIndexWriter.java:119)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.ColumnIndex.lambda$add$1(ColumnIndex.java:233) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at java.lang.Iterable.forEach(Iterable.java:75) ~[na:1.8.0_131]
>   at org.apache.cassandra.db.ColumnIndex.add(ColumnIndex.java:233) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:107) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:169)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:458)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Memtable$FlushRunnable.call(Memtable.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Memtable$FlushRunnable.call(Memtable.java:380) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]
> Exception (java.lang.RuntimeException) encountered during startup: 
> java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
> java.util.concurrent.ExecutionException: 
> org.apache.cassandra.serializers.MarshalException: Unable to make UUID from 
> 

[jira] [Commented] (CASSANDRA-13458) Diag. Events: Add unit testing support

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13458:


* Rebased against latest CASSANDRA-13457 WIP branch
 * Added {{OverrideConfigurationLoader}} to make tests work again after 
disabling diag events by default

Also addressed comments:
 * "shouldn't all classes for this ticket be added under src/test/" - moved 
helper classes to test/unit
 * "should `DiagnosticEventService.throwOnce(..)` be in the production code?" - 
I'd prefer keeping {{DiagnosticEventService.throwOnce}} next to 
{{DiagnosticEventService.once}} and the other subscribe methods, as all of them 
consume and transform events asynchronously in one way or another.
 * "interfaces don't need public methods" - fixed
 * "should classes be final (when possible)? (not sure about c* code style 
here)" - probably a matter of personal style, but I don't see why anyone should 
not extend the classes
 * "modifier order: `static final` not `final static`" - fixed
 * "i'm presuming HintsServiceEventsTest will be updated to assert against the 
extra DISPATCHING_PAUSED event at shutdown time" - assertion added

> Diag. Events: Add unit testing support
> --
>
> Key: CASSANDRA-13458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13458
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> Diagnostic events will improve unit testing by
> * providing test execution control instances based on CompletableFutures (see 
> [PendingRangeCalculatorServiceTest.java|https://github.com/spodkowinski/cassandra/blob/WIP-13458/test/unit/org/apache/cassandra/gms/PendingRangeCalculatorServiceTest.java])
>  
> * validate state and behavior by allowing you to inspect generated events 
> (see 
> [HintsServiceEventsTest.java|https://github.com/spodkowinski/cassandra/blob/WIP-13458/test/unit/org/apache/cassandra/hints/HintsServiceEventsTest.java])
> See included 
> [testing.rst|https://github.com/spodkowinski/cassandra/blob/WIP-13458/doc/source/development/testing.rst#diagnostic-events-40]
>  draft for more details. Let me know if this would be useful for you as a 
> developer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13668) Diag. events for user audit logging

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-13668:


I've now rebased the WIP branch on the new audit logging merged into branch 
(CASSANDRA-12151) and JMX instead of native transport. The actual code on top 
of it hasn't changed a lot, as it's only delegating AuditLogEntry events to the 
DiagnosticEventService.

> Diag. events for user audit logging
> ---
>
> Key: CASSANDRA-13668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13668
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> With the availability of CASSANDRA-13459, any native transport enabled client 
> will be able to subscribe to internal Cassandra events. External tools can 
> take advantage by monitoring these events in various ways. Use-cases for this 
> can be e.g. auditing tools for compliance and security purposes.
> The scope of this ticket is to add diagnostic events that are raised around 
> authentication and CQL operations. These events can then be consumed and used 
> by external tools to implement a Cassandra user auditing solution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13459) Diag. Events: Native transport integration

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-13459:
---
Status: Open  (was: Patch Available)

> Diag. Events: Native transport integration
> --
>
> Key: CASSANDRA-13459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13459
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: CQL
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>  Labels: client-impacting
>
> Events should be consumable by clients that would received subscribed events 
> from the connected node. This functionality is designed to work on top of 
> native transport with minor modifications to the protocol standard (see 
> [original 
> proposal|https://docs.google.com/document/d/1uEk7KYgxjNA0ybC9fOuegHTcK3Yi0hCQN5nTp5cNFyQ/edit?usp=sharing]
>  for further considered options). First we have to add another value for 
> existing event types. Also, we have to extend the protocol a bit to be able 
> to specify a sub-class and sub-type value. E.g. 
> {{DIAGNOSTIC_EVENT(GossiperEvent, MAJOR_STATE_CHANGE_HANDLED)}}. This still 
> has to be worked out and I'd appreciate any feedback.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14417) nodetool import cleanup/fixes

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-14417:
-

pushed a new commit addressing the comments: 
https://github.com/krummas/cassandra/commits/marcuse/14417
bq. In Verifier, is it more appropriate to favor OutputHandler#output over 
OutputHandler#debug for the error message when a key is out of range?
yeah, made it {{OutputHandler#warn}} 
bq. Would like to see some tests (including base/empty case, edge cases like 
wrap around) for {{RangeOwnHelper}}
added, also made it clearer that ROH can't continue to be used after finding an 
out-of-range token by making it throw exceptions instead of returning true/false

Also refactored {{Verifier}} to use a {{KeyIterator}} instead of manually 
deserializing the index when checking keys.

> nodetool import cleanup/fixes
> -
>
> Key: CASSANDRA-14417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14417
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Fix For: 4.x
>
>
> * We shouldn't expose importNewSSTables in both StorageServiceMBean and 
> CFSMbean
> * Allow a quicker token check without doing an extended verify
> * Introduce an ImportOptions class to avoid passing in 100 booleans in 
> importNewSSTables



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org