[jira] [Comment Edited] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252068#comment-17252068
]
Erik Merkle edited comment on CASSANDRA-16362 at 12/19/20, 1:18 AM:
For reference, I stumbled across this running integration tests in the Medusa
project for backup and restore. It was failing when run against trunk and
trying to restore a snapshot with sstableloader. The test uses CCM to run
Cassandra. If needed I could dig into the test setup and detail exactly what
steps are done.
An easier test for me was to simply try this code:
{code:java}
try {
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.getDefaultSSLParameters();
ctx.init(null, null, SecureRandom.getInstanceStrong());
} catch (Exception e) {
e.printStackTrace();
}
{code}
It fails the same way. Calling {{ctx.init()}} before
{{ctx.getDefaultSSLParameters()}} seems to not produce the "not initialized"
error.
was (Author: emerkle826):
For reference, I stumbled across this running integration tests in the Medusa
project for backup and restore. It was failing when run against trunk and
trying to restore a snapshot with sstableloader. The test uses CCM to run
Cassandra. If needed I could dig into the test setup and detail exactly what
steps are done.
An easier test for me was to simply try this code:
{code:java}
try {
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.getDefaultSSLParameters();
ctx.init(null, null, SecureRandom.getInstanceStrong());
} catch (Exception e) {
e.printStackTrace();
}
{code}
It fails the same way. Calling {{ctx.init()}} before
{{ctx.getDefaultSSLParameters()}} seems to no produce the "not initialized"
error.
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Erik Merkle
>Assignee: Jon Meredith
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252068#comment-17252068
]
Erik Merkle commented on CASSANDRA-16362:
-
For reference, I stumbled across this running integration tests in the Medusa
project for backup and restore. It was failing when run against trunk and
trying to restore a snapshot with sstableloader. The test uses CCM to run
Cassandra. If needed I could dig into the test setup and detail exactly what
steps are done.
An easier test for me was to simply try this code:
{code:java}
try {
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.getDefaultSSLParameters();
ctx.init(null, null, SecureRandom.getInstanceStrong());
} catch (Exception e) {
e.printStackTrace();
}
{code}
It fails the same way. Calling {{ctx.init()}} before
{{ctx.getDefaultSSLParameters()}} seems to no produce the "not initialized"
error.
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Erik Merkle
>Assignee: Jon Meredith
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252065#comment-17252065
]
David Capwell commented on CASSANDRA-16362:
---
replicated
{code}
Caused by: java.lang.IllegalStateException: SSLContextImpl is not initialized
at
sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:177)
at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:142)
at
javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:168)
at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:419)
at
org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
{code}
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Erik Merkle
>Assignee: Jon Meredith
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252063#comment-17252063
]
David Capwell commented on CASSANDRA-16362:
---
[~emerkle826] are you able to show the steps you did to hit this?
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Erik Merkle
>Assignee: Jon Meredith
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16332:
--
Fix Version/s: (was: 4.0-beta)
NA
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/c1a59823ef1595a3918e5b476b286f81672eb2cb
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: NA
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] 02/02: Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git commit f9c46ad462d894b3c08b3a547cdfc6ba21b49e53 Author: Adam Holmberg AuthorDate: Fri Dec 18 14:37:18 2020 -0800 Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes patch by Adam Holmberg; reviewed by Caleb Rackliffe, David Capwell for CASSANDRA-16332 --- upgrade_tests/upgrade_manifest.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/upgrade_tests/upgrade_manifest.py b/upgrade_tests/upgrade_manifest.py index be481a8..05e566e 100644 --- a/upgrade_tests/upgrade_manifest.py +++ b/upgrade_tests/upgrade_manifest.py @@ -136,7 +136,7 @@ indev_3_0_x = VersionMeta(name='indev_3_0_x', family='3.0', variant='indev', ver current_3_0_x = VersionMeta(name='current_3_0_x', family='3.0', variant='current', version='3.0.23', min_proto_v=3, max_proto_v=4, java_versions=(8,)) indev_3_11_x = VersionMeta(name='indev_3_11_x', family='3.11', variant='indev', version='github:apache/cassandra-3.11', min_proto_v=3, max_proto_v=4, java_versions=(8,)) -current_3_11_x = VersionMeta(name='current_3_11_x', family='3.11', variant='current', version='github:apache/cassandra-3.11', min_proto_v=3, max_proto_v=4, java_versions=(8,)) +current_3_11_x = VersionMeta(name='current_3_11_x', family='3.11', variant='current', version='3.11.9', min_proto_v=3, max_proto_v=4, java_versions=(8,)) indev_trunk = VersionMeta(name='indev_trunk', family='trunk', variant='indev', version='github:apache/trunk', min_proto_v=4, max_proto_v=5, java_versions=(8,)) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] 01/02: Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
commit c1a59823ef1595a3918e5b476b286f81672eb2cb
Author: Adam Holmberg
AuthorDate: Fri Dec 18 14:37:18 2020 -0800
Fix upgrade python dtest test_static_columns_with_2i -
upgrade_tests.cql_tests.TestCQLNodes
patch by Adam Holmberg; reviewed by Caleb Rackliffe, David Capwell for
CASSANDRA-16332
---
upgrade_tests/cql_tests.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/upgrade_tests/cql_tests.py b/upgrade_tests/cql_tests.py
index 1ce95ba..5c9ec78 100644
--- a/upgrade_tests/cql_tests.py
+++ b/upgrade_tests/cql_tests.py
@@ -4109,6 +4109,7 @@ class TestCQL(UpgradeTester):
def test_static_columns_with_2i(self):
cursor = self.prepare()
+initial_version = self.cluster.version()
cursor.execute("""
CREATE TABLE test (
@@ -4133,8 +4134,8 @@ class TestCQL(UpgradeTester):
assert_all(cursor, "SELECT * FROM test WHERE v = 1", [[0, 0, 42,
1], [0, 1, 42, 1]])
assert_all(cursor, "SELECT p, s FROM test WHERE v = 1", [[0, 42],
[1, 42]])
assert_all(cursor, "SELECT p FROM test WHERE v = 1", [[0], [1]])
-# We don't support that
-assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
+if initial_version >= LooseVersion('3.11.7'): # See
CASSANDRA-16332. This fails with a known limitation on versions before 3.11.7
(CASSANDRA-14242)
+assert_all(cursor, "SELECT s FROM test WHERE v = 1", [[42],
[42]])
@since('2.1')
def test_static_columns_with_distinct(self):
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated (7ba3bdd -> f9c46ad)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git. from 7ba3bdd Use the token allocation strategy generator tool for 4.0 vnode clusters, from CASSANDRA-16205 new c1a5982 Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes new f9c46ad Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: upgrade_tests/cql_tests.py| 5 +++-- upgrade_tests/upgrade_manifest.py | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16332:
--
Status: Ready to Commit (was: Review In Progress)
CI looks great! 22 failures now
https://app.circleci.com/pipelines/github/dcapwell/cassandra/856/workflows/e1f1542d-22b6-441d-946a-19724a0e7f06/jobs/5073/tests
all versions passed the tests.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-16362:
-
Test and Documentation Plan: Run through CircleCI
Status: Patch Available (was: Open)
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Erik Merkle
>Assignee: Jon Meredith
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252053#comment-17252053
]
Jon Meredith commented on CASSANDRA-16362:
--
[PR|https://github.com/apache/cassandra/pull/860]
[Branch|https://github.com/jonmeredith/cassandra/tree/C16362]
[CircleCI|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=C16362]
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Erik Merkle
>Assignee: Jon Meredith
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252042#comment-17252042
]
David Capwell commented on CASSANDRA-16332:
---
kicked off a build here:
https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=ci%2Ftrunk
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252041#comment-17252041
]
David Capwell commented on CASSANDRA-16332:
---
https://github.com/dcapwell/cassandra-dtest/tree/review/CASSANDRA-16332.
changed to 3.11.9
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252039#comment-17252039
]
David Capwell commented on CASSANDRA-16332:
---
I went to check that 3.11 was upgraded in the tests before running and I saw
the following
{code}
indev_3_11_x = VersionMeta(name='indev_3_11_x', family='3.11', variant='indev',
version='github:apache/cassandra-3.11', min_proto_v=3, max_proto_v=4,
java_versions=(8,))
current_3_11_x = VersionMeta(name='current_3_11_x', family='3.11',
variant='current', version='github:apache/cassandra-3.11', min_proto_v=3,
max_proto_v=4, java_versions=(8,))
{code}
indev and current are the same... =(. ill fix this in the patch as well.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252037#comment-17252037
]
David Capwell commented on CASSANDRA-16332:
---
yes, LooseVersion('3.11.7') should be enough
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252034#comment-17252034
]
Caleb Rackliffe commented on CASSANDRA-16332:
-
{noformat}
if initial_version > LooseVersion('3.11'): # See CASSANDRA-16332. This fails
with a known limitation on versions before 3.11 (CASSANDRA-14242)
assert_all(cursor, "SELECT s FROM test WHERE v = 1", [[42], [42]])
{noformat}
Do we have a way to check that the version is >= 3.11.7? That would give us the
most coverage, I suppose. Otherwise, LGTM.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252022#comment-17252022
]
David Capwell commented on CASSANDRA-16332:
---
+1 from me.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16332:
--
Reviewers: Caleb Rackliffe, David Capwell, David Capwell (was: Caleb
Rackliffe, David Capwell)
Caleb Rackliffe, David Capwell, David Capwell (was: Caleb
Rackliffe)
Status: Review In Progress (was: Patch Available)
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16332:
--
Authors: Adam Holmberg
Test and Documentation Plan: CI
Status: Patch Available (was: In Progress)
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251976#comment-17251976
]
David Capwell commented on CASSANDRA-16332:
---
spoke with Adam in slack; dumping context.
We talked about two options: @since(3.11) and if > 3.0 do the check. At the
end of our chat I think we settled on if > 3.0 do the check, the reasons were
the following:
* since(3.11) blocks the other asserts from happening, without an audit
(CASSANDRA-16321 still pending) we do not know if there is coverage for this
feature, so better to still keep those asserts
* if > 3.0 do check, else do old check - I don't like this as I don't think we
should be asserting the old behavior as I *feel* it was incorrect, so prefer
tests to show what we *should* do, not what we *do*
* if > 3.0 do check - this seems like the best comprise as it has the best of
both above without the two negatives listed.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251974#comment-17251974
]
Adam Holmberg commented on CASSANDRA-16332:
---
branch is updated with conditional. CI running again.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (6ea11f9 -> b0c50c1)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 6ea11f9 Merge branch 'cassandra-3.11' into trunk add b0c50c1 Prepare debian changelog for 4.0-beta4 No new revisions were added by this update. Summary of changes: debian/changelog | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251947#comment-17251947
]
Adam Holmberg edited comment on CASSANDRA-16332 at 12/18/20, 7:09 PM:
--
I was just thinking of adding a conditional in code (not annotation) since it's
a known limitation/different behavior in 3.0 that we have no intention of
changing. Seems like it would be nice to avoid that noise.
-If you think @since is sufficient, I'm good with that too.-
-edit: I'm actually not sure how @since works on upgrade tests when there is
both a "from" and a "to" version.-
Just ran it and it does what you would want.
was (Author: aholmber):
I was just thinking of adding a conditional in code (not annotation) since it's
a known limitation/different behavior in 3.0 that we have no intention of
changing. Seems like it would be nice to avoid that noise.
-If you think @since is sufficient, I'm good with that too.-
edit: I'm actually not sure how @since works on upgrade tests when there is
both a "from" and a "to" version.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251947#comment-17251947
]
Adam Holmberg edited comment on CASSANDRA-16332 at 12/18/20, 7:04 PM:
--
I was just thinking of adding a conditional in code (not annotation) since it's
a known limitation/different behavior in 3.0 that we have no intention of
changing. Seems like it would be nice to avoid that noise.
-If you think @since is sufficient, I'm good with that too.-
edit: I'm actually not sure how @since works on upgrade tests when there is
both a "from" and a "to" version.
was (Author: aholmber):
I was just thinking of adding a conditional in code (not annotation) since it's
a known limitation/different behavior in 3.0 that we have no intention of
changing. Seems like it would be nice to avoid that noise.
If you think @since is sufficient, I'm good with that too.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251947#comment-17251947
]
Adam Holmberg commented on CASSANDRA-16332:
---
I was just thinking of adding a conditional in code (not annotation) since it's
a known limitation/different behavior in 3.0 that we have no intention of
changing. Seems like it would be nice to avoid that noise.
If you think @since is sufficient, I'm good with that too.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251939#comment-17251939
]
David Capwell edited comment on CASSANDRA-16332 at 12/18/20, 6:49 PM:
--
I have mixed feelings on this: 1) build won't be green as we test 3.0 -> trunk,
2) 3.0 should be failing as it shouldn't be rejecting (select * works, but not
select static?)...
I feel that letting it fail is best as its shows an issue with 3.0. That, or
maybe add @since(3.11)?
was (Author: dcapwell):
I have mixed feelings on this: 1) build won't be green as we test 3.0 -> trunk,
2) 3.0 should be failing as it shouldn't be rejecting (select * works, but not
select static?)...
I feel that letting it fail is best as its shows an issue with 3.0.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251939#comment-17251939
]
David Capwell commented on CASSANDRA-16332:
---
I have mixed feelings on this: 1) build won't be green as we test 3.0 -> trunk,
2) 3.0 should be failing as it shouldn't be rejecting (select * works, but not
select static?)...
I feel that letting it fail is best as its shows an issue with 3.0.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r45023 - in /dev/cassandra/4.0-beta4/redhat: ./ repodata/
Author: mck Date: Fri Dec 18 17:55:01 2020 New Revision: 45023 Log: staging cassandra rpm packages for 4.0-beta4 Added: dev/cassandra/4.0-beta4/redhat/ dev/cassandra/4.0-beta4/redhat/cassandra-4.0~beta4-1.noarch.rpm (with props) dev/cassandra/4.0-beta4/redhat/cassandra-4.0~beta4-1.src.rpm (with props) dev/cassandra/4.0-beta4/redhat/cassandra-tools-4.0~beta4-1.noarch.rpm (with props) dev/cassandra/4.0-beta4/redhat/repodata/ dev/cassandra/4.0-beta4/redhat/repodata/3443f46494e24cb727e91aaf29ea2baf27f57502f68f615eb6cac0c198d93ced-primary.sqlite.bz2 (with props) dev/cassandra/4.0-beta4/redhat/repodata/3443f46494e24cb727e91aaf29ea2baf27f57502f68f615eb6cac0c198d93ced-primary.sqlite.bz2.asc dev/cassandra/4.0-beta4/redhat/repodata/82494ee82f965fbb6553af24d5cb3ac5c0bc4747075b2ee1e9c88b097146ec7c-filelists.sqlite.bz2 (with props) dev/cassandra/4.0-beta4/redhat/repodata/82494ee82f965fbb6553af24d5cb3ac5c0bc4747075b2ee1e9c88b097146ec7c-filelists.sqlite.bz2.asc dev/cassandra/4.0-beta4/redhat/repodata/d05dff51c4efa601f81eee783f2c8c6b321dde86bcd6eabd7ad9d5fb34d1e670-primary.xml.gz (with props) dev/cassandra/4.0-beta4/redhat/repodata/d05dff51c4efa601f81eee783f2c8c6b321dde86bcd6eabd7ad9d5fb34d1e670-primary.xml.gz.asc dev/cassandra/4.0-beta4/redhat/repodata/e7d1fc870d06b688e3000c09b3315d55104750a3c5b8db53d12303f671eee1d6-filelists.xml.gz (with props) dev/cassandra/4.0-beta4/redhat/repodata/e7d1fc870d06b688e3000c09b3315d55104750a3c5b8db53d12303f671eee1d6-filelists.xml.gz.asc dev/cassandra/4.0-beta4/redhat/repodata/e9e5972132a2063bff8c96f34d5a1af2d2bd88088d361db11270d459f9512647-other.sqlite.bz2 (with props) dev/cassandra/4.0-beta4/redhat/repodata/e9e5972132a2063bff8c96f34d5a1af2d2bd88088d361db11270d459f9512647-other.sqlite.bz2.asc dev/cassandra/4.0-beta4/redhat/repodata/fc08625df85ac5334c7ddf3b2892e4611f71f45f75da54c3fdb363423afeab4d-other.xml.gz (with props) dev/cassandra/4.0-beta4/redhat/repodata/fc08625df85ac5334c7ddf3b2892e4611f71f45f75da54c3fdb363423afeab4d-other.xml.gz.asc dev/cassandra/4.0-beta4/redhat/repodata/repomd.xml dev/cassandra/4.0-beta4/redhat/repodata/repomd.xml.asc Added: dev/cassandra/4.0-beta4/redhat/cassandra-4.0~beta4-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta4/redhat/cassandra-4.0~beta4-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta4/redhat/cassandra-4.0~beta4-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta4/redhat/cassandra-4.0~beta4-1.src.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta4/redhat/cassandra-tools-4.0~beta4-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta4/redhat/cassandra-tools-4.0~beta4-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta4/redhat/repodata/3443f46494e24cb727e91aaf29ea2baf27f57502f68f615eb6cac0c198d93ced-primary.sqlite.bz2 == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta4/redhat/repodata/3443f46494e24cb727e91aaf29ea2baf27f57502f68f615eb6cac0c198d93ced-primary.sqlite.bz2 -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta4/redhat/repodata/3443f46494e24cb727e91aaf29ea2baf27f57502f68f615eb6cac0c198d93ced-primary.sqlite.bz2.asc == --- dev/cassandra/4.0-beta4/redhat/repodata/3443f46494e24cb727e91aaf29ea2baf27f57502f68f615eb6cac0c198d93ced-primary.sqlite.bz2.asc (added) +++ dev/cassandra/4.0-beta4/redhat/repodata/3443f46494e24cb727e91aaf29ea2baf27f57502f68f615eb6cac0c198d93ced-primary.sqlite.bz2.asc Fri Dec 18 17:55:01 2020 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAl/c7L0ACgkQ6RM1134+ +h8uexRAAgAtXGwyx1ZtmDzwQmNFgZm4ZA/eNhp5K7vJJ7VMVBQuQSQGbwqPFtCOW +kkzFiHl5teQ27Z0Hn0GKvzd0gEbqhl4zYPXeV76wAK8tB3S5Y74UuGOpUsQ5xov0 +IalWPcNO3G7Ym6KubuoOJH2CohtzRvFKn5CF38TCu0GnSSpyBzF/DbXESYcSQ6LH +z7rSWFjXOiIs1GzP/wFcydu5gxTmDxHRz0cwECfF1qiDBwm29DRnaDx5ROw7iyMj +sC7Hngo8VTzMRwz5cl7m1E66vCCRwrY9sT3BVDIaIYrRRXMmQvSne3Vi1bPsOwhp +lBtCOPKdMLY9IYOJPI0Z9C8XBsvQefCtAG2zszM0KAvhRIFDhd1BJLbs0z48eGIW +1UHoEiE2xD1oqLQnI9JI7KPMyj1Q7+jwmHIuKAnnpmkm9bB4kV+qE4RkyVdQMVsI +YPPxnn2jnvz8otaNtRL
svn commit: r45022 - in /dev/cassandra/4.0-beta4/debian: ./ dists/ dists/40x/ dists/40x/main/ dists/40x/main/binary-amd64/ dists/40x/main/binary-i386/ dists/40x/main/source/ pool/ pool/main/ pool/main
Author: mck Date: Fri Dec 18 17:46:36 2020 New Revision: 45022 Log: staging cassandra debian packages for 4.0-beta4 Added: dev/cassandra/4.0-beta4/debian/ dev/cassandra/4.0-beta4/debian/cassandra-tools_4.0~beta4_all.deb (with props) dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4.dsc dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4.tar.gz (with props) dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4_all.deb (with props) dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4_amd64.buildinfo dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4_amd64.changes dev/cassandra/4.0-beta4/debian/dists/ dev/cassandra/4.0-beta4/debian/dists/40x/ dev/cassandra/4.0-beta4/debian/dists/40x/InRelease dev/cassandra/4.0-beta4/debian/dists/40x/Release dev/cassandra/4.0-beta4/debian/dists/40x/Release.gpg dev/cassandra/4.0-beta4/debian/dists/40x/main/ dev/cassandra/4.0-beta4/debian/dists/40x/main/binary-amd64/ dev/cassandra/4.0-beta4/debian/dists/40x/main/binary-amd64/Packages dev/cassandra/4.0-beta4/debian/dists/40x/main/binary-amd64/Packages.gz (with props) dev/cassandra/4.0-beta4/debian/dists/40x/main/binary-amd64/Release dev/cassandra/4.0-beta4/debian/dists/40x/main/binary-i386/ dev/cassandra/4.0-beta4/debian/dists/40x/main/binary-i386/Packages dev/cassandra/4.0-beta4/debian/dists/40x/main/binary-i386/Packages.gz (with props) dev/cassandra/4.0-beta4/debian/dists/40x/main/binary-i386/Release dev/cassandra/4.0-beta4/debian/dists/40x/main/source/ dev/cassandra/4.0-beta4/debian/dists/40x/main/source/Release dev/cassandra/4.0-beta4/debian/dists/40x/main/source/Sources.gz (with props) dev/cassandra/4.0-beta4/debian/pool/ dev/cassandra/4.0-beta4/debian/pool/main/ dev/cassandra/4.0-beta4/debian/pool/main/c/ dev/cassandra/4.0-beta4/debian/pool/main/c/cassandra/ dev/cassandra/4.0-beta4/debian/pool/main/c/cassandra/cassandra-tools_4.0~beta4_all.deb (with props) dev/cassandra/4.0-beta4/debian/pool/main/c/cassandra/cassandra_4.0~beta4.dsc dev/cassandra/4.0-beta4/debian/pool/main/c/cassandra/cassandra_4.0~beta4.tar.gz (with props) dev/cassandra/4.0-beta4/debian/pool/main/c/cassandra/cassandra_4.0~beta4_all.deb (with props) Added: dev/cassandra/4.0-beta4/debian/cassandra-tools_4.0~beta4_all.deb == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta4/debian/cassandra-tools_4.0~beta4_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4.dsc == --- dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4.dsc (added) +++ dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4.dsc Fri Dec 18 17:46:36 2020 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 4.0~beta4 +Maintainer: Eric Evans +Uploaders: Sylvain Lebresne +Homepage: http://cassandra.apache.org +Standards-Version: 3.8.3 +Vcs-Browser: https://gitbox.apache.org/repos/asf?p=cassandra.git +Vcs-Git: https://gitbox.apache.org/repos/asf/cassandra.git +Build-Depends: debhelper (>= 5), openjdk-8-jdk | java8-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python-dev (>= 2.7), quilt, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + 85daa153fcbe1f141ed6d406f0d313542791 272831759 cassandra_4.0~beta4.tar.gz +Checksums-Sha256: + 734bb64224a38fa3b0f87f76a74dc5819f16e8c310061b07e99821fbb5a1e2d4 272831759 cassandra_4.0~beta4.tar.gz +Files: + ee7c74c558b74dedccdb26f3f26c2715 272831759 cassandra_4.0~beta4.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAl/c6hwACgkQ6RM1134+ +h8sQKRAAsaxVikTYdd3AH6xdO9wCSV596g1ri6YvmxRaJziNoTy1GWpdb7xo5LDd +zwu4kFjV/8zm81bJfbr0W25n5C+o2PQUGLfH25RX35VlwXTu36fcu4oSveyEFIpV +ay/3xxw6xBoFusQWxlRDHo6UNh9o/KXct6wpBDPL5QYftq9+19qqzxoZ9mBKb05Q +eiIO/7Q4zrPhSeTbuKR0NR7+e56Owkea8lghbsIsv20AZ0cC3rhC+lub+n0FfQJ1 +MmqSOUw0yO1Xil4fBXzYyw4aSBpoAnDVlPiHdHen6U4MwY+v6s5/lT8razPccW2S +3WzV3pTC4duTW3b/NMNNq2dc56N0tcAJCvsIncYvINhQCJc0l/oK2nj2MnHTB6lJ +KaRPpfrzpxek1BUotezBPdwgkfu0dquDjgD+uFBdBZYdGCXo3pc2v/BaBcXyyhis +hMitQT+JGL4QgWmTp/5aO5L9zdKbhcw77H+OKxwM2QsUZ31ItBWYULWXUv2vz2/V +gRF/unI1CGcqWgu7yrgxLGoRBgQA5IOEqGTnKo3DU+LeuVsB4FYGNCc+jx8M3GbV +9sKrLqTPvOC1vY4tuRstt2bBVfSwR9Rnhf8Rf6NUWcM33nvD/RFQW1vyrN25wCGs +JFJOzwTh19Sja81BIkChkZKXotolG8CScYBX/S8XVZgDGA8CsYA= +=Zb0K +-END PGP SIGNATURE- Added: dev/cassandra/4.0-beta4/debian/cassandra_4.0~beta4.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0-
svn commit: r45021 - /dev/cassandra/4.0-beta4/
Author: mck Date: Fri Dec 18 17:39:08 2020 New Revision: 45021 Log: staging cassandra 4.0-beta4 Added: dev/cassandra/4.0-beta4/ dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz (with props) dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.asc dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.sha256 dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.sha512 dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz (with props) dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz.asc dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz.sha256 dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz.sha512 Added: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.asc == --- dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.asc (added) +++ dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.asc Fri Dec 18 17:39:08 2020 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAl/c6PsACgkQ6RM1134+ +h8v1hA//UtCDePmcdBb4AlffRw9HC2zYGLTaat2xPzGvBphih2vZcIBZ3eXzQT6y +lnc15o+4teMBsOQ8ZUlWpa2Y0GX7VvfWcgJfDl0TwvnP2JVbHP4oWmVdlH/5r7BG +cCCIYZ7ldSmBsA4/YA0+Eawq85sDZABpaoC+Z0e2bKRxcBLO7GIoZuigQjrSZue+ +ssZdXtJgKTxHXRMLUWWZNyk3ZLOV32yReezqjFyzdwQ8mUU3bN+e+72YX0MuuNO0 +RufejTi+S/Wz9YYh7hO7moGLyzhToZWo3Uye+rGBgvEyZGKIxnfgbA8BcYMz8lw9 +ci5sTSfLnPDb6kIhO+32CffvNnYmf3eGPyU+iet0+CVKv4PxSf4L9zyvqnO4e2XU +UOVwHsYCgM5kdp8j5heukfkuu7IVFGTY/8hCPi+5Qu7H3Pq5sD6vC+vDWuIaolix +5gl5x7IMtj21NmRq0TPEtcWyvUwNLgqslX160U1G+8H8VRGSr1rpCS1Z3Juk5aTp +zZuskTAPu+w3M32/xsZXZCf1eu9gcQjUZ9dQI++K4oBWEdZn8u7/TPSckQX97BHx +erpxAP1pKMAgf/Muv4k5hz605wtTUmivfekh/76bpD6nh174tSAsVb5n0CGHr/QT +KWb5GOVYHgQu3MGum0FdGcTOTJppqka10yibjGVSK6yWEAgmfXM= +=D4s4 +-END PGP SIGNATURE- Added: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.sha256 == --- dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.sha256 (added) +++ dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.sha256 Fri Dec 18 17:39:08 2020 @@ -0,0 +1 @@ +c9e2cd623cfd4974f3a8c113de25a6617f49682d96d257f26f199b7ec9b1ea03 Added: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.sha512 == --- dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.sha512 (added) +++ dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-bin.tar.gz.sha512 Fri Dec 18 17:39:08 2020 @@ -0,0 +1 @@ +af253d45681eeadc23bb7ff76091756781d021c4adea17f1d5b5cbda7fa4a0d6615ca270433827ae739516a1b23e1c2bea06ce7c0264241df21772f911fbb7d4 Added: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz.asc == --- dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz.asc (added) +++ dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz.asc Fri Dec 18 17:39:08 2020 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAl/c6P0ACgkQ6RM1134+ +h8v9vw/+M9XL3gzxBWvMyGbD5h6Ajo1P7TqLT/0KM5q1jkwv21vFuayj4HNEBTZJ +XOqSpEIkPxeJiuaocMlA035z4FCiQ2KUcfj3yMXzuLJ2JAK6DE3nfxrsH7w89bQ1 +1fZi1lGymJLRoNmznZEvdgegpW7asPQDexxw8nscTCp+eTXJor+kwPbOgP1HqwU/ +bW1v5Dq6eUqULRo4qXkOL8+ET6c83LtPYt5Tz/QmA1qAqH+5LZOhZONqUqwNjgs5 +VXogyf3Q50XddJ2Hh+AB58loo1XHMgJhs3WbqPaALzihll7CG+sfipLNPL1Az5k6 +Eh8S2pAjoImlWMQI9f5Un3Jdar6EbPTqwjpwNzVQ1QeINfcEvOHPKWmW4GfbNMxi +YhGaWm/c1dQR5eYO+J0mLsusxa7XZzXHtvGafM3YRVFv2iRmSawtkEYw+og1SazZ +3jAiGpPH+XIBfbCdlETzsCfW52Izz1u0a+p8mF0BTTJsXnpUfBaZ5dXcvuETLsOd +XdG3xoSBBYrp4rVN7Vit7Go+JVUgbbuAfHQg31TgJFMUzcOvweY89WkPK1g53H/u +pP+UU+g6eYMIZNU/qYNBIHNC7a0HprAYVGwpmUbsce2v600fe/7baVBdIc7TiGDY +VATsCgD9HD2sWTg0eT9uOC3OGrUtdO65O6RZocXach//+3HQ3bE= +=9Ubi +-END PGP SIGNATURE- Added: dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz.sha256 == --- dev/cassandra/4.0-beta4/apache-cassandra-4.0-beta4-src.tar.gz.sha25
[cassandra] tag 4.0-beta4-tentative created (now b0c50c1)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.0-beta4-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. at b0c50c1 (commit) This tag includes the following new commits: new b0c50c1 Prepare debian changelog for 4.0-beta4 The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Prepare debian changelog for 4.0-beta4
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to tag 4.0-beta4-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b0c50c10dbc443a05662b111a971a65cafa258d5 Author: Mick Semb Wever AuthorDate: Fri Dec 18 18:33:39 2020 +0100 Prepare debian changelog for 4.0-beta4 --- debian/changelog | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index a366395..71f5786 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,8 @@ -cassandra (4.0~beta4) UNRELEASED; urgency=medium +cassandra (4.0~beta4) unstable; urgency=medium * New release - -- Mick Semb Wever Thu, 29 Oct 2020 12:59:30 +0100 + -- Mick Semb Wever Fri, 18 Dec 2020 18:32:45 +0100 cassandra (4.0~beta3) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 6ea11f91b3ff0233f37fd725f1f1347e34a4caa8 Merge: d9859d2 921609e Author: Mick Semb Wever AuthorDate: Fri Dec 18 18:14:38 2020 +0100 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (d9859d2 -> 6ea11f9)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d9859d2 DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata new 921609e ninja-fix: CHANGES.txt entry for CASSANDRA-15158 corrected to 3.11.10 new 6ea11f9 Merge branch 'cassandra-3.11' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: ninja-fix: CHANGES.txt entry for CASSANDRA-15158 corrected to 3.11.10
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.11 by this push: new 921609e ninja-fix: CHANGES.txt entry for CASSANDRA-15158 corrected to 3.11.10 921609e is described below commit 921609eff7ab26f26ddc2bfa906d21f161e3ee69 Author: Mick Semb Wever AuthorDate: Fri Dec 18 18:12:34 2020 +0100 ninja-fix: CHANGES.txt entry for CASSANDRA-15158 corrected to 3.11.10 ref: https://the-asf.slack.com/archives/CK23JSY2K/p1608217828111400 --- CHANGES.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index a9a0cee..d4ec59a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -12,6 +12,7 @@ Merged from 3.0: * Remove the SEPExecutor blocking behavior (CASSANDRA-16186) * Fix invalid cell value skipping when reading from disk (CASSANDRA-16223) * Prevent invoking enable/disable gossip when not in NORMAL (CASSANDRA-16146) + * Wait for schema agreement when bootstrapping (CASSANDRA-15158) Merged from 2.2: * Fix the histogram merge of the table metrics (CASSANDRA-16259) @@ -23,7 +24,6 @@ Merged from 2.2: * Avoid failing compactions with very large partitions (CASSANDRA-15164) * Make sure LCS handles duplicate sstable added/removed notifications correctly (CASSANDRA-14103) Merged from 3.0: - * Wait for schema agreement when bootstrapping (CASSANDRA-15158) * Fix OOM when terminating repair session (CASSANDRA-15902) * Avoid marking shutting down nodes as up after receiving gossip shutdown message (CASSANDRA-16094) * Check SSTables for latest version before dropping compact storage (CASSANDRA-16063) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16361) DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata
[
https://issues.apache.org/jira/browse/CASSANDRA-16361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16361:
---
Fix Version/s: 4.0
> DROP COMPACT STORAGE should invalidate prepared statements still using
> CompactTableMetadata
> ---
>
> Key: CASSANDRA-16361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16361
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0, 4.0-beta4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When we drop compact storage from a table, existing prepared statements
> continue to refer to an instance of {{CompactTableMetadata}}, rather than
> being invalidated so they can be assigned a new {{TableMetadata}} instance.
> There are perhaps some brute force ways to fix this, like bouncing the node,
> but that obviously sub-optimal.
> One idea is to have {{TableMetadata#changeAffectsPreparedStatements()}}
> return true when we go from having to not having the DENSE flag. It should be
> pretty easy to validate a fix with a small addition to {{CompactTableTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16361) DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata
[
https://issues.apache.org/jira/browse/CASSANDRA-16361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16361:
---
Fix Version/s: (was: 4.0-beta)
4.0-beta4
Since Version: 4.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/d9859d231f24781b7ebf4dd93bb4584fb4bc7538
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Cleaned up some trailing whitespace, and added the CHANGES.txt entry.
Committed as
[d9859d231f24781b7ebf4dd93bb4584fb4bc7538|https://github.com/apache/cassandra/commit/d9859d231f24781b7ebf4dd93bb4584fb4bc7538].
> DROP COMPACT STORAGE should invalidate prepared statements still using
> CompactTableMetadata
> ---
>
> Key: CASSANDRA-16361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16361
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When we drop compact storage from a table, existing prepared statements
> continue to refer to an instance of {{CompactTableMetadata}}, rather than
> being invalidated so they can be assigned a new {{TableMetadata}} instance.
> There are perhaps some brute force ways to fix this, like bouncing the node,
> but that obviously sub-optimal.
> One idea is to have {{TableMetadata#changeAffectsPreparedStatements()}}
> return true when we go from having to not having the DENSE flag. It should be
> pretty easy to validate a fix with a small addition to {{CompactTableTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new d9859d2 DROP COMPACT STORAGE should invalidate prepared statements
still using CompactTableMetadata
d9859d2 is described below
commit d9859d231f24781b7ebf4dd93bb4584fb4bc7538
Author: Caleb Rackliffe
AuthorDate: Thu Dec 17 16:27:36 2020 -0600
DROP COMPACT STORAGE should invalidate prepared statements still using
CompactTableMetadata
patch by Caleb Rackliffe; reviewed by Alex Petrov, Mick Semb Wever for
CASSANDRA-16361
---
CHANGES.txt| 1 +
.../org/apache/cassandra/cql3/QueryProcessor.java | 6 +++
.../org/apache/cassandra/schema/TableMetadata.java | 3 +-
.../validation/operations/CompactTableTest.java| 54 ++
4 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 59205c5..4903e43 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta4
+ * DROP COMPACT STORAGE should invalidate prepared statements still using
CompactTableMetadata (CASSANDRA-16361)
* Update default num_tokens to 16 and
allocate_tokens_for_local_replication_factor to 3 (CASSANDRA-13701)
* Remove use of String.intern() (CASSANDRA-15810)
* Fix the missing bb position in ByteBufferAccessor.getUnsignedShort
(CASSANDRA-16249)
diff --git a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
index 0b94ec0..c92718d 100644
--- a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
+++ b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
@@ -163,6 +163,12 @@ public class QueryProcessor implements QueryHandler
}
@VisibleForTesting
+public static ConcurrentMap getInternalStatements()
+{
+return internalStatements;
+}
+
+@VisibleForTesting
public static QueryState internalQueryState()
{
return new QueryState(InternalStateInstance.INSTANCE.clientState);
diff --git a/src/java/org/apache/cassandra/schema/TableMetadata.java
b/src/java/org/apache/cassandra/schema/TableMetadata.java
index f0a5bb7..e642833 100644
--- a/src/java/org/apache/cassandra/schema/TableMetadata.java
+++ b/src/java/org/apache/cassandra/schema/TableMetadata.java
@@ -558,7 +558,8 @@ public class TableMetadata implements SchemaElement
|| !regularAndStaticColumns.equals(updated.regularAndStaticColumns)
|| !indexes.equals(updated.indexes)
|| params.defaultTimeToLive != updated.params.defaultTimeToLive
-|| params.gcGraceSeconds != updated.params.gcGraceSeconds;
+|| params.gcGraceSeconds != updated.params.gcGraceSeconds
+|| ( !Flag.isCQLTable(flags) && Flag.isCQLTable(updated.flags) );
}
/**
diff --git
a/test/unit/org/apache/cassandra/cql3/validation/operations/CompactTableTest.java
b/test/unit/org/apache/cassandra/cql3/validation/operations/CompactTableTest.java
index 0791842..46a7b1d 100644
---
a/test/unit/org/apache/cassandra/cql3/validation/operations/CompactTableTest.java
+++
b/test/unit/org/apache/cassandra/cql3/validation/operations/CompactTableTest.java
@@ -18,9 +18,19 @@
package org.apache.cassandra.cql3.validation.operations;
+import java.util.concurrent.ConcurrentMap;
+import java.util.concurrent.atomic.AtomicBoolean;
+
import org.junit.Test;
import org.apache.cassandra.cql3.CQLTester;
+import org.apache.cassandra.cql3.QueryHandler;
+import org.apache.cassandra.cql3.QueryProcessor;
+import org.apache.cassandra.schema.Schema;
+import org.apache.cassandra.schema.SchemaChangeListener;
+
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
public class CompactTableTest extends CQLTester
{
@@ -47,6 +57,50 @@ public class CompactTableTest extends CQLTester
}
@Test
+public void dropCompactStorageShouldInvalidatePreparedStatements() throws
Throwable
+{
+createTable("CREATE TABLE %s (pk int, ck int, v int, PRIMARY KEY (pk,
ck)) WITH COMPACT STORAGE;");
+execute("INSERT INTO %s (pk, ck, v) VALUES (1, 1, 1)");
+String templateSelect = "SELECT * FROM %s WHERE pk = 1";
+assertRows(execute(templateSelect), row(1, 1, 1));
+
+// Verify that the prepared statement has been added to the cache
after our first query.
+String formattedQuery = formatQuery(templateSelect);
+ConcurrentMap original =
QueryProcessor.getInternalStatements();
+assertTrue(original.containsKey(formattedQuery));
+
+// Verify that schema change listeners are told statements are
affected with DROP COMPACT STORAGE.
+SchemaChangeListener listener = new SchemaChangeListener()
+{
+public void onAlterTable(String keyspace, String table, boolean
affectsStatements
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251866#comment-17251866
]
Adam Holmberg commented on CASSANDRA-16332:
---
Spoke with Andres, who cleared up my confusion. He said this would not be
expected to work in 3.0, so the results are not surprising. Here was the ci run:
https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16332
My only question would be to ask if we think adding a version conditional
around this assertion would be worth it.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16226) COMPACT STORAGE SSTables created before 3.0 are not correctly skipped by timestamp due to missing primary key liveness info
[
https://issues.apache.org/jira/browse/CASSANDRA-16226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251860#comment-17251860
]
Michael Semb Wever commented on CASSANDRA-16226:
> I've made the minor adjustment to the docs in the 3.11 branch here. Let me
> know what you think.
LGTM!
> COMPACT STORAGE SSTables created before 3.0 are not correctly skipped by
> timestamp due to missing primary key liveness info
> ---
>
> Key: CASSANDRA-16226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16226
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: perfomance, upgrade
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> This was discovered while tracking down a spike in the number of SSTables
> per read for a COMPACT STORAGE table after a 2.1 -> 3.0 upgrade. Before 3.0,
> there is no direct analog of 3.0's primary key liveness info. When we upgrade
> 2.1 COMPACT STORAGE SSTables to the mf format, we simply don't write row
> timestamps, even if the original mutations were INSERTs. On read, when we
> look at SSTables in order from newest to oldest max timestamp, we expect to
> have this primary key liveness information to determine whether we can skip
> older SSTables after finding completely populated rows.
> ex. I have three SSTables in a COMPACT STORAGE table with max timestamps
> 1000, 2000, and 3000. There are many rows in a particular partition, making
> filtering on the min and max clustering effectively a no-op. All data is
> inserted, and there are no partial updates. A fully specified row with
> timestamp 2500 exists in the SSTable with a max timestamp of 3000. With a
> proper row timestamp in hand, we can easily ignore the SSTables w/ max
> timestamps of 1000 and 2000. Without it, we read 3 SSTables instead of 1,
> which likely means a significant performance regression.
> The following test illustrates this difference in behavior between 2.1 and
> 3.0:
> https://github.com/maedhroz/cassandra/commit/84ce9242bedd735ca79d4f06007d127de6a82800
> A solution here might be as simple as having
> {{SinglePartitionReadCommand#canRemoveRow()}} only inspect primary key
> liveness information for non-compact/CQL tables. Tombstones seem to be
> handled at a level above that anyway. (One potential problem with that is
> whether or not the distinction will continue to exist in 4.0, and dropping
> compact storage from a table doesn't magically make pk liveness information
> appear.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16226) COMPACT STORAGE SSTables created before 3.0 are not correctly skipped by timestamp due to missing primary key liveness info
[
https://issues.apache.org/jira/browse/CASSANDRA-16226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251846#comment-17251846
]
Caleb Rackliffe commented on CASSANDRA-16226:
-
[~mck] [~ifesdjeen] I've made the minor adjustment to the docs in the 3.11
branch
[here|https://github.com/apache/cassandra/pull/853/commits/1de49337f1ed93bbf023d0b25add179922fd9341].
Let me know what you think.
> COMPACT STORAGE SSTables created before 3.0 are not correctly skipped by
> timestamp due to missing primary key liveness info
> ---
>
> Key: CASSANDRA-16226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16226
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: perfomance, upgrade
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> This was discovered while tracking down a spike in the number of SSTables
> per read for a COMPACT STORAGE table after a 2.1 -> 3.0 upgrade. Before 3.0,
> there is no direct analog of 3.0's primary key liveness info. When we upgrade
> 2.1 COMPACT STORAGE SSTables to the mf format, we simply don't write row
> timestamps, even if the original mutations were INSERTs. On read, when we
> look at SSTables in order from newest to oldest max timestamp, we expect to
> have this primary key liveness information to determine whether we can skip
> older SSTables after finding completely populated rows.
> ex. I have three SSTables in a COMPACT STORAGE table with max timestamps
> 1000, 2000, and 3000. There are many rows in a particular partition, making
> filtering on the min and max clustering effectively a no-op. All data is
> inserted, and there are no partial updates. A fully specified row with
> timestamp 2500 exists in the SSTable with a max timestamp of 3000. With a
> proper row timestamp in hand, we can easily ignore the SSTables w/ max
> timestamps of 1000 and 2000. Without it, we read 3 SSTables instead of 1,
> which likely means a significant performance regression.
> The following test illustrates this difference in behavior between 2.1 and
> 3.0:
> https://github.com/maedhroz/cassandra/commit/84ce9242bedd735ca79d4f06007d127de6a82800
> A solution here might be as simple as having
> {{SinglePartitionReadCommand#canRemoveRow()}} only inspect primary key
> liveness information for non-compact/CQL tables. Tombstones seem to be
> handled at a level above that anyway. (One potential problem with that is
> whether or not the distinction will continue to exist in 4.0, and dropping
> compact storage from a table doesn't magically make pk liveness information
> appear.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-16362:
-
Bug Category: Parent values: Code(13163)
Complexity: Normal
Component/s: Tool/bulk load
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Erik Merkle
>Assignee: Jon Meredith
>Priority: Normal
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251828#comment-17251828
]
Jon Meredith commented on CASSANDRA-16362:
--
Sorry for breaking sstableloader with the change. I'll investigate today.
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
>Reporter: Erik Merkle
>Priority: Normal
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16362) SSLFactory should initialize SSLContext before setting protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith reassigned CASSANDRA-16362:
Assignee: Jon Meredith
> SSLFactory should initialize SSLContext before setting protocols
>
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
>Reporter: Erik Merkle
>Assignee: Jon Meredith
>Priority: Normal
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16361) DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata
[
https://issues.apache.org/jira/browse/CASSANDRA-16361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16361:
Status: Ready to Commit (was: Review In Progress)
[~mck] [~ifesdjeen] Thanks for the review! I've changed the one item you two
mentioned on the PR, and I think we're ready to commit. Would either of you
mind doing the honors?
> DROP COMPACT STORAGE should invalidate prepared statements still using
> CompactTableMetadata
> ---
>
> Key: CASSANDRA-16361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16361
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When we drop compact storage from a table, existing prepared statements
> continue to refer to an instance of {{CompactTableMetadata}}, rather than
> being invalidated so they can be assigned a new {{TableMetadata}} instance.
> There are perhaps some brute force ways to fix this, like bouncing the node,
> but that obviously sub-optimal.
> One idea is to have {{TableMetadata#changeAffectsPreparedStatements()}}
> return true when we go from having to not having the DENSE flag. It should be
> pretty easy to validate a fix with a small addition to {{CompactTableTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16361) DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata
[
https://issues.apache.org/jira/browse/CASSANDRA-16361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16361:
Reviewers: Alex Petrov, Michael Semb Wever (was: Alex Petrov, Caleb
Rackliffe, Michael Semb Wever)
> DROP COMPACT STORAGE should invalidate prepared statements still using
> CompactTableMetadata
> ---
>
> Key: CASSANDRA-16361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16361
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When we drop compact storage from a table, existing prepared statements
> continue to refer to an instance of {{CompactTableMetadata}}, rather than
> being invalidated so they can be assigned a new {{TableMetadata}} instance.
> There are perhaps some brute force ways to fix this, like bouncing the node,
> but that obviously sub-optimal.
> One idea is to have {{TableMetadata#changeAffectsPreparedStatements()}}
> return true when we go from having to not having the DENSE flag. It should be
> pretty easy to validate a fix with a small addition to {{CompactTableTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16361) DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata
[
https://issues.apache.org/jira/browse/CASSANDRA-16361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16361:
Reviewers: Alex Petrov, Michael Semb Wever, Caleb Rackliffe (was: Alex
Petrov, Caleb Rackliffe, Michael Semb Wever)
Alex Petrov, Michael Semb Wever, Caleb Rackliffe (was: Alex
Petrov)
Status: Review In Progress (was: Patch Available)
> DROP COMPACT STORAGE should invalidate prepared statements still using
> CompactTableMetadata
> ---
>
> Key: CASSANDRA-16361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16361
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When we drop compact storage from a table, existing prepared statements
> continue to refer to an instance of {{CompactTableMetadata}}, rather than
> being invalidated so they can be assigned a new {{TableMetadata}} instance.
> There are perhaps some brute force ways to fix this, like bouncing the node,
> but that obviously sub-optimal.
> One idea is to have {{TableMetadata#changeAffectsPreparedStatements()}}
> return true when we go from having to not having the DENSE flag. It should be
> pretty easy to validate a fix with a small addition to {{CompactTableTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16332) Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251787#comment-17251787
]
Adam Holmberg commented on CASSANDRA-16332:
---
I ran it and was surprised to see it failing on 3.0, which I thought had
CASSANDRA-14242. Will need to look into that, unless someone tells me that is
expected.
> Fix upgrade python dtest test_static_columns_with_2i -
> upgrade_tests.cql_tests.TestCQLNodes
> ---
>
> Key: CASSANDRA-16332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16332
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964
> {code}
> # We don't support that
> > assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")
> upgrade_tests/cql_tests.py:4137:
> {code}
> {code}
> > assert False, "Expecting query to raise an exception, but nothing
> > was raised."
> E AssertionError: Expecting query to raise an exception, but
> nothing was raised.
> tools/assertions.py:63: AssertionError
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16363) Does open source cassandra supports PITR(point in time recovery) ?
[ https://issues.apache.org/jira/browse/CASSANDRA-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16363: Resolution: Not A Bug Status: Resolved (was: Triage Needed) > Does open source cassandra supports PITR(point in time recovery) ? > -- > > Key: CASSANDRA-16363 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16363 > Project: Cassandra > Issue Type: Bug >Reporter: shanmukha >Priority: Normal > Attachments: Capture.PNG > > > Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? > or it will only work on enterprise edition? > If so how to achieve i am not getting any proper documentation. > i have read about commitlog_archiving.properties and enabled the commit logs > archiving > but not able to restore to some point in time. > Does PITR works only in case of node failure. > if i mistakenly deleted the data or keyspace can i use PITR in that to > revert to previous before the issue, > have some queries like apart from node failure data if i want to restore to > any point is that possible? > wt is restore command used for? > wt is restore directories used for? > by placing archive commit logs in commit log directory and restart the node > that will get automatic replayed? > if i copy archive logs and mention point in time in file does get data > before that time? > Do we have any example configuration how to use this settings? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16363) Does open source cassandra supports PITR(point in time recovery) ?
[ https://issues.apache.org/jira/browse/CASSANDRA-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251760#comment-17251760 ] Alex Petrov commented on CASSANDRA-16363: - Please use Cassandra user mailing list (see https://cassandra.apache.org/community/) for this (and further similar) enquiries. Thank you! > Does open source cassandra supports PITR(point in time recovery) ? > -- > > Key: CASSANDRA-16363 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16363 > Project: Cassandra > Issue Type: Bug >Reporter: shanmukha >Priority: Normal > Attachments: Capture.PNG > > > Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? > or it will only work on enterprise edition? > If so how to achieve i am not getting any proper documentation. > i have read about commitlog_archiving.properties and enabled the commit logs > archiving > but not able to restore to some point in time. > Does PITR works only in case of node failure. > if i mistakenly deleted the data or keyspace can i use PITR in that to > revert to previous before the issue, > have some queries like apart from node failure data if i want to restore to > any point is that possible? > wt is restore command used for? > wt is restore directories used for? > by placing archive commit logs in commit log directory and restart the node > that will get automatic replayed? > if i copy archive logs and mention point in time in file does get data > before that time? > Do we have any example configuration how to use this settings? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16316) Tracing continues after session completed
[ https://issues.apache.org/jira/browse/CASSANDRA-16316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251749#comment-17251749 ] Jan Karlsson commented on CASSANDRA-16316: -- Sure thing. Here is a [dtest|https://github.com/apache/cassandra-dtest/compare/trunk...itskarlsson:16316] that tests for this issue. I tested it both with and without patch on 3.11.9 to verify. > Tracing continues after session completed > - > > Key: CASSANDRA-16316 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16316 > Project: Cassandra > Issue Type: Bug > Components: Observability/Tracing >Reporter: Jan Karlsson >Assignee: Jan Karlsson >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x > > > We saw the system_trace.events table increasing in size continuously without > any trace requests being issued. > I traced the issue back to a specific version and patch. I believe we have > removed the call to reset the trace flag in CASSANDRA-15041 which causes > tracing to continue in the thread even after it is finished with the request. > Reproduced like follows: > 1. ccm test -n 1 -v 3.11.9 > 2. Enable authentication/authorization > 3. Set permissions_update_interval_in_ms: 1000 (It works if this value is > default value. I am guessing this is because the update is done in the > calling thread) > 4. select * from some table a bunch of times until PermissionRoleCache is > refreshed > 5. Watch system_traces.events grow > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16363) Does open source cassandra supports PITR(point in time recovery) ?
[ https://issues.apache.org/jira/browse/CASSANDRA-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shanmukha updated CASSANDRA-16363: -- Description: Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? or it will only work on enterprise edition? If so how to achieve i am not getting any proper documentation. i have read about commitlog_archiving.properties and enabled the commit logs archiving but not able to restore to some point in time. Does PITR works only in case of node failure. if i mistakenly deleted the data or keyspace can i use PITR in that to revert to previous before the issue, have some queries like apart from node failure data if i want to restore to any point is that possible? wt is restore command used for? wt is restore directories used for? by placing archive commit logs in commit log directory and restart the node that will get automatic replayed? if i copy archive logs and mention point in time in file does get data before that time? Do we have any example configuration how to use this settings? was: Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? or it will only work on enterprise edition? If so how to achieve i am not getting any proper documentation to read. i have read about commitlog_archiving.properties and enabled the commit logs archiving but not able to restore to some point in time. Does PITR works only in case of node failure. if i mistakenly deleted the data or keyspace can i use PITR in that to revert to previous before the issue, have some queries like apart from node failure data if i want to restore to any point is that possible? wt is restore command used for? wt is restore directories used for? by placing archive commit logs in commit log directory and restart the node that will get automatic replayed? if i copy archive logs and mention point in time in file does get data before that time? Do we have any example configuration how to use this settings? > Does open source cassandra supports PITR(point in time recovery) ? > -- > > Key: CASSANDRA-16363 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16363 > Project: Cassandra > Issue Type: Bug >Reporter: shanmukha >Priority: Normal > Attachments: Capture.PNG > > > Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? > or it will only work on enterprise edition? > If so how to achieve i am not getting any proper documentation. > i have read about commitlog_archiving.properties and enabled the commit logs > archiving > but not able to restore to some point in time. > Does PITR works only in case of node failure. > if i mistakenly deleted the data or keyspace can i use PITR in that to > revert to previous before the issue, > have some queries like apart from node failure data if i want to restore to > any point is that possible? > wt is restore command used for? > wt is restore directories used for? > by placing archive commit logs in commit log directory and restart the node > that will get automatic replayed? > if i copy archive logs and mention point in time in file does get data > before that time? > Do we have any example configuration how to use this settings? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16363) Does open source cassandra supports PITR(point in time recovery) ?
[ https://issues.apache.org/jira/browse/CASSANDRA-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shanmukha updated CASSANDRA-16363: -- Description: Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? or it will only work on enterprise edition? If so how to achieve i am not getting any proper documentation to read. i have read about commitlog_archiving.properties and enabled the commit logs archiving but not able to restore to some point in time. Does PITR works only in case of node failure. if i mistakenly deleted the data or keyspace can i use PITR in that to revert to previous before the issue, have some queries like apart from node failure data if i want to restore to any point is that possible? wt is restore command used for? wt is restore directories used for? by placing archive commit logs in commit log directory and restart the node that will get automatic replayed? if i copy archive logs and mention point in time in file does get data before that time? Do we have any example configuration how to use this settings? was: Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? If so how to achieve i am not getting any proper documentation to read. i have read about commitlog_archiving.properties and enabled the commit logs archiving but not able to restore to some point in time. Does PITR works only in case of node failure. if i mistakenly deleted the data or keyspace can i use PITR in that to revert to previous before the issue, have some queries like apart from node failure data if i want to restore to any point is that possible? wt is restore command used for? wt is restore directories used for? by placing archive commit logs in commit log directory and restart the node that will get automatic replayed? if i copy archive logs and mention point in time in file does get data before that time? Do we have any example configuration how to use this settings? > Does open source cassandra supports PITR(point in time recovery) ? > -- > > Key: CASSANDRA-16363 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16363 > Project: Cassandra > Issue Type: Bug >Reporter: shanmukha >Priority: Normal > Attachments: Capture.PNG > > > Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? > or it will only work on enterprise edition? > If so how to achieve i am not getting any proper documentation to read. > i have read about commitlog_archiving.properties and enabled the commit logs > archiving > but not able to restore to some point in time. > Does PITR works only in case of node failure. > if i mistakenly deleted the data or keyspace can i use PITR in that to > revert to previous before the issue, > have some queries like apart from node failure data if i want to restore to > any point is that possible? > wt is restore command used for? > wt is restore directories used for? > by placing archive commit logs in commit log directory and restart the node > that will get automatic replayed? > if i copy archive logs and mention point in time in file does get data > before that time? > Do we have any example configuration how to use this settings? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16363) Does open source cassandra supports PITR(point in time recovery) ?
[ https://issues.apache.org/jira/browse/CASSANDRA-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shanmukha updated CASSANDRA-16363: -- Attachment: Capture.PNG > Does open source cassandra supports PITR(point in time recovery) ? > -- > > Key: CASSANDRA-16363 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16363 > Project: Cassandra > Issue Type: Bug >Reporter: shanmukha >Priority: Normal > Attachments: Capture.PNG > > > Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? > If so how to achieve i am not getting any proper documentation to read. > i have read about commitlog_archiving.properties and enabled the commit logs > archiving > but not able to restore to some point in time. > Does PITR works only in case of node failure. > if i mistakenly deleted the data or keyspace can i use PITR in that to revert > to previous before the issue, > have some queries like apart from node failure data if i want to restore to > any point is that possible? > wt is restore command used for? > wt is restore directories used for? > by placing archive commit logs in commit log directory and restart the node > that will get automatic replayed? > if i copy archive logs and mention point in time in file does get data > before that time? > Do we have any example configuration how to use this settings? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16363) Does open source cassandra supports PITR(point in time recovery) ?
[ https://issues.apache.org/jira/browse/CASSANDRA-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shanmukha updated CASSANDRA-16363: -- Description: Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? If so how to achieve i am not getting any proper documentation to read. i have read about commitlog_archiving.properties and enabled the commit logs archiving but not able to restore to some point in time. Does PITR works only in case of node failure. if i mistakenly deleted the data or keyspace can i use PITR in that to revert to previous before the issue, have some queries like apart from node failure data if i want to restore to any point is that possible? wt is restore command used for? wt is restore directories used for? by placing archive commit logs in commit log directory and restart the node that will get automatic replayed? if i copy archive logs and mention point in time in file does get data before that time? Do we have any example configuration how to use this settings? was: Does open source cassandra supports PITR(point in time recovery) ? If so how to achieve i am not getting any proper documentation to read. i have read about commitlog_archiving.properties and enabled the commit logs archiving but not restore to some point in time and have some queries like after from node failure data if i want to restore to any point is that possible? wt is restore command used for? wt is restore directories used for? by placing archive commit logs in commit log directory and restart node that will get automatic replayed? if i copy archive logs and mention point in time in file does get data before that time? Do we have any example configuration how to use this settings? > Does open source cassandra supports PITR(point in time recovery) ? > -- > > Key: CASSANDRA-16363 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16363 > Project: Cassandra > Issue Type: Bug >Reporter: shanmukha >Priority: Normal > > Does open source cassandra (3.11.3 ) supports PITR(point in time recovery) ? > If so how to achieve i am not getting any proper documentation to read. > i have read about commitlog_archiving.properties and enabled the commit logs > archiving > but not able to restore to some point in time. > Does PITR works only in case of node failure. > if i mistakenly deleted the data or keyspace can i use PITR in that to revert > to previous before the issue, > have some queries like apart from node failure data if i want to restore to > any point is that possible? > wt is restore command used for? > wt is restore directories used for? > by placing archive commit logs in commit log directory and restart the node > that will get automatic replayed? > if i copy archive logs and mention point in time in file does get data > before that time? > Do we have any example configuration how to use this settings? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16363) Does open source cassandra supports PITR(point in time recovery) ?
shanmukha created CASSANDRA-16363: - Summary: Does open source cassandra supports PITR(point in time recovery) ? Key: CASSANDRA-16363 URL: https://issues.apache.org/jira/browse/CASSANDRA-16363 Project: Cassandra Issue Type: Bug Reporter: shanmukha Does open source cassandra supports PITR(point in time recovery) ? If so how to achieve i am not getting any proper documentation to read. i have read about commitlog_archiving.properties and enabled the commit logs archiving but not restore to some point in time and have some queries like after from node failure data if i want to restore to any point is that possible? wt is restore command used for? wt is restore directories used for? by placing archive commit logs in commit log directory and restart node that will get automatic replayed? if i copy archive logs and mention point in time in file does get data before that time? Do we have any example configuration how to use this settings? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251697#comment-17251697
]
Benjamin Lerer commented on CASSANDRA-4938:
---
To be honest, the 4. solution is probably NOT a {{lhf}}.
> CREATE INDEX can block for creation now that schema changes may be concurrent
> -
>
> Key: CASSANDRA-4938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4938
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Assignee: Kirk True
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Response from CREATE INDEX command comes faster than the creation of
> secondary index. So below code:
> {code:xml}
> CREATE INDEX ON tab(name);
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> doesn't return any rows(of course, in column family "tab", there are some
> records with "name" value = 'Chris'..) and any errors ( i would expect
> something like ??"Bad Request: No indexed columns present in by-columns
> clause with Equal operator"??)
> Inputing some timeout between those two commands resolves the problem, so:
> {code:xml}
> CREATE INDEX ON tab(name);
> Sleep(timeout); // for column family with 2000 rows the timeout had to be set
> for ~1 second
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> will return all rows with values as specified.
> I'm using single node cluster.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251689#comment-17251689
]
Benjamin Lerer commented on CASSANDRA-4938:
---
[~kirktrue] The exception thrown is the result of CASSANDRA-8505 which
correspond to the choice number 3. that you originally proposed.
{quote}
1. No rows returned, i.e. leave existing behavior
2. Return rows as they become available in the index
3. Return error ('No indexed columns present') until index creation complete
4. Block until index creation complete as requested by OP. But who blocks? Just
the creating client, all clients? Block for reads, writes, or?
{quote}
Even if {{4.}} is implemented in the way suggested by [~jbellis] you will need
that safety net in case somebody queries the index from another client
application.
As explained by [~slebresne] implementing {{4.}} is not a simple thing to do
and I am not sure it is worth the effort.
[~maxwellguo] The index is effectively local but most of the clients (including
nodetool) connect to only a single node and by consequence do not have a full
view of the cluster. An index can be built on one node but not on another one.
Even if we succeed to check all the nodes that are alive, we would have to
check what happen if a node was down at the time where the {{CREATE INDEX}} was
fired and is restarted after the index of the others has been built. My guess
is that the node will accept queries before its index is build therefore
failing the query but I did not check.
> CREATE INDEX can block for creation now that schema changes may be concurrent
> -
>
> Key: CASSANDRA-4938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4938
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Assignee: Kirk True
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Response from CREATE INDEX command comes faster than the creation of
> secondary index. So below code:
> {code:xml}
> CREATE INDEX ON tab(name);
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> doesn't return any rows(of course, in column family "tab", there are some
> records with "name" value = 'Chris'..) and any errors ( i would expect
> something like ??"Bad Request: No indexed columns present in by-columns
> clause with Equal operator"??)
> Inputing some timeout between those two commands resolves the problem, so:
> {code:xml}
> CREATE INDEX ON tab(name);
> Sleep(timeout); // for column family with 2000 rows the timeout had to be set
> for ~1 second
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> will return all rows with values as specified.
> I'm using single node cluster.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16361) DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata
[
https://issues.apache.org/jira/browse/CASSANDRA-16361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251628#comment-17251628
]
Michael Semb Wever commented on CASSANDRA-16361:
+1
> DROP COMPACT STORAGE should invalidate prepared statements still using
> CompactTableMetadata
> ---
>
> Key: CASSANDRA-16361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16361
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When we drop compact storage from a table, existing prepared statements
> continue to refer to an instance of {{CompactTableMetadata}}, rather than
> being invalidated so they can be assigned a new {{TableMetadata}} instance.
> There are perhaps some brute force ways to fix this, like bouncing the node,
> but that obviously sub-optimal.
> One idea is to have {{TableMetadata#changeAffectsPreparedStatements()}}
> return true when we go from having to not having the DENSE flag. It should be
> pretty easy to validate a fix with a small addition to {{CompactTableTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16361) DROP COMPACT STORAGE should invalidate prepared statements still using CompactTableMetadata
[
https://issues.apache.org/jira/browse/CASSANDRA-16361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-16361:
Reviewers: Alex Petrov
+1, with a minor comment on GH
> DROP COMPACT STORAGE should invalidate prepared statements still using
> CompactTableMetadata
> ---
>
> Key: CASSANDRA-16361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16361
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When we drop compact storage from a table, existing prepared statements
> continue to refer to an instance of {{CompactTableMetadata}}, rather than
> being invalidated so they can be assigned a new {{TableMetadata}} instance.
> There are perhaps some brute force ways to fix this, like bouncing the node,
> but that obviously sub-optimal.
> One idea is to have {{TableMetadata#changeAffectsPreparedStatements()}}
> return true when we go from having to not having the DENSE flag. It should be
> pretty easy to validate a fix with a small addition to {{CompactTableTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
