[jira] [Commented] (CASSANDRA-18676) CorruptedSSTablesCompactionsTest is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-18676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744436#comment-17744436
]
Berenguer Blasi commented on CASSANDRA-18676:
-
I checked and CorruptedSSTablesCompactionsTest was not touched by
CASSANDRA-14227 hence it wasn't run with the multiplexer. It's probably some
corruption causing ldt that can't fit a Uint.
> CorruptedSSTablesCompactionsTest is flaky
> -
>
> Key: CASSANDRA-18676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18676
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable, Test/unit
>Reporter: Branimir Lambov
>Priority: Normal
> Fix For: 5.x
>
>
> See e.g. [this
> run|https://app.circleci.com/pipelines/github/blambov/cassandra/510/workflows/fd484f76-b0f0-48c9-8672-d73bdc36b8ec/jobs/13575/tests].
> The test was looked at for CASSANDRA-15879, but it is still failing from time
> to time. One of the failures appears to be introduced by CASSANDRA-14227 and
> the others by CASSANDRA-18134. The failures are genuine problems with
> handling corruption, not just test issues.
> The {{CorruptSSTableException}} paths in {{SSTableIdentityIterator}} should
> likely also catch {{AssertionError}} and {{IllegalArgumentException}}, and
> most probably the tombstone verification should be done on the read path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744435#comment-17744435 ] Jacek Lewandowski commented on CASSANDRA-17992: --- I agree, currently they are not needed, just something to remember in case of problems. > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch dependabot/npm_and_yarn/site-ui/word-wrap-1.2.4 created (now b506c20b)
This is an automated email from the ASF dual-hosted git repository. github-bot pushed a change to branch dependabot/npm_and_yarn/site-ui/word-wrap-1.2.4 in repository https://gitbox.apache.org/repos/asf/cassandra-website.git at b506c20b Bump word-wrap from 1.2.3 to 1.2.4 in /site-ui No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (7cb4262c -> b00ee6aa)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 7cb4262c generate docs for 69e18568 new b00ee6aa generate docs for 69e18568 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (7cb4262c) \ N -- N -- N refs/heads/asf-staging (b00ee6aa) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18282) Exception message for RTBoundValidator
[ https://issues.apache.org/jira/browse/CASSANDRA-18282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744378#comment-17744378 ] Cameron Zemek commented on CASSANDRA-18282: --- [~brandon.williams] do you have any ideas on starting point to fix this? The stack trace is from once its generating the response. Prior to that in ReadCommandVerbHandler it fetched the UnfilteredPartitionIterator which includes calls to RTBoundValidator.validate . So confused how it passes that check but then when iterating to generate the response it is invalid. > Exception message for RTBoundValidator > -- > > Key: CASSANDRA-18282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18282 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging >Reporter: Brad Schoening >Priority: Normal > > From the exception RTBoundValidator its not clear what 'RT' refers to. > 1.) Exception subject > Instead of: 'has an illegal RT bounds sequence' > change to: 'has an illegal Range Tombstone bounds sequence' > 2.) Why doesn't the (key: %s omdt: [%s]) display in the exception message? > Example: > 2023-01-31 18:26:27,480 [ERROR] [ReadStage-9] cluster_id=5 > ip_address=127.1.1.1 AbstractLocalAwareExecutorService.java:166 - Uncaught > exception on thread Thread[ReadStage-9,5,main] > java.lang.IllegalStateException: MERGED UnfilteredRowIterator for > rdhprod.instrument_alias_map has an illegal RT bounds sequence: unexpected > end bound or boundary Marker INCL_END_BOUND(T, > TBG)@1612002648782856/1612002648 > at > org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.ise(RTBoundValidator.java:120) > ~[apache-cassandra-3.11.11.jar:3.11.11] > at > org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.applyToMarker(RTBoundValidator.java:87) > ~[apache-cassandra-3.11.11.jar:3.11.11] > at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:148) > ~[apache-cassandra-3.11.11.jar:3.11.11] > at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133) > ~[apache-cassandra-3.11.11.jar:3.11.11] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18255) Drop JDK8 Support
[ https://issues.apache.org/jira/browse/CASSANDRA-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744368#comment-17744368 ] Ekaterina Dimitrova commented on CASSANDRA-18255: - WIP 1) Cassandra builds - [https://github.com/ekaterinadimitrova2/cassandra-builds/commit/643c664b2da194bd80131423f27aa7bb38c13499] 2) Cassandra - [https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18255-trunk] TODO: add JVM args for NetBeans and eclipse tasks (those tasks were working only with JDK8); 3) CCM - [https://github.com/ekaterinadimitrova2/ccm/commit/20a3f6221d950832ebf8a4fe935084d52e6851c4] CircleCI run #2424 looks good - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18255-trunk] I will have to spin also local Jenkins and test. I suspect there should be more places to apply changes to in Cassandra-builds > Drop JDK8 Support > - > > Key: CASSANDRA-18255 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18255 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Michael Semb Wever >Assignee: Ekaterina Dimitrova >Priority: High > Fix For: 5.x > > > * update Jenkins builds scripts (Cassandra-builds) for trunk to build and run > tests only with JDK 11 and JDK 17 - both Jenkins-dev and post-commit > * the JDK11+17 config files and script in cassandra/.circleci should replace > the default J8+J11 test config files and script > * Cassandra trunk build.xml and conf files should be updated - JDK8 removed > everywhere > * Any tickets blocked on this one and ready to commit should be committed > * Revert this change in CCM - > [https://github.com/riptano/ccm/commit/6e71061146f7ae67b84ccd2b1d90d7319b640e4c#diff-0999a90fd83b66b6840af0bbd8afd1ebd9648e135b0665692fa0f523325a1058L984] > * Docs will be updated later in CASSANDRA-18233 > NOTE: Python Upgrade tests were already switched to 11 in this > [change|https://github.com/apache/cassandra-dtest/commit/52053200e75d3e6718c03bfa68232dfb94f9a566#diff-31d0989c90471274d54ccce871e5ea977ba477d1b55ee13be6f399fd844c16cfR171], > so I _think_ there is no other change pending in cassandra-dtest repo -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744361#comment-17744361 ] Stefan Miklosovic edited comment on CASSANDRA-18624 at 7/18/23 9:50 PM: I think the conclusion we reached is that we need to remove all dependencies on Corretto. That means Amazon Corretto crypto provider class (the implementation of ICryptoProvider) can not be shipped with the project. We should finish this ticket in such a way that it will be possible to configure a crypto provider class in cassandra.yaml and then you need to put the crypto jar (as well as the implementation) into lib directory yourself. We can not ship that. NoOpProvider as the default provider which does nothing is fine. was (Author: smiklosovic): I think the conclusion we reached is that we need to remove all dependencies on Corretto. That means Amazon Corretto crypto provider class (the implementation of ICryptoProvider) can not be shipped with the project. We should finish this ticket in such a way that it will be possible to configure a crypto provider class in cassandra.yaml and then you need to put the crypto jar into lib directory yourself. We can not ship that. NoOpProvider as the default provider which does nothing is fine. > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Ayushi Singh >Priority: Normal > Attachments: image.png > > Time Spent: 9.5h > Remaining Estimate: 0h > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744361#comment-17744361 ] Stefan Miklosovic commented on CASSANDRA-18624: --- I think the conclusion we reached is that we need to remove all dependencies on Corretto. That means Amazon Corretto crypto provider class (the implementation of ICryptoProvider) can not be shipped with the project. We should finish this ticket in such a way that it will be possible to configure a crypto provider class in cassandra.yaml and then you need to put the crypto jar into lib directory yourself. We can not ship that. NoOpProvider as the default provider which does nothing is fine. > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Ayushi Singh >Priority: Normal > Attachments: image.png > > Time Spent: 9.5h > Remaining Estimate: 0h > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18499:
---
Status: In Progress (was: Patch Available)
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to write and verify data
> write_proc, verify_proc, verification_queue =
> self._start_continuous_write_and_verify(wait_for_rowcount=5000)
>
> # upgrade through versions
> for version_meta in self.test_version_metas[1:]:
> if version_meta.family > '3.11' and internode_ssl:
> seeds =[]
> for seed in cluster.seeds:
> > seeds.append(seed.ip_addr + ':7001')
> E AttributeError: 'str' object has no attribute
> 'ip_addr'
> upgrade_tests/upgrade_through_versions_test.py:422: AttributeError
> {code}
> I haven't seen this failure on Jenkins yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744359#comment-17744359
]
Michael Semb Wever commented on CASSANDRA-18499:
yeah, failures came in that i didn't see :(
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to write and verify data
> write_proc, verify_proc, verification_queue =
> self._start_continuous_write_and_verify(wait_for_rowcount=5000)
>
> # upgrade through versions
> for version_meta in self.test_version_metas[1:]:
> if version_meta.family > '3.11' and internode_ssl:
> seeds =[]
> for seed in cluster.seeds:
> > seeds.append(seed.ip_addr + ':7001')
> E AttributeError: 'str' object has no attribute
> 'ip_addr'
> upgrade_tests/upgrade_through_versions_test.py:422: AttributeError
> {code}
> I haven't seen this failure on Jenkins yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744356#comment-17744356 ] Ayushi Singh commented on CASSANDRA-18624: -- NoOpProvider sounds good to me as a default provider. But if I had to add support for ACCP as another provider then I have to tag a classifier with it, not tagging the classifier will result in downloading an empty package. > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Ayushi Singh >Priority: Normal > Attachments: image.png > > Time Spent: 9.5h > Remaining Estimate: 0h > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744352#comment-17744352
]
Brandon Williams edited comment on CASSANDRA-18499 at 7/18/23 8:41 PM:
---
Looks good except -why are we removing "indev" from the matrix?- those were
just unused variables.
There is still something wrong with the seeds list in
test_rolling_upgrade_with_internode_ssl.
was (Author: brandon.williams):
Looks good except why are we removing "indev" from the matrix? I don't think
we'll catch regressions if we're only testing the last released version.
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to write and verify data
> write_proc, verify_proc, verification_queue =
> self._start_continuous_write_and_verify(wait_for_rowcount=5000)
>
> # upgrade through versions
> for version_meta in self.test_version_metas[1:]:
> if version_meta.family > '3.11' and internode_ssl:
> seeds =[]
> for seed in cluster.seeds:
> > seeds.append(seed.ip_addr + ':7001')
> E AttributeError: 'str' object has no attribute
> 'ip_addr'
> upgrade_tests/upgrade_through_versions_test.py:422: AttributeError
> {code}
> I haven't seen this failure on Jenkins yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e
[jira] [Commented] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744352#comment-17744352
]
Brandon Williams commented on CASSANDRA-18499:
--
Looks good except why are we removing "indev" from the matrix? I don't think
we'll catch regressions if we're only testing the last released version.
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to write and verify data
> write_proc, verify_proc, verification_queue =
> self._start_continuous_write_and_verify(wait_for_rowcount=5000)
>
> # upgrade through versions
> for version_meta in self.test_version_metas[1:]:
> if version_meta.family > '3.11' and internode_ssl:
> seeds =[]
> for seed in cluster.seeds:
> > seeds.append(seed.ip_addr + ':7001')
> E AttributeError: 'str' object has no attribute
> 'ip_addr'
> upgrade_tests/upgrade_through_versions_test.py:422: AttributeError
> {code}
> I haven't seen this failure on Jenkins yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744348#comment-17744348
]
Michael Semb Wever edited comment on CASSANDRA-18499 at 7/18/23 8:28 PM:
-
Fixed with just the dtest patch (above)
- remove the skip annotation, doing skip in the base class at runtime instead,
- handle rewriting seeds in different formats (for internode_ssl)
- filter the MULTI_UPGRADES tests to supported upgrade paths (their original
definition is based on protocol level compatibility, which is needed but is
different to mix-version compatibility)
The in-tree patch (above) is not required, but contains the fixes I needed for
local testing. It will eventually be needed, so it's included here.
CI
-
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/187/workflows/acf8c537-4456-49a1-bc02-c20680d8d052/jobs/12078
-
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/1732/
was (Author: michaelsembwever):
Fixed with just the dtest patch (above)
- remove the skip annotation, doing skip in the base class at runtime instead,
- handle rewriting seeds in different formats (for internode_ssl)
- filter the MULTI_UPGRADES tests to supported upgrade paths (their original
definition is based on protocol level compatibility, which is different to
mix-version compatibility)
The in-tree patch (above) is not required, but contains the fixes I needed for
local testing. It will eventually be needed, so it's included here.
CI
-
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/187/workflows/acf8c537-4456-49a1-bc02-c20680d8d052/jobs/12078
-
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/1732/
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
>
[jira] [Updated] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18499:
---
Test and Documentation Plan: ci
Status: Patch Available (was: In Progress)
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to write and verify data
> write_proc, verify_proc, verification_queue =
> self._start_continuous_write_and_verify(wait_for_rowcount=5000)
>
> # upgrade through versions
> for version_meta in self.test_version_metas[1:]:
> if version_meta.family > '3.11' and internode_ssl:
> seeds =[]
> for seed in cluster.seeds:
> > seeds.append(seed.ip_addr + ':7001')
> E AttributeError: 'str' object has no attribute
> 'ip_addr'
> upgrade_tests/upgrade_through_versions_test.py:422: AttributeError
> {code}
> I haven't seen this failure on Jenkins yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744348#comment-17744348
]
Michael Semb Wever edited comment on CASSANDRA-18499 at 7/18/23 8:27 PM:
-
Fixed with just the dtest patch (above)
- remove the skip annotation, doing skip in the base class at runtime instead,
- handle rewriting seeds in different formats (for internode_ssl)
- filter the MULTI_UPGRADES tests to supported upgrade paths (their original
definition is based on protocol level compatibility, which is different to
mix-version compatibility)
The in-tree patch (above) is not required, but contains the fixes I needed for
local testing. It will eventually be needed, so it's included here.
CI
-
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/187/workflows/acf8c537-4456-49a1-bc02-c20680d8d052/jobs/12078
-
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/1732/
was (Author: michaelsembwever):
Fixed with just the dtest patch (above)
- remove the skip annotation, doing skip in the base class at runtime instead,
- handle rewriting seeds in different formats (for internode_ssl)
- filter the MULTI_UPGRADES tests to supported upgrade paths (their original
definition is based on protocol level compatibility, which is different to
mix-version compatibility)
The in-tree patch is not required, but contains the fixes I needed for local
testing. It will eventually be needed, so it's included here.
CI
-
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/187/workflows/acf8c537-4456-49a1-bc02-c20680d8d052/jobs/12078
-
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/1732/
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_sch
[jira] [Updated] (CASSANDRA-17914) Argparse migration as the Python Optparse library is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17914:
--
Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic)
Status: Review In Progress (was: Needs Committer)
> Argparse migration as the Python Optparse library is deprecated
> ---
>
> Key: CASSANDRA-17914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17914
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Vineet Gali
>Priority: Normal
>
> [Deprecated since version 2.7: The optparse module is deprecated and will not
> be developed further; development will continue with the argparse
> module.|https://docs.python.org/2/library/optparse.html]
> Argparse is described in [PEP 389 – argparse - New Command Line Parsing
> Module|https://peps.python.org/pep-0389/]
>
> A partial upgrade path from
> [{{optparse}}|https://docs.python.org/3/library/optparse.html#module-optparse]
> to
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]:
> https://docs.python.org/3/library/argparse.html#upgrading-optparse-code
> * Replace all
> [{{optparse.OptionParser.add_option()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.add_option]
> calls with
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls.
> * Replace {{(options, args) = parser.parse_args()}} with {{args =
> parser.parse_args()}} and add additional
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls for the positional arguments. Keep in mind that what was previously
> called {{{}options{}}}, now in the
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]
> context is called {{{}args{}}}.
> * Replace
> [{{optparse.OptionParser.disable_interspersed_args()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.disable_interspersed_args]
> by using
> [{{parse_intermixed_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_intermixed_args]
> instead of
> [{{parse_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_args].
> * Replace callback actions and the {{callback_*}} keyword arguments with
> {{type}} or {{action}} arguments.
> * Replace string names for {{type}} keyword arguments with the corresponding
> type objects (e.g. int, float, complex, etc).
> * Replace {{optparse.Values}} with
> [{{Namespace}}|https://docs.python.org/3/library/argparse.html#argparse.Namespace]
> and {{optparse.OptionError}} and {{optparse.OptionValueError}} with
> {{{}ArgumentError{}}}.
> * Replace strings with implicit arguments such as {{%default}} or {{%prog}}
> with the standard Python syntax to use dictionaries to format strings, that
> is, {{%(default)s}} and {{{}%(prog)s{}}}.
> * Replace the OptionParser constructor {{version}} argument with a call to
> {{{}parser.add_argument('--version', action='version', version=' version>'){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744348#comment-17744348
]
Michael Semb Wever edited comment on CASSANDRA-18499 at 7/18/23 8:26 PM:
-
Fixed with just the dtest patch (above)
- remove the skip annotation, doing skip in the base class at runtime instead,
- handle rewriting seeds in different formats (for internode_ssl)
- filter the MULTI_UPGRADES tests to supported upgrade paths (their original
definition is based on protocol level compatibility, which is different to
mix-version compatibility)
The in-tree patch is not required, but contains the fixes I needed for local
testing. It will eventually be needed, so it's included here.
CI
-
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/187/workflows/acf8c537-4456-49a1-bc02-c20680d8d052/jobs/12078
-
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/1732/
was (Author: michaelsembwever):
Fixed with just the dtest patch (above)
- remove the skip annotation, doing skip in the base class at runtime instead,
- handle rewriting seeds in different formats (for internode_ssl)
- filter the MULTI_UPGRADES tests to supported upgrade paths (their original
definition is based on protocol level compatibility, which is different to
mix-version compatibility)
The in-tree patch is not required, but contains the fixes I needed for local
testing. It will eventually be needed, so it's included here.
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to writ
[jira] [Commented] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744348#comment-17744348
]
Michael Semb Wever commented on CASSANDRA-18499:
Fixed with just the dtest patch (above)
- remove the skip annotation, doing skip in the base class at runtime instead,
- handle rewriting seeds in different formats (for internode_ssl)
- filter the MULTI_UPGRADES tests to supported upgrade paths (their original
definition is based on protocol level compatibility, which is different to
mix-version compatibility)
The in-tree patch is not required, but contains the fixes I needed for local
testing. It will eventually be needed, so it's included here.
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to write and verify data
> write_proc, verify_proc, verification_queue =
> self._start_continuous_write_and_verify(wait_for_rowcount=5000)
>
> # upgrade through versions
> for version_meta in self.test_version_metas[1:]:
> if version_meta.family > '3.11' and internode_ssl:
> seeds =[]
> for seed in cluster.seeds:
> > seeds.append(seed.ip_addr + ':7001')
> E AttributeError: 'str' object has no attribute
> 'ip_addr'
> upgrade_tests/upgrade_through_versions_test.py:422: AttributeError
> {code}
> I haven't seen this failure on Jenkins yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscr
svn commit: r63073 - in /dev/cassandra/4.1.3/redhat: ./ noboolean/ noboolean/repodata/ repodata/
Author: smiklosovic Date: Tue Jul 18 20:24:04 2023 New Revision: 63073 Log: staging cassandra rpm packages for 4.1.3 Added: dev/cassandra/4.1.3/redhat/ dev/cassandra/4.1.3/redhat/cassandra-4.1.3-1.noarch.rpm (with props) dev/cassandra/4.1.3/redhat/cassandra-4.1.3-1.src.rpm (with props) dev/cassandra/4.1.3/redhat/cassandra-tools-4.1.3-1.noarch.rpm (with props) dev/cassandra/4.1.3/redhat/noboolean/ dev/cassandra/4.1.3/redhat/noboolean/cassandra-4.1.3-1.noarch.rpm (with props) dev/cassandra/4.1.3/redhat/noboolean/cassandra-4.1.3-1.src.rpm (with props) dev/cassandra/4.1.3/redhat/noboolean/cassandra-tools-4.1.3-1.noarch.rpm (with props) dev/cassandra/4.1.3/redhat/noboolean/repodata/ dev/cassandra/4.1.3/redhat/noboolean/repodata/11bd882bf12672eda334e3777b519341adb71ed4d80a8f65cf44c55ccbdfe014-primary.xml.gz (with props) dev/cassandra/4.1.3/redhat/noboolean/repodata/11bd882bf12672eda334e3777b519341adb71ed4d80a8f65cf44c55ccbdfe014-primary.xml.gz.asc dev/cassandra/4.1.3/redhat/noboolean/repodata/12712aa6e18787377407310426b4b11bfda6fc23aaecc56a63f7c039b74f58f9-other.sqlite.bz2 (with props) dev/cassandra/4.1.3/redhat/noboolean/repodata/12712aa6e18787377407310426b4b11bfda6fc23aaecc56a63f7c039b74f58f9-other.sqlite.bz2.asc dev/cassandra/4.1.3/redhat/noboolean/repodata/6c1166231efebe4beab6731a2307c6b269f13522690cdd368307c60e8fe06126-primary.sqlite.bz2 (with props) dev/cassandra/4.1.3/redhat/noboolean/repodata/6c1166231efebe4beab6731a2307c6b269f13522690cdd368307c60e8fe06126-primary.sqlite.bz2.asc dev/cassandra/4.1.3/redhat/noboolean/repodata/8fbd3ca4f379f75931545accced9d01de5cd9f677ea288facb75b5062f9bbc08-filelists.xml.gz (with props) dev/cassandra/4.1.3/redhat/noboolean/repodata/8fbd3ca4f379f75931545accced9d01de5cd9f677ea288facb75b5062f9bbc08-filelists.xml.gz.asc dev/cassandra/4.1.3/redhat/noboolean/repodata/a115e0b878e77fc27d9b500e75e06446374a0de59b352a6370fe82ad015392c8-filelists.sqlite.bz2 (with props) dev/cassandra/4.1.3/redhat/noboolean/repodata/a115e0b878e77fc27d9b500e75e06446374a0de59b352a6370fe82ad015392c8-filelists.sqlite.bz2.asc dev/cassandra/4.1.3/redhat/noboolean/repodata/af8d0b16b369c2d0e321b0f62fae5a1fdc92d62ee80ab9e54332c601e2778280-other.xml.gz (with props) dev/cassandra/4.1.3/redhat/noboolean/repodata/af8d0b16b369c2d0e321b0f62fae5a1fdc92d62ee80ab9e54332c601e2778280-other.xml.gz.asc dev/cassandra/4.1.3/redhat/noboolean/repodata/repomd.xml dev/cassandra/4.1.3/redhat/noboolean/repodata/repomd.xml.asc dev/cassandra/4.1.3/redhat/repodata/ dev/cassandra/4.1.3/redhat/repodata/223b1e1bcb69421928a5d91c29022a30fb23b1f4d01e52eaa1a0e83276d31d5c-primary.sqlite.bz2 (with props) dev/cassandra/4.1.3/redhat/repodata/223b1e1bcb69421928a5d91c29022a30fb23b1f4d01e52eaa1a0e83276d31d5c-primary.sqlite.bz2.asc dev/cassandra/4.1.3/redhat/repodata/3623f4968201cc73834c25300bb83d2c9777e2356345a1f36ddc0db3906f74d5-other.sqlite.bz2 (with props) dev/cassandra/4.1.3/redhat/repodata/3623f4968201cc73834c25300bb83d2c9777e2356345a1f36ddc0db3906f74d5-other.sqlite.bz2.asc dev/cassandra/4.1.3/redhat/repodata/933d3cf6594838de95ae396ddad4f0e2c345cf2563b0a27f189bd76cdcfb818a-primary.xml.gz (with props) dev/cassandra/4.1.3/redhat/repodata/933d3cf6594838de95ae396ddad4f0e2c345cf2563b0a27f189bd76cdcfb818a-primary.xml.gz.asc dev/cassandra/4.1.3/redhat/repodata/a0a1beceef1e51298752aab19114e44fc1b47a4a0f0829046db101bab6ef928c-filelists.xml.gz (with props) dev/cassandra/4.1.3/redhat/repodata/a0a1beceef1e51298752aab19114e44fc1b47a4a0f0829046db101bab6ef928c-filelists.xml.gz.asc dev/cassandra/4.1.3/redhat/repodata/a3fe2590bdccf84c52210eb096119dff9cfd166313b3cfbd0270bcb7fff7cac8-other.xml.gz (with props) dev/cassandra/4.1.3/redhat/repodata/a3fe2590bdccf84c52210eb096119dff9cfd166313b3cfbd0270bcb7fff7cac8-other.xml.gz.asc dev/cassandra/4.1.3/redhat/repodata/ec8a4020192a9e784eafdec276414ef6532bd38bd7f31789290dece5ae8172fd-filelists.sqlite.bz2 (with props) dev/cassandra/4.1.3/redhat/repodata/ec8a4020192a9e784eafdec276414ef6532bd38bd7f31789290dece5ae8172fd-filelists.sqlite.bz2.asc dev/cassandra/4.1.3/redhat/repodata/repomd.xml dev/cassandra/4.1.3/redhat/repodata/repomd.xml.asc Added: dev/cassandra/4.1.3/redhat/cassandra-4.1.3-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.1.3/redhat/cassandra-4.1.3-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.1.3/redhat/cassandra-4.1.3-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.1.3/redhat/cassandra-4.1.3-1.src.rpm --
svn commit: r63072 - in /dev/cassandra/4.1.3/debian: ./ dists/ dists/41x/ dists/41x/main/ dists/41x/main/binary-amd64/ dists/41x/main/binary-arm64/ dists/41x/main/binary-i386/ dists/41x/main/source/ p
Author: smiklosovic Date: Tue Jul 18 20:14:10 2023 New Revision: 63072 Log: staging cassandra debian packages for 4.1.3 Added: dev/cassandra/4.1.3/debian/ dev/cassandra/4.1.3/debian/cassandra-tools_4.1.3_all.deb (with props) dev/cassandra/4.1.3/debian/cassandra_4.1.3.dsc dev/cassandra/4.1.3/debian/cassandra_4.1.3.tar.gz (with props) dev/cassandra/4.1.3/debian/cassandra_4.1.3_all.deb (with props) dev/cassandra/4.1.3/debian/cassandra_4.1.3_amd64.buildinfo dev/cassandra/4.1.3/debian/cassandra_4.1.3_amd64.changes dev/cassandra/4.1.3/debian/dists/ dev/cassandra/4.1.3/debian/dists/41x/ dev/cassandra/4.1.3/debian/dists/41x/InRelease dev/cassandra/4.1.3/debian/dists/41x/Release dev/cassandra/4.1.3/debian/dists/41x/Release.gpg dev/cassandra/4.1.3/debian/dists/41x/main/ dev/cassandra/4.1.3/debian/dists/41x/main/binary-amd64/ dev/cassandra/4.1.3/debian/dists/41x/main/binary-amd64/Packages dev/cassandra/4.1.3/debian/dists/41x/main/binary-amd64/Packages.gz (with props) dev/cassandra/4.1.3/debian/dists/41x/main/binary-amd64/Release dev/cassandra/4.1.3/debian/dists/41x/main/binary-arm64/ dev/cassandra/4.1.3/debian/dists/41x/main/binary-arm64/Packages dev/cassandra/4.1.3/debian/dists/41x/main/binary-arm64/Packages.gz (with props) dev/cassandra/4.1.3/debian/dists/41x/main/binary-arm64/Release dev/cassandra/4.1.3/debian/dists/41x/main/binary-i386/ dev/cassandra/4.1.3/debian/dists/41x/main/binary-i386/Packages dev/cassandra/4.1.3/debian/dists/41x/main/binary-i386/Packages.gz (with props) dev/cassandra/4.1.3/debian/dists/41x/main/binary-i386/Release dev/cassandra/4.1.3/debian/dists/41x/main/source/ dev/cassandra/4.1.3/debian/dists/41x/main/source/Release dev/cassandra/4.1.3/debian/dists/41x/main/source/Sources.gz (with props) dev/cassandra/4.1.3/debian/pool/ dev/cassandra/4.1.3/debian/pool/main/ dev/cassandra/4.1.3/debian/pool/main/c/ dev/cassandra/4.1.3/debian/pool/main/c/cassandra/ dev/cassandra/4.1.3/debian/pool/main/c/cassandra/cassandra-tools_4.1.3_all.deb (with props) dev/cassandra/4.1.3/debian/pool/main/c/cassandra/cassandra_4.1.3.dsc dev/cassandra/4.1.3/debian/pool/main/c/cassandra/cassandra_4.1.3.tar.gz (with props) dev/cassandra/4.1.3/debian/pool/main/c/cassandra/cassandra_4.1.3_all.deb (with props) Added: dev/cassandra/4.1.3/debian/cassandra-tools_4.1.3_all.deb == Binary file - no diff available. Propchange: dev/cassandra/4.1.3/debian/cassandra-tools_4.1.3_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.1.3/debian/cassandra_4.1.3.dsc == --- dev/cassandra/4.1.3/debian/cassandra_4.1.3.dsc (added) +++ dev/cassandra/4.1.3/debian/cassandra_4.1.3.dsc Tue Jul 18 20:14:10 2023 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 4.1.3 +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 (>= 11), openjdk-8-jdk | java8-jdk | openjdk-11-jdk | java11-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python3-dev (>= 3.6), quilt, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + cd5d00b389ce346fd25a6c96a1a502ecd106038f 13773830 cassandra_4.1.3.tar.gz +Checksums-Sha256: + 2a4b03ea7042d18b8d4c269923c36c59d3262f17f85f6f404e476d6a44bc3a7d 13773830 cassandra_4.1.3.tar.gz +Files: + 5f7b66350759a585863c98d971793ca4 13773830 cassandra_4.1.3.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEdGSq2QaCQcULpqJiMvNcsvVG2T4FAmS28oAACgkQMvNcsvVG +2T42lhAAmLOoP6hQO82G5jeH6C4fFAY1GqAeWxA0SiPu1UeNKiEme7FFzDv1lXYR ++KPDaKSBMcdkOYzE06jJfcDjP8peNmZjD+N8ffHevECW4upL7xXya3xlvhPGObch +Zv/1mCEhcdXv7J1jZ9lZXJzX04obt7Om+2yMGODeWYrTns0H0NfTo1yjAql77u23 +WjQT+zWgmm2QsebUsQhx7wm2a6Lw/SEZrIf39UCVq0sro1oztfOZDju+PAnkf/ds +glt3qkj5KGbaXyBfukobUv45xGG01beryw2TwQ+XbXg8/rZpHwX2EFXvotlrQ32Y ++71IjJC4lKAqmpb7V+4xejm6A7BjzKbb6L62Qok5Q4CMEyuLYdoQiVe6FyyfuX+C +BfhCmfjZ7BHH+jnMJ8Shb9ojoZx+ybqrXPzVe2JRG5D14be7G106Y+fghla2qeW4 +Hfe8FACsw4kdKWTBrBGRbHkHM+pV0/+KGw7rT33ysvmjrU6jZCt/xNwP67RHxNtz +4rNBIL53RYT7yGAKKBYuAE9Fd3keuAAyOFSHABQpgAyM8LC4D+DapjSQv65gWCxA +FcL8JeVwGfKz5S4fjZ2NlYDEdj3U+TfY6VegatwYgEB7XdOyNrEvvTs1fKeiYVsr +eGGmOUroQ1YNKaXVAi3NTN4ukA7s8/ncI+cHjKQgTeALGobhWoA= +=AY1v +-END PGP SIGNATURE- Added: dev/cassandra/4.1.3/debian/cassandra_4.1.3.tar.gz
svn commit: r63071 - /dev/cassandra/4.1.3/
Author: smiklosovic Date: Tue Jul 18 20:10:24 2023 New Revision: 63071 Log: staging cassandra 4.1.3 Added: dev/cassandra/4.1.3/ dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz (with props) dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.asc dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.sha256 dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.sha512 dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz (with props) dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.asc dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.sha256 dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.sha512 Added: dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.asc == --- dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.asc (added) +++ dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.asc Tue Jul 18 20:10:24 2023 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEdGSq2QaCQcULpqJiMvNcsvVG2T4FAmS28VwACgkQMvNcsvVG +2T403w/9Fi0KU3KleV1F2fkU0Pl/44P6+sXxy3WLBqtRIhDA/MzP/0sODQ2fFK+R +JwXySF8vAC6BOTysxGfVMrjXuFa9ma9neql3i2THiMnshTJRGDG48KIGkuEbJ+4/ +D6j346MQfsuRBfWaMbX3k93+N2k2XQXB4mK8+dPuIr5trVZiLz3nzyA9I34Sjrc4 +2/GgzYSKicVFAvYBFvoXjilzG+WUTh1paWlUaFu0Nid9+NuX6A32n+z6li+hyvm3 +o5WrPxNtRqSZFlszl7faxnsVLwD8nNAaviFLrClj2BQmJaRpsW5xp0BqElR7EGL2 +nwKXVYz2WFsdxF/nG3hxsKTaPM1x1V4URCNIWyTuqCeyOeW0dlPLfOtnYwDCZVFh +DWqol0nFKt3zeYbZmKqFpjKsSQSw9tMJTa+Um9kSg95aiiJnMtG4m5QbGjI+R1SG +cwLcK03Q9hPsy389qvnrNHm+DMOAJ06XMOucfzR3gXdfzxpfJjTVwJAZbnM9+DTd +RI6Yrt8zbWvOGEdiCMuZmZj1rZOzgmwKkGR9nmI5iLtUNhEcfLK4Mrxrr9nl79nR +ona7MHRBK3dCb3o2xMmKxi+KrGj1UTMCqHsWWw2vpRB4Y4EZlhhyzvH3Y5rdvfSs +EgcHv2m/7PvPAXKqB1a6bkwqNvpVGpJzQEzpdgF6pTs76ukEJ0E= +=vn3d +-END PGP SIGNATURE- Added: dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.sha256 == --- dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.sha256 (added) +++ dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.sha256 Tue Jul 18 20:10:24 2023 @@ -0,0 +1 @@ +da014999723f4e1e2c15775dac6aaa9ff69a48f6df6465740fcd52ca9d19ea88 Added: dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.sha512 == --- dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.sha512 (added) +++ dev/cassandra/4.1.3/apache-cassandra-4.1.3-bin.tar.gz.sha512 Tue Jul 18 20:10:24 2023 @@ -0,0 +1 @@ +393443a5b9849645362df2f7536e734e1fc6d513aadf440fab8dda3063553394a138805098796d35f9d4d31e2899ecab630a2ec2a44d00d5e63bed549a2e844c Added: dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.asc == --- dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.asc (added) +++ dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.asc Tue Jul 18 20:10:24 2023 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEdGSq2QaCQcULpqJiMvNcsvVG2T4FAmS28V8ACgkQMvNcsvVG +2T6B7BAAlGOq2XWPZE8fuWK3/ssj5vph+5X5vAUSq0sK1/oSy9thZhv4kzu28rob +Aupyw4/uvyXGPmBfDVOZDboSWlmnEd2DnyyTYHjFTASDxfbNsS6QfpvSeYb0eudl +0qVvGVvunumti+yBXxYw4PZhel2051jwHoSMBrxACCO96mWVmRpuLojopP6awdSr +hCIHVrslw8T0aCv1kUtWNpsKY0tpLU5vDJ3MdMs6gf+wzroHnESnJLSmt0pJKJJf +DT19S4A0CZS4vL1rX8R1ToadB0ICNSfjDQwPZSDD7fujD4ubXj3mBhY6odjG+Qmh +g3N9Kl9k/isw0T8KA+IWSA8wnR+dTo+LiEYeNPaqRBenWKXrVjQzmmEwC5tMqZL6 +dBS5sb76ChNQw3I5uc56b+X3HgClpcvOcF0u7w7ejSbDcMDIyOATffxN1Ug8lhet +aYwL8udHTj+nFsgVtSwscPEzQGzX+8WQIAIHd/E3ysm3jZrzQpVgmI+faYsrBrmX +DB8Hnwgoi78aPx7j0sZbTj67ZRcLCs1FZ5Qe/tDf3Bb+1kKIWCs3ERq3DGWyKDjO +800WDk75OnRKU1uZ4/uFYt0iFVw1LYHOl0QIm7n2gaTtAshaaYTCdiXnSpp7+dr3 +H0rW0r1TcH24zZ96wpwIplEiq3Oui5OjFXtAzh/zjUmouarvYmI= +=iqRZ +-END PGP SIGNATURE- Added: dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.sha256 == --- dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.sha256 (added) +++ dev/cassandra/4.1.3/apache-cassandra-4.1.3-src.tar.gz.sha256 Tue Jul 18 20:10:24 2023 @@ -0,0 +1 @@ +5b8bdd200aaa783cbe26944164e71a7f617455dd8b95492fea19048d8afb4ff6 Added: dev/cassandra/4.1.3
[cassandra] tag 4.1.3-tentative created (now 2a4cd36475)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to tag 4.1.3-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git at 2a4cd36475 (commit) This tag includes the following new commits: new 2a4cd36475 Prepare debian changelog for 4.1.3 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.1.3
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to tag 4.1.3-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 2a4cd36475de3eb47207cd88d2d472b876c6816d Author: Stefan Miklosovic AuthorDate: Tue Jul 18 22:04:57 2023 +0200 Prepare debian changelog for 4.1.3 --- debian/changelog | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index 1bb1d0da29..1ab71d4b64 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,8 @@ -cassandra (4.1.3) UNRELEASED; urgency=medium +cassandra (4.1.3) unstable; urgency=medium * New release - -- Mick Semb Wever Thu, 25 May 2023 16:11:28 +0200 + -- Stefan Miklosovic Tue, 18 Jul 2023 22:04:28 +0200 cassandra (4.1.2) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-7-sai updated (4b43c75b00 -> 03851b0a1d)
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a change to branch cep-7-sai in repository https://gitbox.apache.org/repos/asf/cassandra.git from 4b43c75b00 Add support for index implementation selection via USING for CREATE INDEX add 03851b0a1d Removed "proprietary" verbiage in the SAI README No new revisions were added by this update. Summary of changes: src/java/org/apache/cassandra/index/sai/README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18615) CREATE INDEX Modifications for Initial Release of SAI
[
https://issues.apache.org/jira/browse/CASSANDRA-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18615:
Source Control Link:
https://github.com/apache/cassandra/commit/4b43c75b00703c5863228331326ecc95d3fe1605
(was: https://github.com/apache/cassandra/pull/2433)
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
https://github.com/apache/cassandra/commit/4b43c75b00703c5863228331326ecc95d3fe1605
> CREATE INDEX Modifications for Initial Release of SAI
> -
>
> Key: CASSANDRA-18615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18615
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> After a lengthy discussion on the dev list, the community seems to have
> arrived at the following list of TODOs before we release SAI in 5.0:
> 1.) CREATE INDEX should be expanded to support {{USING … WITH OPTIONS…}}
> Essentially, we should be able to do something like {{CREATE INDEX ON tbl(v)
> USING ’sai’ WITH OPTIONS = ...}} and {{CREATE INDEX ON tbl(v) USING
> ‘cassandra’}} as a more specific/complete way to emulate the current behavior
> of {{CREATE INDEX}}.
> 2.) Allow operators to configure, in the YAML, a.) whether an index
> implementation must be specified w/ USING and {{CREATE INDEX}} and b.) what
> the default implementation will be, if {{USING}} isn’t required.
> 3.) The defaults we ship w/ will avoid breaking existing {{CREATE INDEX}}
> usage. (i.e. A default is allowed, and that default will remain ‘cassandra’,
> or the legacy 2i)
> With all this in place, users should be able create SAI indexes w/ the
> simplest possible syntax, no defaults will change, and operators will have
> the ability to change defaults to favor SAI whenever they like.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-7-sai updated: Add support for index implementation selection via USING for CREATE INDEX
This is an automated email from the ASF dual-hosted git repository.
maedhroz pushed a commit to branch cep-7-sai
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-7-sai by this push:
new 4b43c75b00 Add support for index implementation selection via USING
for CREATE INDEX
4b43c75b00 is described below
commit 4b43c75b00703c5863228331326ecc95d3fe1605
Author: Caleb Rackliffe
AuthorDate: Wed Jun 21 17:29:05 2023 -0500
Add support for index implementation selection via USING for CREATE INDEX
patch by Caleb Rackliffe; reviewed by Maxwell Guo and Andres de la Peña for
CASSANDRA-18615
---
conf/cassandra.yaml| 9 ++
doc/cql3/CQL.textile | 12 +-
.../examples/BNF/create_index_statement.bnf| 3 +-
.../cassandra/examples/CQL/create_index.cql| 3 +-
.../pages/developing/cql/cql_singlefile.adoc | 27 +++--
.../cassandra/pages/developing/cql/indexes.adoc| 29 +++--
src/java/org/apache/cassandra/config/Config.java | 7 +-
.../cassandra/config/DatabaseDescriptor.java | 20
.../statements/schema/CreateIndexStatement.java| 23
.../cassandra/index/internal/CassandraIndex.java | 2 +
src/java/org/apache/cassandra/index/sai/README.md | 4 +-
.../cassandra/index/sai/StorageAttachedIndex.java | 2 +
.../org/apache/cassandra/schema/IndexMetadata.java | 5 +-
.../validation/entities/SecondaryIndexTest.java| 46
.../org/apache/cassandra/index/sai/SAITester.java | 2 +-
.../index/sai/cql/CollectionIndexingTest.java | 53 +
.../sai/cql/CompositePartitionKeyIndexTest.java| 12 +-
.../index/sai/cql/MultipleColumnIndexTest.java | 20 ++--
.../index/sai/cql/StorageAttachedIndexDDLTest.java | 124 ++---
.../index/sai/cql/types/IndexingTypeSupport.java | 6 +-
.../index/sai/functional/GroupComponentsTest.java | 6 +-
.../index/sai/virtual/SSTablesSystemViewTest.java | 4 +-
22 files changed, 305 insertions(+), 114 deletions(-)
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 2c4844beca..e016babba8 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -1956,6 +1956,15 @@ drop_compact_storage_enabled: false
# if zero_ttl_on_twcs_enabled is set to false, this property is irrelevant as
such statements will fail.
#zero_ttl_on_twcs_warned: true
+# The default secondary index implementation when CREATE INDEX does not
specify one via USING.
+# ex. "legacy_local_table" - (default) legacy secondary index, implemented as
a hidden table
+# ex. "sai" - "storage-attched" index, implemented via optimized
SSTable/Memtable-attached indexes
+#default_secondary_index: legacy_local_table
+
+# Whether a default secondary index implementation is allowed. If this is
"false", CREATE INDEX must
+# specify an index implementation via USING.
+#default_secondary_index_enabled: true
+
# Startup Checks are executed as part of Cassandra startup process, not all of
them
# are configurable (so you can disable them) but these which are enumerated
bellow.
# Uncomment the startup checks and configure them appropriately to cover your
needs.
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 0073ff7ed3..4f6a4d7338 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -513,7 +513,8 @@ __Sample:__
bc(sample).
CREATE INDEX userIndex ON NerdMovies (user);
CREATE INDEX ON Mutants (abilityId);
-CREATE INDEX ON users (keys(favs));
+CREATE INDEX ON users (KEYS(favs));
+CREATE INDEX ON users (age) USING 'sai';
CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass';
CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass' WITH
OPTIONS = {'storage': '/mnt/ssd/indexes/'};
@@ -521,6 +522,15 @@ The @CREATE INDEX@ statement is used to create a new
(automatic) secondary index
Attempting to create an already existing index will return an error unless the
@IF NOT EXISTS@ option is used. If it is used, the statement will be a no-op if
the index already exists.
+h4(#usingIndex). Index Types
+
+The @USING@ keyword optionally specifies an index type. There are two built-in
types:
+
+* legacy_local_table - (default) legacy secondary index, implemented as a
hidden local table
+* sai - "storage-attched" index, implemented via optimized
SSTable/Memtable-attached indexes
+
+To create a custom index, a fully qualified class name must be specified.
+
h4(#keysIndex). Indexes on Map Keys
When creating an index on a "map column":#map, you may index either the keys
or the values. If the column identifier is placed within the @keys()@
function, the index will be on the map keys, allowing you to use @CONTAINS KEY@
in @WHERE@ clauses. Otherwise, the index will be on the map values.
diff --git a/doc/modules/cassandra/examples/BNF/create_index_statement.bnf
b/doc/modules/cassandra/examples/BNF/create_index_statement
[jira] [Commented] (CASSANDRA-18615) CREATE INDEX Modifications for Initial Release of SAI
[
https://issues.apache.org/jira/browse/CASSANDRA-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744332#comment-17744332
]
Caleb Rackliffe commented on CASSANDRA-18615:
-
Thanks [~adelapena] and [~maxwellguo]. Starting commit...
> CREATE INDEX Modifications for Initial Release of SAI
> -
>
> Key: CASSANDRA-18615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18615
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> After a lengthy discussion on the dev list, the community seems to have
> arrived at the following list of TODOs before we release SAI in 5.0:
> 1.) CREATE INDEX should be expanded to support {{USING … WITH OPTIONS…}}
> Essentially, we should be able to do something like {{CREATE INDEX ON tbl(v)
> USING ’sai’ WITH OPTIONS = ...}} and {{CREATE INDEX ON tbl(v) USING
> ‘cassandra’}} as a more specific/complete way to emulate the current behavior
> of {{CREATE INDEX}}.
> 2.) Allow operators to configure, in the YAML, a.) whether an index
> implementation must be specified w/ USING and {{CREATE INDEX}} and b.) what
> the default implementation will be, if {{USING}} isn’t required.
> 3.) The defaults we ship w/ will avoid breaking existing {{CREATE INDEX}}
> usage. (i.e. A default is allowed, and that default will remain ‘cassandra’,
> or the legacy 2i)
> With all this in place, users should be able create SAI indexes w/ the
> simplest possible syntax, no defaults will change, and operators will have
> the ability to change defaults to favor SAI whenever they like.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-66) Fix failing unit tests in Apache CI
[
https://issues.apache.org/jira/browse/CASSANDRASC-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744326#comment-17744326
]
Francisco Guerrero commented on CASSANDRASC-66:
---
Updated CI:
https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/193
> Fix failing unit tests in Apache CI
> ---
>
> Key: CASSANDRASC-66
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-66
> Project: Sidecar for Apache Cassandra
> Issue Type: Bug
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Currently, the tests under
> {{org.apache.cassandra.sidecar.HealthServiceSslTest}} [are
> failing|https://ci-cassandra.apache.org/job/cassandra~sidecar/42/] when
> running inside ASF's CI. The logs show that some resources (keystore and
> truststore) are not found. This is causing the tests to fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17914) Argparse migration as the Python Optparse library is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744317#comment-17744317
]
Brandon Williams commented on CASSANDRA-17914:
--
The failure on 4.0 is CASSANDRA-18366, the one in 4.1 is CASSANDRA-15239, and
finally on trunk we hit CASSANDRA-17686. No new failures, +1.
> Argparse migration as the Python Optparse library is deprecated
> ---
>
> Key: CASSANDRA-17914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17914
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Vineet Gali
>Priority: Normal
>
> [Deprecated since version 2.7: The optparse module is deprecated and will not
> be developed further; development will continue with the argparse
> module.|https://docs.python.org/2/library/optparse.html]
> Argparse is described in [PEP 389 – argparse - New Command Line Parsing
> Module|https://peps.python.org/pep-0389/]
>
> A partial upgrade path from
> [{{optparse}}|https://docs.python.org/3/library/optparse.html#module-optparse]
> to
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]:
> https://docs.python.org/3/library/argparse.html#upgrading-optparse-code
> * Replace all
> [{{optparse.OptionParser.add_option()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.add_option]
> calls with
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls.
> * Replace {{(options, args) = parser.parse_args()}} with {{args =
> parser.parse_args()}} and add additional
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls for the positional arguments. Keep in mind that what was previously
> called {{{}options{}}}, now in the
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]
> context is called {{{}args{}}}.
> * Replace
> [{{optparse.OptionParser.disable_interspersed_args()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.disable_interspersed_args]
> by using
> [{{parse_intermixed_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_intermixed_args]
> instead of
> [{{parse_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_args].
> * Replace callback actions and the {{callback_*}} keyword arguments with
> {{type}} or {{action}} arguments.
> * Replace string names for {{type}} keyword arguments with the corresponding
> type objects (e.g. int, float, complex, etc).
> * Replace {{optparse.Values}} with
> [{{Namespace}}|https://docs.python.org/3/library/argparse.html#argparse.Namespace]
> and {{optparse.OptionError}} and {{optparse.OptionValueError}} with
> {{{}ArgumentError{}}}.
> * Replace strings with implicit arguments such as {{%default}} or {{%prog}}
> with the standard Python syntax to use dictionaries to format strings, that
> is, {{%(default)s}} and {{{}%(prog)s{}}}.
> * Replace the OptionParser constructor {{version}} argument with a call to
> {{{}parser.add_argument('--version', action='version', version=' version>'){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17914) Argparse migration as the Python Optparse library is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17914:
-
Status: Needs Committer (was: Patch Available)
> Argparse migration as the Python Optparse library is deprecated
> ---
>
> Key: CASSANDRA-17914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17914
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Vineet Gali
>Priority: Normal
>
> [Deprecated since version 2.7: The optparse module is deprecated and will not
> be developed further; development will continue with the argparse
> module.|https://docs.python.org/2/library/optparse.html]
> Argparse is described in [PEP 389 – argparse - New Command Line Parsing
> Module|https://peps.python.org/pep-0389/]
>
> A partial upgrade path from
> [{{optparse}}|https://docs.python.org/3/library/optparse.html#module-optparse]
> to
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]:
> https://docs.python.org/3/library/argparse.html#upgrading-optparse-code
> * Replace all
> [{{optparse.OptionParser.add_option()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.add_option]
> calls with
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls.
> * Replace {{(options, args) = parser.parse_args()}} with {{args =
> parser.parse_args()}} and add additional
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls for the positional arguments. Keep in mind that what was previously
> called {{{}options{}}}, now in the
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]
> context is called {{{}args{}}}.
> * Replace
> [{{optparse.OptionParser.disable_interspersed_args()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.disable_interspersed_args]
> by using
> [{{parse_intermixed_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_intermixed_args]
> instead of
> [{{parse_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_args].
> * Replace callback actions and the {{callback_*}} keyword arguments with
> {{type}} or {{action}} arguments.
> * Replace string names for {{type}} keyword arguments with the corresponding
> type objects (e.g. int, float, complex, etc).
> * Replace {{optparse.Values}} with
> [{{Namespace}}|https://docs.python.org/3/library/argparse.html#argparse.Namespace]
> and {{optparse.OptionError}} and {{optparse.OptionValueError}} with
> {{{}ArgumentError{}}}.
> * Replace strings with implicit arguments such as {{%default}} or {{%prog}}
> with the standard Python syntax to use dictionaries to format strings, that
> is, {{%(default)s}} and {{{}%(prog)s{}}}.
> * Replace the OptionParser constructor {{version}} argument with a call to
> {{{}parser.add_argument('--version', action='version', version=' version>'){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17914) Argparse migration as the Python Optparse library is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17914:
-
Status: Patch Available (was: Open)
> Argparse migration as the Python Optparse library is deprecated
> ---
>
> Key: CASSANDRA-17914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17914
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Vineet Gali
>Priority: Normal
>
> [Deprecated since version 2.7: The optparse module is deprecated and will not
> be developed further; development will continue with the argparse
> module.|https://docs.python.org/2/library/optparse.html]
> Argparse is described in [PEP 389 – argparse - New Command Line Parsing
> Module|https://peps.python.org/pep-0389/]
>
> A partial upgrade path from
> [{{optparse}}|https://docs.python.org/3/library/optparse.html#module-optparse]
> to
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]:
> https://docs.python.org/3/library/argparse.html#upgrading-optparse-code
> * Replace all
> [{{optparse.OptionParser.add_option()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.add_option]
> calls with
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls.
> * Replace {{(options, args) = parser.parse_args()}} with {{args =
> parser.parse_args()}} and add additional
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls for the positional arguments. Keep in mind that what was previously
> called {{{}options{}}}, now in the
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]
> context is called {{{}args{}}}.
> * Replace
> [{{optparse.OptionParser.disable_interspersed_args()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.disable_interspersed_args]
> by using
> [{{parse_intermixed_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_intermixed_args]
> instead of
> [{{parse_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_args].
> * Replace callback actions and the {{callback_*}} keyword arguments with
> {{type}} or {{action}} arguments.
> * Replace string names for {{type}} keyword arguments with the corresponding
> type objects (e.g. int, float, complex, etc).
> * Replace {{optparse.Values}} with
> [{{Namespace}}|https://docs.python.org/3/library/argparse.html#argparse.Namespace]
> and {{optparse.OptionError}} and {{optparse.OptionValueError}} with
> {{{}ArgumentError{}}}.
> * Replace strings with implicit arguments such as {{%default}} or {{%prog}}
> with the standard Python syntax to use dictionaries to format strings, that
> is, {{%(default)s}} and {{{}%(prog)s{}}}.
> * Replace the OptionParser constructor {{version}} argument with a call to
> {{{}parser.add_argument('--version', action='version', version=' version>'){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17914) Argparse migration as the Python Optparse library is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744301#comment-17744301
]
Brandon Williams commented on CASSANDRA-17914:
--
I tested locally without an issue so I suspect we'll have better luck this time.
||Branch||CI||
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17914-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1140/workflows/5f63ef4f-02ff-473e-8b80-c96572b86d1c],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1140/workflows/1808e9fe-e563-4913-889e-f05b94a9b9a5]|
> Argparse migration as the Python Optparse library is deprecated
> ---
>
> Key: CASSANDRA-17914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17914
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Vineet Gali
>Priority: Normal
>
> [Deprecated since version 2.7: The optparse module is deprecated and will not
> be developed further; development will continue with the argparse
> module.|https://docs.python.org/2/library/optparse.html]
> Argparse is described in [PEP 389 – argparse - New Command Line Parsing
> Module|https://peps.python.org/pep-0389/]
>
> A partial upgrade path from
> [{{optparse}}|https://docs.python.org/3/library/optparse.html#module-optparse]
> to
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]:
> https://docs.python.org/3/library/argparse.html#upgrading-optparse-code
> * Replace all
> [{{optparse.OptionParser.add_option()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.add_option]
> calls with
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls.
> * Replace {{(options, args) = parser.parse_args()}} with {{args =
> parser.parse_args()}} and add additional
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls for the positional arguments. Keep in mind that what was previously
> called {{{}options{}}}, now in the
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]
> context is called {{{}args{}}}.
> * Replace
> [{{optparse.OptionParser.disable_interspersed_args()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.disable_interspersed_args]
> by using
> [{{parse_intermixed_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_intermixed_args]
> instead of
> [{{parse_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_args].
> * Replace callback actions and the {{callback_*}} keyword arguments with
> {{type}} or {{action}} arguments.
> * Replace string names for {{type}} keyword arguments with the corresponding
> type objects (e.g. int, float, complex, etc).
> * Replace {{optparse.Values}} with
> [{{Namespace}}|https://docs.python.org/3/library/argparse.html#argparse.Namespace]
> and {{optparse.OptionError}} and {{optparse.OptionValueError}} with
> {{{}ArgumentError{}}}.
> * Replace strings with implicit arguments such as {{%default}} or {{%prog}}
> with the standard Python syntax to use dictionaries to format strings, that
> is, {{%(default)s}} and {{{}%(prog)s{}}}.
> * Replace the OptionParser constructor {{version}} argument with a call to
> {{{}parser.add_argument('--version', action='version', version=' version>'){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (c9ab97a0 -> 7cb4262c)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit c9ab97a0 generate docs for 69e18568 new 7cb4262c generate docs for 69e18568 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (c9ab97a0) \ N -- N -- N refs/heads/asf-staging (7cb4262c) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17914) Argparse migration as the Python Optparse library is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744295#comment-17744295
]
Vineet Gali commented on CASSANDRA-17914:
-
[~brandon.williams] Could you kickstart the 4.1 tests again?
> Argparse migration as the Python Optparse library is deprecated
> ---
>
> Key: CASSANDRA-17914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17914
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Vineet Gali
>Priority: Normal
>
> [Deprecated since version 2.7: The optparse module is deprecated and will not
> be developed further; development will continue with the argparse
> module.|https://docs.python.org/2/library/optparse.html]
> Argparse is described in [PEP 389 – argparse - New Command Line Parsing
> Module|https://peps.python.org/pep-0389/]
>
> A partial upgrade path from
> [{{optparse}}|https://docs.python.org/3/library/optparse.html#module-optparse]
> to
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]:
> https://docs.python.org/3/library/argparse.html#upgrading-optparse-code
> * Replace all
> [{{optparse.OptionParser.add_option()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.add_option]
> calls with
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls.
> * Replace {{(options, args) = parser.parse_args()}} with {{args =
> parser.parse_args()}} and add additional
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls for the positional arguments. Keep in mind that what was previously
> called {{{}options{}}}, now in the
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]
> context is called {{{}args{}}}.
> * Replace
> [{{optparse.OptionParser.disable_interspersed_args()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.disable_interspersed_args]
> by using
> [{{parse_intermixed_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_intermixed_args]
> instead of
> [{{parse_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_args].
> * Replace callback actions and the {{callback_*}} keyword arguments with
> {{type}} or {{action}} arguments.
> * Replace string names for {{type}} keyword arguments with the corresponding
> type objects (e.g. int, float, complex, etc).
> * Replace {{optparse.Values}} with
> [{{Namespace}}|https://docs.python.org/3/library/argparse.html#argparse.Namespace]
> and {{optparse.OptionError}} and {{optparse.OptionValueError}} with
> {{{}ArgumentError{}}}.
> * Replace strings with implicit arguments such as {{%default}} or {{%prog}}
> with the standard Python syntax to use dictionaries to format strings, that
> is, {{%(default)s}} and {{{}%(prog)s{}}}.
> * Replace the OptionParser constructor {{version}} argument with a call to
> {{{}parser.add_argument('--version', action='version', version=' version>'){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18661) Update to cassandra-stress to use Apache Commons CLI
[
https://issues.apache.org/jira/browse/CASSANDRA-18661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Tu reassigned CASSANDRA-18661:
--
Assignee: (was: Timothy Tu)
> Update to cassandra-stress to use Apache Commons CLI
>
>
> Key: CASSANDRA-18661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18661
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/stress
>Reporter: Brad Schoening
>Priority: Normal
>
> The Apache Commons CLI library provides an API for parsing command line
> options with the package org.apache.commons.cli and this is already used by a
> dozen of existing Cassandra utilities including:
> {quote}SSTableMetadataViewer, StandaloneScrubber, StandaloneSplitter,
> SSTableExport, BulkLoader, and others.
> {quote}
> However, cassandra-stress is an outlier which uses its own custom classes to
> parse command line options with classes such as OptionsSimple. In addition,
> the options syntax for username, password, and others are not aligned with
> the format used by CQLSH.
>
> This suggestion is to:
>
> a) Upgrade cassandra-stress to use Apache Commons CLI (no new dependencies
> are required as this library is already used by the project)
>
> b) Align the cassandra-stress CLI options with those in CQLSH,
>
> {quote}For example, using the new syntax like CQLSH:
> {quote}
>
> cassandra-stress -username foo -password bar
> {quote}
> and replacing the old syntax:
> {quote}
> cassandra-stress -mode username=foo and password=bar
>
> This will simplify and unify the code base, eliminate code and reduce the
> confusion between similar named classes such as
> org.apache.cassandra.stress.settings.\{Option, OptionsMulti, OptionsSimple}
> and org.apache.commons.cli.{Option, OptionGroup, Options)
>
> Note: documentation will need to be updated as well
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r63067 - /release/cassandra/4.0.10/
Author: brandonwilliams Date: Tue Jul 18 16:08:11 2023 New Revision: 63067 Log: Remove old release Removed: release/cassandra/4.0.10/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-66) Fix failing unit tests in Apache CI
[
https://issues.apache.org/jira/browse/CASSANDRASC-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-66:
--
Test and Documentation Plan: Fixes unit tests failing in CI
Status: Patch Available (was: In Progress)
PR: https://github.com/apache/cassandra-sidecar/pull/62
CI: https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/192
> Fix failing unit tests in Apache CI
> ---
>
> Key: CASSANDRASC-66
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-66
> Project: Sidecar for Apache Cassandra
> Issue Type: Bug
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Currently, the tests under
> {{org.apache.cassandra.sidecar.HealthServiceSslTest}} [are
> failing|https://ci-cassandra.apache.org/job/cassandra~sidecar/42/] when
> running inside ASF's CI. The logs show that some resources (keystore and
> truststore) are not found. This is causing the tests to fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-66) Fix failing unit tests in Apache CI
[
https://issues.apache.org/jira/browse/CASSANDRASC-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-66:
--
Bug Category: Parent values: Packaging(13660)Level 1 values: Source
Distribution(13661)
Complexity: Normal
Component/s: Configuration
Discovered By: Unit Test
Severity: Low
Status: Open (was: Triage Needed)
> Fix failing unit tests in Apache CI
> ---
>
> Key: CASSANDRASC-66
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-66
> Project: Sidecar for Apache Cassandra
> Issue Type: Bug
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Currently, the tests under
> {{org.apache.cassandra.sidecar.HealthServiceSslTest}} [are
> failing|https://ci-cassandra.apache.org/job/cassandra~sidecar/42/] when
> running inside ASF's CI. The logs show that some resources (keystore and
> truststore) are not found. This is causing the tests to fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-66) Fix failing unit tests in Apache CI
[
https://issues.apache.org/jira/browse/CASSANDRASC-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRASC-66:
--
Labels: pull-request-available (was: )
> Fix failing unit tests in Apache CI
> ---
>
> Key: CASSANDRASC-66
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-66
> Project: Sidecar for Apache Cassandra
> Issue Type: Bug
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Currently, the tests under
> {{org.apache.cassandra.sidecar.HealthServiceSslTest}} [are
> failing|https://ci-cassandra.apache.org/job/cassandra~sidecar/42/] when
> running inside ASF's CI. The logs show that some resources (keystore and
> truststore) are not found. This is causing the tests to fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-66) Fix failing unit tests in Apache CI
Francisco Guerrero created CASSANDRASC-66:
-
Summary: Fix failing unit tests in Apache CI
Key: CASSANDRASC-66
URL: https://issues.apache.org/jira/browse/CASSANDRASC-66
Project: Sidecar for Apache Cassandra
Issue Type: Bug
Reporter: Francisco Guerrero
Assignee: Francisco Guerrero
Currently, the tests under
{{org.apache.cassandra.sidecar.HealthServiceSslTest}} [are
failing|https://ci-cassandra.apache.org/job/cassandra~sidecar/42/] when running
inside ASF's CI. The logs show that some resources (keystore and truststore)
are not found. This is causing the tests to fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18676) CorruptedSSTablesCompactionsTest is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-18676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18676:
Bug Category: Parent values: Degradation(12984)
Complexity: Normal
Discovered By: Unit Test
Severity: Normal
Status: Open (was: Triage Needed)
> CorruptedSSTablesCompactionsTest is flaky
> -
>
> Key: CASSANDRA-18676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18676
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable, Test/unit
>Reporter: Branimir Lambov
>Priority: Normal
>
> See e.g. [this
> run|https://app.circleci.com/pipelines/github/blambov/cassandra/510/workflows/fd484f76-b0f0-48c9-8672-d73bdc36b8ec/jobs/13575/tests].
> The test was looked at for CASSANDRA-15879, but it is still failing from time
> to time. One of the failures appears to be introduced by CASSANDRA-14227 and
> the others by CASSANDRA-18134. The failures are genuine problems with
> handling corruption, not just test issues.
> The {{CorruptSSTableException}} paths in {{SSTableIdentityIterator}} should
> likely also catch {{AssertionError}} and {{IllegalArgumentException}}, and
> most probably the tombstone verification should be done on the read path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18676) CorruptedSSTablesCompactionsTest is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-18676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18676:
Fix Version/s: 5.x
> CorruptedSSTablesCompactionsTest is flaky
> -
>
> Key: CASSANDRA-18676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18676
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable, Test/unit
>Reporter: Branimir Lambov
>Priority: Normal
> Fix For: 5.x
>
>
> See e.g. [this
> run|https://app.circleci.com/pipelines/github/blambov/cassandra/510/workflows/fd484f76-b0f0-48c9-8672-d73bdc36b8ec/jobs/13575/tests].
> The test was looked at for CASSANDRA-15879, but it is still failing from time
> to time. One of the failures appears to be introduced by CASSANDRA-14227 and
> the others by CASSANDRA-18134. The failures are genuine problems with
> handling corruption, not just test issues.
> The {{CorruptSSTableException}} paths in {{SSTableIdentityIterator}} should
> likely also catch {{AssertionError}} and {{IllegalArgumentException}}, and
> most probably the tombstone verification should be done on the read path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18676) CorruptedSSTablesCompactionsTest is flaky
Branimir Lambov created CASSANDRA-18676:
---
Summary: CorruptedSSTablesCompactionsTest is flaky
Key: CASSANDRA-18676
URL: https://issues.apache.org/jira/browse/CASSANDRA-18676
Project: Cassandra
Issue Type: Bug
Components: Local/SSTable, Test/unit
Reporter: Branimir Lambov
See e.g. [this
run|https://app.circleci.com/pipelines/github/blambov/cassandra/510/workflows/fd484f76-b0f0-48c9-8672-d73bdc36b8ec/jobs/13575/tests].
The test was looked at for CASSANDRA-15879, but it is still failing from time
to time. One of the failures appears to be introduced by CASSANDRA-14227 and
the others by CASSANDRA-18134. The failures are genuine problems with handling
corruption, not just test issues.
The {{CorruptSSTableException}} paths in {{SSTableIdentityIterator}} should
likely also catch {{AssertionError}} and {{IllegalArgumentException}}, and most
probably the tombstone verification should be done on the read path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744246#comment-17744246
]
Ekaterina Dimitrova commented on CASSANDRA-17992:
-
Excellent catch, and the solution looks good to me! Thanks!
{quote}bq. {color:#172b4d}which should probably be applied to all
branches{color}
{quote}
{color:#172b4d}Indeed but I suggest we focus on trunk now and the netty upgrade
and open a follow-up ticket to fix the rest of the branches.{color}
> Upgrade Netty on 5.0
>
>
> Key: CASSANDRA-17992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17992
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Low
> Fix For: 5.x
>
>
> I haven't been able to identify from the Netty docs which was the lowest
> version where JDK17 was added but we are about 40 versions behind in netty 4
> so I suspect we better update.
> -We need to consider there was an issue with class cast exceptions when
> building with JDK17 with newer versions of netty (the newest available in
> March 2022). For the record, we didn't see those when running CI on JDK8 and
> JDK11. We also need to carefully revise the changes between the netty
> versions. -->- CASSANDRA-18180
> Upgrading will cover also a fix in netty that was discussed in
> [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF
> Slack thread.
> CC [~benedict] , [~aleksey]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Increment current to 4.0.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/trunk by this push: new f2b48180 Increment current to 4.0.11 f2b48180 is described below commit f2b48180a5905fec44372e8681bffd7157982708 Author: Brandon Williams AuthorDate: Tue Jul 18 08:53:32 2023 -0500 Increment current to 4.0.11 --- 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 4f897e6f..43937b2f 100644 --- a/upgrade_tests/upgrade_manifest.py +++ b/upgrade_tests/upgrade_manifest.py @@ -166,7 +166,7 @@ indev_3_11_x = VersionMeta(name='indev_3_11_x', family=CASSANDRA_3_11, variant=' current_3_11_x = VersionMeta(name='current_3_11_x', family=CASSANDRA_3_11, variant='current', version='3.11.15', min_proto_v=3, max_proto_v=4, java_versions=(8,)) indev_4_0_x = VersionMeta(name='indev_4_0_x', family=CASSANDRA_4_0, variant='indev', version='github:apache/cassandra-4.0', min_proto_v=3, max_proto_v=4, java_versions=(8,11)) -current_4_0_x = VersionMeta(name='current_4_0_x', family=CASSANDRA_4_0, variant='current', version='4.0.10', min_proto_v=4, max_proto_v=5, java_versions=(8,11)) +current_4_0_x = VersionMeta(name='current_4_0_x', family=CASSANDRA_4_0, variant='current', version='4.0.11', min_proto_v=4, max_proto_v=5, java_versions=(8,11)) indev_4_1_x = VersionMeta(name='indev_4_1_x', family=CASSANDRA_4_1, variant='indev', version='github:apache/cassandra-4.1', min_proto_v=4, max_proto_v=5, java_versions=(8,11)) current_4_1_x = VersionMeta(name='current_4_1_x', family=CASSANDRA_4_1, variant='current', version='4.1.2', min_proto_v=4, max_proto_v=5, java_versions=(8,11)) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (1e9c4bc2 -> c9ab97a0)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 1e9c4bc2 generate docs for 898aa3ff add a06941ad Update quickstart.adoc add 9c3f161d ninjafix – don't test generate the website in a github action when on the trunk branch add 466d6ffe ninjafix – don't do inline sed (for compatibility) and don't do `ant echo-base-version` (it doesn't exist) add 69e18568 Minor release 4.0.11 add c9ab97a0 generate docs for 69e18568 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (1e9c4bc2) \ N -- N -- N refs/heads/asf-site (c9ab97a0) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. No new revisions were added by this update. Summary of changes: .github/workflows/site-content.yaml| 5 +- content/_/download.html| 6 +- content/_/quickstart.html | 2 +- .../4.0.0/cassandra/tools/nodetool/bootstrap.html | 6 +- .../4.0.0/cassandra/tools/nodetool/nodetool.html | 8 +- .../cassandra/tools/nodetool/repair_admin.html | 80 - .../4.0.1/cassandra/tools/nodetool/bootstrap.html | 6 +- .../4.0.1/cassandra/tools/nodetool/nodetool.html | 8 +- .../cassandra/tools/nodetool/repair_admin.html | 80 - .../4.0.2/cassandra/tools/nodetool/bootstrap.html | 6 +- .../4.0.2/cassandra/tools/nodetool/nodetool.html | 8 +- .../cassandra/tools/nodetool/repair_admin.html | 80 - .../4.0.3/cassandra/tools/nodetool/bootstrap.html | 6 +- .../4.0.3/cassandra/tools/nodetool/nodetool.html | 8 +- .../cassandra/tools/nodetool/repair_admin.html | 80 - .../4.0.4/cassandra/tools/nodetool/bootstrap.html | 6 +- .../4.0.4/cassandra/tools/nodetool/nodetool.html | 8 +- .../cassandra/tools/nodetool/repair_admin.html | 80 - .../4.0.5/cassandra/tools/nodetool/bootstrap.html | 6 +- .../4.0.5/cassandra/tools/nodetool/nodetool.html | 8 +- .../cassandra/tools/nodetool/repair_admin.html | 80 - .../4.0/cassandra/tools/nodetool/bootstrap.html| 6 +- .../doc/4.0/cassandra/tools/nodetool/nodetool.html | 8 +- .../4.0/cassandra/tools/nodetool/repair_admin.html | 80 - .../4.1/cassandra/tools/nodetool/bootstrap.html| 7 +- .../doc/4.1/cassandra/tools/nodetool/nodetool.html | 7 +- .../4.1/cassandra/tools/nodetool/repair_admin.html | 78 - .../managing/tools/sstable/sstablemetadata.html| 97 + .../4.2/cassandra/tools/nodetool/bootstrap.html| 8 +- .../doc/4.2/cassandra/tools/nodetool/import.html | 6 +- .../doc/4.2/cassandra/tools/nodetool/nodetool.html | 8 +- .../4.2/cassandra/tools/nodetool/repair_admin.html | 68 +++ .../latest/cassandra/tools/nodetool/bootstrap.html | 7 +- .../latest/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 78 - .../stable/cassandra/tools/nodetool/bootstrap.html | 6 +- .../stable/cassandra/tools/nodetool/nodetool.html | 8 +- .../cassandra/tools/nodetool/repair_admin.html | 80 - .../managing/tools/sstable/sstablemetadata.html| 97 + .../trunk/cassandra/tools/nodetool/bootstrap.html | 8 +- .../doc/trunk/cassandra/tools/nodetool/import.html | 6 +- .../trunk/cassandra/tools/nodetool/nodetool.html | 8 +- .../cassandra/tools/nodetool/repair_admin.html | 68 +++ content/search-index.js| 2 +- site-content/docker-entrypoint.sh | 13 ++- .../source/modules/ROOT/pages/download.adoc| 6 +- .../source/modules/ROOT/pages/quickstart.adoc | 2 +- site-ui/build/ui-bundle.zip| Bin 4796900 -> 4796900 bytes 48 files changed, 740 insertions(+), 606 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (3377e45e -> c9ab97a0)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 3377e45e generate docs for 466d6ffe add 69e18568 Minor release 4.0.11 new c9ab97a0 generate docs for 69e18568 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (3377e45e) \ N -- N -- N refs/heads/asf-staging (c9ab97a0) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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. Summary of changes: content/_/download.html| 6 +++--- .../managing/tools/sstable/sstablemetadata.html| 4 .../managing/tools/sstable/sstablemetadata.html| 4 .../source/modules/ROOT/pages/download.adoc| 6 +++--- site-ui/build/ui-bundle.zip| Bin 4796900 -> 4796900 bytes 5 files changed, 14 insertions(+), 6 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Minor release 4.0.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 69e18568 Minor release 4.0.11 69e18568 is described below commit 69e185682945ec7bd3588259e7dcd1e1c5e3a11a Author: Brandon Williams AuthorDate: Tue Jul 18 08:30:29 2023 -0500 Minor release 4.0.11 https://lists.apache.org/thread/hd4lncvnqz8f5c0f2wfv9o2flk02loq2 --- site-content/source/modules/ROOT/pages/download.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/download.adoc b/site-content/source/modules/ROOT/pages/download.adoc index a6b174a2..38789d02 100644 --- a/site-content/source/modules/ROOT/pages/download.adoc +++ b/site-content/source/modules/ROOT/pages/download.adoc @@ -35,14 +35,14 @@ https://www.apache.org/dyn/closer.lua/cassandra/4.1.2/apache-cassandra-4.1.2-bin [discrete] Apache Cassandra 4.0 [discrete] - Latest release on 2023-05-29 + Latest release on 2023-07-18 [discrete] Maintained until 5.1.0 release (~July 2024) [.btn.btn--alt] -https://www.apache.org/dyn/closer.lua/cassandra/4.0.10/apache-cassandra-4.0.10-bin.tar.gz[4.0.10,window=blank] +https://www.apache.org/dyn/closer.lua/cassandra/4.0.11/apache-cassandra-4.0.11-bin.tar.gz[4.0.11,window=blank] -(https://downloads.apache.org/cassandra/4.0.10/apache-cassandra-4.0.10-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/4.0.10/apache-cassandra-4.0.10-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/4.0.10/apache-cassandra-4.0.10-bin.tar.gz.sha512[sha512,window=blank]) +(https://downloads.apache.org/cassandra/4.0.11/apache-cassandra-4.0.11-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/4.0.11/apache-cassandra-4.0.11-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/4.0.11/apache-cassandra-4.0.11-bin.tar.gz.sha512[sha512,window=blank]) -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744224#comment-17744224 ] Jacek Lewandowski commented on CASSANDRA-17992: --- Tomorrow I may try to have a look on python dtests > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18499) Test Failure: upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever reassigned CASSANDRA-18499:
--
Assignee: Michael Semb Wever
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
>
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to write and verify data
> write_proc, verify_proc, verification_queue =
> self._start_continuous_write_and_verify(wait_for_rowcount=5000)
>
> # upgrade through versions
> for version_meta in self.test_version_metas[1:]:
> if version_meta.family > '3.11' and internode_ssl:
> seeds =[]
> for seed in cluster.seeds:
> > seeds.append(seed.ip_addr + ':7001')
> E AttributeError: 'str' object has no attribute
> 'ip_addr'
> upgrade_tests/upgrade_through_versions_test.py:422: AttributeError
> {code}
> I haven't seen this failure on Jenkins yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744186#comment-17744186 ] Jacek Lewandowski edited comment on CASSANDRA-17992 at 7/18/23 12:38 PM: - I've pushed this update along with rebased branch; now running tests: https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/803/workflows/8a8a4b36-92c8-41e6-95d6-364951eb968e (/) was (Author: jlewandowski): I've pushed this update along with rebased branch; now running tests: https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/803/workflows/8a8a4b36-92c8-41e6-95d6-364951eb968e > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744193#comment-17744193
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
We need to exclude all system tables from this patch. It is not desirable to
compress some system table by a default from sstable_compression. It just has
to be as it was before - effectively every time on LZ4.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r63063 - /release/cassandra/4.0.11/redhat/
Author: brandonwilliams Date: Tue Jul 18 11:49:20 2023 New Revision: 63063 Log: Apache Cassandra 4.0.11 redhat artifacts Removed: release/cassandra/4.0.11/redhat/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r63062 - /release/cassandra/4.0.11/debian/
Author: brandonwilliams Date: Tue Jul 18 11:46:29 2023 New Revision: 63062 Log: Apache Cassandra 4.0.11 debian artifacts Removed: release/cassandra/4.0.11/debian/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17992) Upgrade Netty on 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744177#comment-17744177
]
Jacek Lewandowski edited comment on CASSANDRA-17992 at 7/18/23 11:45 AM:
-
I've managed to fix it. The problem is not related to this particular story but
the way we produce a {{dtest jar}}. That repackages all dependencies along with
our classes in a single jar. Some of the dependencies might have digital
signatures which are extracted into {{META-INF}} as say {{*.SF}} files. We need
to remove them because they are invalid for the uber jar we produce.
(see
https://stackoverflow.com/questions/35577351/exclude-jar-from-ant-build-using-zipgroupfileset/35593838#35593838)
Therefore, there are exclusion in {{zipgroupfileset}} operations, more or less
like this:
{noformat}
{noformat}
However, this is wrong. {{exclude}} attribute denotes jar files we don't want
to repackage rather than filter on the content of the jar file. The new
BouncyCastle jars include signatures in SF and DSA files and all of them lands
in the final dtest jar regardless of that filter.
To fix it, I needed to use the following approach:
{noformat}
{noformat}
that is, I excluded bc jars from that zipgroupfileset repackaging and included
them individually. Unlike {{zipgroupfileset}}, {{zipfileset}} allows for
filtering the content of the repackaged jar file. Unfortunately, it allows to
add a single jar at a time, thus we need to provide its exact name. This
solution is not very flexible - we will have to update that task manually each
time we change certain dependencies.
I'll be looking for a better approach, but at least we know what is going on.
was (Author: jlewandowski):
I've managed to fix it. The problem is not related to this particular story but
the way we produce a {{dtest jar}}. That repackages all dependencies along with
our classes in a single jar. Some of the dependencies might have digital
signatures which are extracted into {{META-INF}} as say {{*.SF}} files. We need
to remove them because they are invalid for the uber jar we produce.
Therefore, there are exclusion in {{zipgroupfileset}} operations, more or less
like this:
{noformat}
{noformat}
However, this is wrong. {{exclude}} attribute denotes jar files we don't want
to repackage rather than filter on the content of the jar file. The new
BouncyCastle jars include signatures in SF and DSA files and all of them lands
in the final dtest jar regardless of that filter.
To fix it, I needed to use the following approach:
{noformat}
{noformat}
that is, I excluded bc jars from that zipgroupfileset repackaging and included
them individually. Unlike {{zipgroupfileset}}, {{zipfileset}} allows for
filtering the content of the repackaged jar file. Unfortunately, it allows to
add a single jar at a time, thus we need to provide its exact name. This
solution is not very flexible - we will have to update that task manually each
time we change certain dependencies.
I'll be looking for a better approach, but at least we know what is going on.
> Upgrade Netty on 5.0
>
>
> Key: CASSANDRA-17992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17992
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Low
> Fix For: 5.x
>
>
> I haven't been able to identify from the Netty docs which was the lowest
> version where JDK17 was added but we are about 40 versions behind in netty 4
> so I suspect we better update.
> -We need to consider there was an issue with class cast exceptions when
> building with JDK17 with newer versions of netty (the newest available in
> March 2022). For the record, we didn't see those when running CI on JDK8 and
> JDK11. We also need to carefully revise the changes between the netty
> versions. -->- CASSANDRA-18180
> Upgrading will cover also a fix in netty that was discussed in
> [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF
> Slack thread.
> CC [~benedict] , [~aleksey]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744186#comment-17744186 ] Jacek Lewandowski commented on CASSANDRA-17992: --- I've pushed this update along with rebased branch; now running tests: https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/803/workflows/8a8a4b36-92c8-41e6-95d6-364951eb968e > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r63061 - /dev/cassandra/4.0.11/ /release/cassandra/4.0.11/
Author: brandonwilliams Date: Tue Jul 18 11:43:48 2023 New Revision: 63061 Log: Apache Cassandra 4.0.11 release Added: release/cassandra/4.0.11/ - copied from r63060, dev/cassandra/4.0.11/ Removed: dev/cassandra/4.0.11/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744185#comment-17744185
]
Jacek Lewandowski commented on CASSANDRA-17992:
---
I think we may use more radical approach:
{code}
{code}
which should be probably applied to all branches
> Upgrade Netty on 5.0
>
>
> Key: CASSANDRA-17992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17992
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Low
> Fix For: 5.x
>
>
> I haven't been able to identify from the Netty docs which was the lowest
> version where JDK17 was added but we are about 40 versions behind in netty 4
> so I suspect we better update.
> -We need to consider there was an issue with class cast exceptions when
> building with JDK17 with newer versions of netty (the newest available in
> March 2022). For the record, we didn't see those when running CI on JDK8 and
> JDK11. We also need to carefully revise the changes between the netty
> versions. -->- CASSANDRA-18180
> Upgrading will cover also a fix in netty that was discussed in
> [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF
> Slack thread.
> CC [~benedict] , [~aleksey]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0.11-tentative deleted (was f8584b943e)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to tag 4.0.11-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git *** WARNING: tag 4.0.11-tentative was deleted! *** was f8584b943e Prepare debian changelog for 4.0.11 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] annotated tag cassandra-4.0.11 created (now bddc4fdd34)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to annotated tag cassandra-4.0.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git at bddc4fdd34 (tag) tagging f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5 (commit) replaces cassandra-4.0.10 by Brandon Williams on Tue Jul 18 06:41:10 2023 -0500 - Log - Apache Cassandra 4.0.11 release --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18615) CREATE INDEX Modifications for Initial Release of SAI
[
https://issues.apache.org/jira/browse/CASSANDRA-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18615:
--
Status: Ready to Commit (was: Review In Progress)
> CREATE INDEX Modifications for Initial Release of SAI
> -
>
> Key: CASSANDRA-18615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18615
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> After a lengthy discussion on the dev list, the community seems to have
> arrived at the following list of TODOs before we release SAI in 5.0:
> 1.) CREATE INDEX should be expanded to support {{USING … WITH OPTIONS…}}
> Essentially, we should be able to do something like {{CREATE INDEX ON tbl(v)
> USING ’sai’ WITH OPTIONS = ...}} and {{CREATE INDEX ON tbl(v) USING
> ‘cassandra’}} as a more specific/complete way to emulate the current behavior
> of {{CREATE INDEX}}.
> 2.) Allow operators to configure, in the YAML, a.) whether an index
> implementation must be specified w/ USING and {{CREATE INDEX}} and b.) what
> the default implementation will be, if {{USING}} isn’t required.
> 3.) The defaults we ship w/ will avoid breaking existing {{CREATE INDEX}}
> usage. (i.e. A default is allowed, and that default will remain ‘cassandra’,
> or the legacy 2i)
> With all this in place, users should be able create SAI indexes w/ the
> simplest possible syntax, no defaults will change, and operators will have
> the ability to change defaults to favor SAI whenever they like.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18615) CREATE INDEX Modifications for Initial Release of SAI
[
https://issues.apache.org/jira/browse/CASSANDRA-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744184#comment-17744184
]
Andres de la Peña edited comment on CASSANDRA-18615 at 7/18/23 11:39 AM:
-
The repeated CI run shows [a single failure of most of the methods of
{{StorageAttachedIndexDDLTest}}|https://app.circleci.com/pipelines/github/maedhroz/cassandra/744/workflows/8efbf733-8007-4092-8c26-e349b7fd9576/jobs/10731]
during the same run. The failure seems environmental, due to an issue while
binding a port to an address already in use. The other test failures
({{{}VirtualTableFromInternodeTest{}}} and JDK 17 stuff) are known issues. So I
think CI results are good, +1.
was (Author: adelapena):
The repeated CI run shows [a single failure of most of the methods of
{{StorageAttachedIndexDDLTest}}|https://app.circleci.com/pipelines/github/maedhroz/cassandra/744/workflows/8efbf733-8007-4092-8c26-e349b7fd9576/jobs/10731].
The failure seems environmental, due to an issue while binding a port to an
address already in use. The other test failures
({{{}VirtualTableFromInternodeTest{}}} and JDK 17 stuff) are known issues. So I
think CI results are good, +1.
> CREATE INDEX Modifications for Initial Release of SAI
> -
>
> Key: CASSANDRA-18615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18615
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> After a lengthy discussion on the dev list, the community seems to have
> arrived at the following list of TODOs before we release SAI in 5.0:
> 1.) CREATE INDEX should be expanded to support {{USING … WITH OPTIONS…}}
> Essentially, we should be able to do something like {{CREATE INDEX ON tbl(v)
> USING ’sai’ WITH OPTIONS = ...}} and {{CREATE INDEX ON tbl(v) USING
> ‘cassandra’}} as a more specific/complete way to emulate the current behavior
> of {{CREATE INDEX}}.
> 2.) Allow operators to configure, in the YAML, a.) whether an index
> implementation must be specified w/ USING and {{CREATE INDEX}} and b.) what
> the default implementation will be, if {{USING}} isn’t required.
> 3.) The defaults we ship w/ will avoid breaking existing {{CREATE INDEX}}
> usage. (i.e. A default is allowed, and that default will remain ‘cassandra’,
> or the legacy 2i)
> With all this in place, users should be able create SAI indexes w/ the
> simplest possible syntax, no defaults will change, and operators will have
> the ability to change defaults to favor SAI whenever they like.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18615) CREATE INDEX Modifications for Initial Release of SAI
[
https://issues.apache.org/jira/browse/CASSANDRA-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744184#comment-17744184
]
Andres de la Peña commented on CASSANDRA-18615:
---
The repeated CI run shows [a single failure of most of the methods of
{{StorageAttachedIndexDDLTest}}|https://app.circleci.com/pipelines/github/maedhroz/cassandra/744/workflows/8efbf733-8007-4092-8c26-e349b7fd9576/jobs/10731].
The failure seems environmental, due to an issue while binding a port to an
address already in use. The other test failures
({{{}VirtualTableFromInternodeTest{}}} and JDK 17 stuff) are known issues. So I
think CI results are good, +1.
> CREATE INDEX Modifications for Initial Release of SAI
> -
>
> Key: CASSANDRA-18615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18615
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> After a lengthy discussion on the dev list, the community seems to have
> arrived at the following list of TODOs before we release SAI in 5.0:
> 1.) CREATE INDEX should be expanded to support {{USING … WITH OPTIONS…}}
> Essentially, we should be able to do something like {{CREATE INDEX ON tbl(v)
> USING ’sai’ WITH OPTIONS = ...}} and {{CREATE INDEX ON tbl(v) USING
> ‘cassandra’}} as a more specific/complete way to emulate the current behavior
> of {{CREATE INDEX}}.
> 2.) Allow operators to configure, in the YAML, a.) whether an index
> implementation must be specified w/ USING and {{CREATE INDEX}} and b.) what
> the default implementation will be, if {{USING}} isn’t required.
> 3.) The defaults we ship w/ will avoid breaking existing {{CREATE INDEX}}
> usage. (i.e. A default is allowed, and that default will remain ‘cassandra’,
> or the legacy 2i)
> With all this in place, users should be able create SAI indexes w/ the
> simplest possible syntax, no defaults will change, and operators will have
> the ability to change defaults to favor SAI whenever they like.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744182#comment-17744182 ] Berenguer Blasi commented on CASSANDRA-17992: - Nice catch... > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744177#comment-17744177
]
Jacek Lewandowski commented on CASSANDRA-17992:
---
I've managed to fix it. The problem is not related to this particular story but
the way we produce a {{dtest jar}}. That repackages all dependencies along with
our classes in a single jar. Some of the dependencies might have digital
signatures which are extracted into {{META-INF}} as say {{*.SF}} files. We need
to remove them because they are invalid for the uber jar we produce.
Therefore, there are exclusion in {{zipgroupfileset}} operations, more or less
like this:
{noformat}
{noformat}
However, this is wrong. {{exclude}} attribute denotes jar files we don't want
to repackage rather than filter on the content of the jar file. The new
BouncyCastle jars include signatures in SF and DSA files and all of them lands
in the final dtest jar regardless of that filter.
To fix it, I needed to use the following approach:
{noformat}
{noformat}
that is, I excluded bc jars from that zipgroupfileset repackaging and included
them individually. Unlike {{zipgroupfileset}}, {{zipfileset}} allows for
filtering the content of the repackaged jar file. Unfortunately, it allows to
add a single jar at a time, thus we need to provide its exact name. This
solution is not very flexible - we will have to update that task manually each
time we change certain dependencies.
I'll be looking for a better approach, but at least we know what is going on.
> Upgrade Netty on 5.0
>
>
> Key: CASSANDRA-17992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17992
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Low
> Fix For: 5.x
>
>
> I haven't been able to identify from the Netty docs which was the lowest
> version where JDK17 was added but we are about 40 versions behind in netty 4
> so I suspect we better update.
> -We need to consider there was an issue with class cast exceptions when
> building with JDK17 with newer versions of netty (the newest available in
> March 2022). For the record, we didn't see those when running CI on JDK8 and
> JDK11. We also need to carefully revise the changes between the netty
> versions. -->- CASSANDRA-18180
> Upgrading will cover also a fix in netty that was discussed in
> [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF
> Slack thread.
> CC [~benedict] , [~aleksey]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744174#comment-17744174
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
OK.
We introduced this:
{code}
case fast:
if
(!compressor.recommendedUses().contains(ICompressor.Uses.FAST_COMPRESSION))
{
// it may happen that default compressor in
cassandra.yaml will not be fast,
// if that is the case, we need to fall back to a
default compressor which is fast
compressionParams = CompressionParams.defaultParams();
if
(!compressionParams.getSstableCompressor().recommendedUses().contains(ICompressor.Uses.FAST_COMPRESSION))
{
compressionParams =
CompressionParams.defaultFastCompression();
}
break;
}
{code}
This has to be reverted how it was:
{code}
case fast:
if
(!compressor.recommendedUses().contains(ICompressor.Uses.FAST_COMPRESSION))
{
// The default compressor is generally fast (LZ4 with
16KiB block size)
compressionParams = CompressionParams.DEFAULT;
break;
}
{code}
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18659) Upgrade apache commons cli to 1.5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18659: - Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/00e5431d64a28b17ffd0d3a62b7c01ea0ea32aaa Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks everyone! > Upgrade apache commons cli to 1.5.0 > --- > > Key: CASSANDRA-18659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18659 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Timothy Tu >Assignee: Timothy Tu >Priority: Normal > Fix For: 5.0 > > > Upgrade apache commons-cli from 1.1 (July 2007) to 1.5.0 (October 2021). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Upgrade commons cli to 1.5.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams 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 00e5431d64 Upgrade commons cli to 1.5.0 00e5431d64 is described below commit 00e5431d64a28b17ffd0d3a62b7c01ea0ea32aaa Author: timothytu12 AuthorDate: Mon Jul 17 12:45:47 2023 -0400 Upgrade commons cli to 1.5.0 Patch by Timothy Tu; reviewed by bereng and brandonwilliams for CASSANDRA-18659 --- .build/parent-pom-template.xml | 2 +- CHANGES.txt| 1 + .../managing/tools/sstable/sstablemetadata.adoc| 1 + .../cassandra/tools/SSTableMetadataViewer.java | 5 + .../apache/cassandra/tools/AuditLogViewerTest.java | 6 +++--- .../apache/cassandra/tools/HashPasswordTest.java | 8 +--- .../apache/cassandra/tools/SSTableExportTest.java | 1 - .../cassandra/tools/SSTableMetadataViewerTest.java | 7 --- .../cassandra/tools/SSTablePartitionsTest.java | 13 ++-- .../cassandra/tools/StandaloneScrubberTest.java| 24 +++--- .../cassandra/tools/StandaloneVerifierTest.java| 6 -- 11 files changed, 43 insertions(+), 31 deletions(-) diff --git a/.build/parent-pom-template.xml b/.build/parent-pom-template.xml index 3eaa9ba3af..a57739f963 100644 --- a/.build/parent-pom-template.xml +++ b/.build/parent-pom-template.xml @@ -306,7 +306,7 @@ commons-cli commons-cli -1.1 +1.5.0 commons-codec diff --git a/CHANGES.txt b/CHANGES.txt index 996c938f00..178ed2b5ae 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 5.0 + * Upgrade commons cli to 1.5.0 (CASSANDRA-18659) * Disable the deprecated keyspace/table thresholds and convert them to guardrails (CASSANDRA-18617) * Deprecate CloudstackSnitch and remove duplicate code in snitches (CASSANDRA-18438) * Add support for vectors in UDFs (CASSANDRA-18613) diff --git a/doc/modules/cassandra/pages/managing/tools/sstable/sstablemetadata.adoc b/doc/modules/cassandra/pages/managing/tools/sstable/sstablemetadata.adoc index 6eab727348..03cd3cd81d 100644 --- a/doc/modules/cassandra/pages/managing/tools/sstable/sstablemetadata.adoc +++ b/doc/modules/cassandra/pages/managing/tools/sstable/sstablemetadata.adoc @@ -18,6 +18,7 @@ sstablemetadata |=== |--colors |Use ANSI color sequences |--gc_grace_seconds |The gc_grace_seconds to use when calculating +|--help |Help |--scan |Full sstable scan for additional details. Only available in 3.0+ sstables. Defaults: false |--timestamp_unit|Time unit that cell timestamps are written with |--unicode|Use unicode to draw histograms and progress bars diff --git a/src/java/org/apache/cassandra/tools/SSTableMetadataViewer.java b/src/java/org/apache/cassandra/tools/SSTableMetadataViewer.java index 2f3e39be8b..aa5cfbff25 100644 --- a/src/java/org/apache/cassandra/tools/SSTableMetadataViewer.java +++ b/src/java/org/apache/cassandra/tools/SSTableMetadataViewer.java @@ -83,6 +83,7 @@ public class SSTableMetadataViewer private static final String GCGS_KEY = "g"; private static final String TIMESTAMP_UNIT = "t"; private static final String SCAN = "s"; +private static final String HELP = "h"; private static final Comparator VCOMP = Comparator.comparingLong(ValuedByteBuffer::getValue).reversed(); static @@ -517,6 +518,10 @@ public class SSTableMetadataViewer tsUnit.setOptionalArg(true); options.addOption(tsUnit); +Option help = new Option(HELP, "help", false, "Help"); +help.setOptionalArg(true); +options.addOption(help); + Option scanEnabled = new Option(SCAN, "scan", false, "Full sstable scan for additional details. Only available in 3.0+ sstables. Defaults: false"); scanEnabled.setOptionalArg(true); diff --git a/test/unit/org/apache/cassandra/tools/AuditLogViewerTest.java b/test/unit/org/apache/cassandra/tools/AuditLogViewerTest.java index 514857efc2..76ed9ba04b 100644 --- a/test/unit/org/apache/cassandra/tools/AuditLogViewerTest.java +++ b/test/unit/org/apache/cassandra/tools/AuditLogViewerTest.java @@ -96,9 +96,9 @@ public class AuditLogViewerTest " indefinitely waiting for more records\n" + " -h,--help display this help message\n" + " -i,--ignore Silently ignore unsupported records\n" + - " -r,--roll_cycleHow often to roll the log file was rolled. May be\n" + - " necessary for Chronicle to correctly parse file names. (MINUTELY, HOURLY,\n" + - " DAILY)
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744163#comment-17744163
]
Michael Semb Wever commented on CASSANDRA-12937:
I would expect the flush_compression to always take precedence when flushing.
`nodetool snapshot` shouldn't change anything, flushing is flushing…
At flush time the sstable_compression setting should not be used, the table
created already has a compressor assigned. When flushing it is used if
`flush_compression=table` or `flush_compression=fast AND table compressor is
fast`. If `flush_compression=none` then no compression is used. If
`flush_compression=fast` and the table's compressor is not fast then lz4 is
used.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-12937:
-
Assignee: Stefan Miklosovic
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: In Progress (was: Changes Suggested)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744151#comment-17744151
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 7/18/23 10:30 AM:
-
I want to highlight one not-so-obvious consequence of introducing this patch.
There is flush_compression property in cassandra.yaml doing this:
{code}
# Compression to apply to SSTables as they flush for compressed tables.
# Note that tables without compression enabled do not respect this flag.
#
# As high ratio compressors like LZ4HC, Zstd, and Deflate can potentially
# block flushes for too long, the default is to flush with a known fast
# compressor in those cases. Options are:
#
# none : Flush without compressing blocks but while still doing checksums.
# fast : Flush with a fast compressor. If the table is already using a
#fast compressor that compressor is used.
# table: Always flush with the same compressor that the table uses. This
#was the pre 4.0 behavior.
#
# flush_compression: fast
{code}
By default, "fast" compressor is LZ4, it will use that one.
So, by default, "fast" compressor is used for flushing (LZ4). Hence, if one
does "nodetool snapshot", it will do snapshots of all tables, user defined as
well as system tables and it is compressed with LZ4.
If one specifies a custom compressor to be used in newly introduced
"sstable_compression" field, two situations might happen:
1) the compressor is not "fast" (check ICompressor.Uses and
ICompressor.recommendedUses()), that means that we need to fallback to a fast
compressor - it will default to LZ4
2) the compressor is fast - so we are going to flush *system* tables with a
*custom, user-specified, ICompressor*.
I want to be sure that we are on the same page. While it makes sense to do it
like that - a user specified a custom compressor to use - that also means that
system tables will be compressed with that compressor as well. I want to be
sure everybody is OK with this.
If we are not comfortable with that, we can check in DataComponent where
compressionParams are resolved to always flush with LZ4 when flushing system
tables, no matter what sstable_compressor is set to. I think that that is safer
to do. LZ4 is battle-tested. I am not completely sure that a user knows that if
he provides his fast compressor it is going to be used for flushing the system
tables as well. That is rather a delicate matter ...
was (Author: smiklosovic):
I want to highlight one not-so-obvious consequence of introducing this patch.
There is flush_compression property in cassandra.yaml doing this:
{code}
# Compression to apply to SSTables as they flush for compressed tables.
# Note that tables without compression enabled do not respect this flag.
#
# As high ratio compressors like LZ4HC, Zstd, and Deflate can potentially
# block flushes for too long, the default is to flush with a known fast
# compressor in those cases. Options are:
#
# none : Flush without compressing blocks but while still doing checksums.
# fast : Flush with a fast compressor. If the table is already using a
#fast compressor that compressor is used.
# table: Always flush with the same compressor that the table uses. This
#was the pre 4.0 behavior.
#
# flush_compression: fast
{code}
By default, "fast" compressor is LZ4, it will use that one.
So, by default, "fast" compressor is used for flushing (LZ4). Hence, if one
does "nodetool snapshot", it will do snapshots of all tables, user defined as
well as system tables and it is compressed with LZ4.
If one specifies a custom compressor to be used in newly introduced
"sstable_compression" field, two situations might happen:
1) the compressor is not "fast" (check ICompressor.Uses and
ICompressor.recommendedUses()), that means that we need to fallback to a fast
compressor - it will default to LZ4
2) the compressor is fast - so we are going to flush *system* tables with a
*custom, user-specified, ICompressor*.
I want to be sure that we are on the same page. While it makes sense to do it
like that - a user specified a custom compressor to use - that also means that
system tables will be compressed with that compressor as well. I want to be
sure everybody is OK with this.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks a
[jira] [Comment Edited] (CASSANDRA-17992) Upgrade Netty on 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744158#comment-17744158
]
Jacek Lewandowski edited comment on CASSANDRA-17992 at 7/18/23 10:29 AM:
-
I found a hidden exception under the hood:
{noformat}
java.lang.SecurityException: Invalid signature file digest for Manifest main
attributes
at
java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:316)
at
java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:258)
at
java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:283)
at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239)
at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:767)
at java.base/java.util.jar.JarFile.getInputStream(JarFile.java:852)
at
java.base/jdk.internal.util.jar.JarIndex.getJarIndex(JarIndex.java:121)
at
java.base/jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:760)
at
java.base/jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:752)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:751)
at
java.base/jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:726)
at
java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:494)
at
java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:477)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:476)
at
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:445)
at
java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:314)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:455)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:452)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:451)
at
org.apache.cassandra.distributed.shared.InstanceClassLoader.findClass(InstanceClassLoader.java:143)
at
org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:126)
at
org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:112)
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.lookupDeserializeOneObject(IsolatedExecutor.java:235)
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.transferAdhocPropagate(IsolatedExecutor.java:204)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.newInstance(AbstractCluster.java:292)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegateForStartup(AbstractCluster.java:267)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:385)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:358)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:359)
at
org.apache.cassandra.distributed.upgrade.BatchUpgradeTest.batchTest(BatchUpgradeTest.java:53)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744158#comment-17744158
]
Jacek Lewandowski commented on CASSANDRA-17992:
---
I found a hidden exception under the hood:
{noformat}
java.lang.SecurityException: Invalid signature file digest for Manifest main
attributes
at
java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:316)
at
java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:258)
at
java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:283)
at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239)
at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:767)
at java.base/java.util.jar.JarFile.getInputStream(JarFile.java:852)
at
java.base/jdk.internal.util.jar.JarIndex.getJarIndex(JarIndex.java:121)
at
java.base/jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:760)
at
java.base/jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:752)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:751)
at
java.base/jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:726)
at
java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:494)
at
java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:477)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:476)
at
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:445)
at
java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:314)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:455)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:452)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:451)
at
org.apache.cassandra.distributed.shared.InstanceClassLoader.findClass(InstanceClassLoader.java:143)
at
org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:126)
at
org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:112)
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.lookupDeserializeOneObject(IsolatedExecutor.java:235)
at
org.apache.cassandra.distributed.impl.IsolatedExecutor.transferAdhocPropagate(IsolatedExecutor.java:204)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.newInstance(AbstractCluster.java:292)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegateForStartup(AbstractCluster.java:267)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:385)
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:358)
at
org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:359)
at
org.apache.cassandra.distributed.upgrade.BatchUpgradeTest.batchTest(BatchUpgradeTest.java:53)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744151#comment-17744151
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 7/18/23 10:17 AM:
-
I want to highlight one not-so-obvious consequence of introducing this patch.
There is flush_compression property in cassandra.yaml doing this:
{code}
# Compression to apply to SSTables as they flush for compressed tables.
# Note that tables without compression enabled do not respect this flag.
#
# As high ratio compressors like LZ4HC, Zstd, and Deflate can potentially
# block flushes for too long, the default is to flush with a known fast
# compressor in those cases. Options are:
#
# none : Flush without compressing blocks but while still doing checksums.
# fast : Flush with a fast compressor. If the table is already using a
#fast compressor that compressor is used.
# table: Always flush with the same compressor that the table uses. This
#was the pre 4.0 behavior.
#
# flush_compression: fast
{code}
By default, "fast" compressor is LZ4, it will use that one.
So, by default, "fast" compressor is used for flushing (LZ4). Hence, if one
does "nodetool snapshot", it will do snapshots of all tables, user defined as
well as system tables and it is compressed with LZ4.
If one specifies a custom compressor to be used in newly introduced
"sstable_compression" field, two situations might happen:
1) the compressor is not "fast" (check ICompressor.Uses and
ICompressor.recommendedUses()), that means that we need to fallback to a fast
compressor - it will default to LZ4
2) the compressor is fast - so we are going to flush *system* tables with a
*custom, user-specified, ICompressor*.
I want to be sure that we are on the same page. While it makes sense to do it
like that - a user specified a custom compressor to use - that also means that
system tables will be compressed with that compressor as well. I want to be
sure everybody is OK with this.
was (Author: smiklosovic):
I want to highlight one not-so-obvious consequence of introducing this patch.
There is flush_compression property in cassandra.yaml doing this:
{code}
# Compression to apply to SSTables as they flush for compressed tables.
# Note that tables without compression enabled do not respect this flag.
#
# As high ratio compressors like LZ4HC, Zstd, and Deflate can potentially
# block flushes for too long, the default is to flush with a known fast
# compressor in those cases. Options are:
#
# none : Flush without compressing blocks but while still doing checksums.
# fast : Flush with a fast compressor. If the table is already using a
#fast compressor that compressor is used.
# table: Always flush with the same compressor that the table uses. This
#was the pre 4.0 behavior.
#
# flush_compression: fast
{code}
By default, "fast" compressor is LZ4, it will use that one.
So, by default, "fast" compressor is used for flushing (LZ4). Hence, if one
does "nodetool snapshot", it will do snapshots of all tables, user defined as
well as system tables and it is compressed with LZ4.
If one specifies a custom compressor to be used in newly introduced
"sstable_compression" field, two situations might happen:
1) the default compressor is not "fast" (check ICompressor.Uses and
ICompressor.recommendedUses()), that means that we need to fallback to a fast
compressor - it will default to LZ4
2) the default compressor is fast - so we are going to flush *system* tables
with a *custom, user-specified, ICompressor*.
I want to be sure that we are on the same page. While it makes sense to do it
like that - a user specified a custom compressor to use - that also means that
system tables will be compressed with that compressor as well. I want to be
sure everybody is OK with this.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744151#comment-17744151
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 7/18/23 10:16 AM:
-
I want to highlight one not-so-obvious consequence of introducing this patch.
There is flush_compression property in cassandra.yaml doing this:
{code}
# Compression to apply to SSTables as they flush for compressed tables.
# Note that tables without compression enabled do not respect this flag.
#
# As high ratio compressors like LZ4HC, Zstd, and Deflate can potentially
# block flushes for too long, the default is to flush with a known fast
# compressor in those cases. Options are:
#
# none : Flush without compressing blocks but while still doing checksums.
# fast : Flush with a fast compressor. If the table is already using a
#fast compressor that compressor is used.
# table: Always flush with the same compressor that the table uses. This
#was the pre 4.0 behavior.
#
# flush_compression: fast
{code}
By default, "fast" compressor is LZ4, it will use that one.
So, by default, "fast" compressor is used for flushing (LZ4). Hence, if one
does "nodetool snapshot", it will do snapshots of all tables, user defined as
well as system tables and it is compressed with LZ4.
If one specifies a custom compressor to be used in newly introduced
"sstable_compression" field, two situations might happen:
1) the default compressor is not "fast" (check ICompressor.Uses and
ICompressor.recommendedUses()), that means that we need to fallback to a fast
compressor - it will default to LZ4
2) the default compressor is fast - so we are going to flush *system* tables
with a *custom, user-specified, ICompressor*.
I want to be sure that we are on the same page. While it makes sense to do it
like that - a user specified a custom compressor to use - that also means that
system tables will be compressed with that compressor as well. I want to be
sure everybody is OK with this.
was (Author: smiklosovic):
I want to highlight one not-so-obvious consequence of introducing this patch.
There is flush_compression property in cassandra.yaml doing this:
{code}
# Compression to apply to SSTables as they flush for compressed tables.
# Note that tables without compression enabled do not respect this flag.
#
# As high ratio compressors like LZ4HC, Zstd, and Deflate can potentially
# block flushes for too long, the default is to flush with a known fast
# compressor in those cases. Options are:
#
# none : Flush without compressing blocks but while still doing checksums.
# fast : Flush with a fast compressor. If the table is already using a
#fast compressor that compressor is used.
# table: Always flush with the same compressor that the table uses. This
#was the pre 4.0 behavior.
#
# flush_compression: fast
{code}
By default, "fast" compressor is LZ4, it will use that one.
So, by default, "fast" compressor is used for flushing (LZ4). Hence, if one
does "nodetool snapshot", it will do snapshots of all tables, user defined as
well as system tables and it is compressed with LZ4.
If one specifies a default compressor to be used in newly introduced
"sstable_compression" field, two situations might happen:
1) the default compressor is not "fast" (check ICompressor.Uses and
ICompressor.recommendedUses()), that means that we need to fallback to a fast
compressor - it will default to LZ4
2) the default compressor is fast - so we are going to flush *system* tables
with a *custom, user-specified, ICompressor*.
I want to be sure that we are on the same page. While it makes sense to do it
like that - a user specified a custom compressor to use - that also means that
system tables will be compressed with that compressor as well. I want to be
sure everybody is OK with this.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Addit
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744151#comment-17744151
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
I want to highlight one not-so-obvious consequence of introducing this patch.
There is flush_compression property in cassandra.yaml doing this:
{code}
# Compression to apply to SSTables as they flush for compressed tables.
# Note that tables without compression enabled do not respect this flag.
#
# As high ratio compressors like LZ4HC, Zstd, and Deflate can potentially
# block flushes for too long, the default is to flush with a known fast
# compressor in those cases. Options are:
#
# none : Flush without compressing blocks but while still doing checksums.
# fast : Flush with a fast compressor. If the table is already using a
#fast compressor that compressor is used.
# table: Always flush with the same compressor that the table uses. This
#was the pre 4.0 behavior.
#
# flush_compression: fast
{code}
By default, "fast" compressor is LZ4, it will use that one.
So, by default, "fast" compressor is used for flushing (LZ4). Hence, if one
does "nodetool snapshot", it will do snapshots of all tables, user defined as
well as system tables and it is compressed with LZ4.
If one specifies a default compressor to be used in newly introduced
"sstable_compression" field, two situations might happen:
1) the default compressor is not "fast" (check ICompressor.Uses and
ICompressor.recommendedUses()), that means that we need to fallback to a fast
compressor - it will default to LZ4
2) the default compressor is fast - so we are going to flush *system* tables
with a *custom, user-specified, ICompressor*.
I want to be sure that we are on the same page. While it makes sense to do it
like that - a user specified a custom compressor to use - that also means that
system tables will be compressed with that compressor as well. I want to be
sure everybody is OK with this.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-7-sai updated: Fix KeyRangeIntersectionIterator count
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch cep-7-sai
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-7-sai by this push:
new 21a30509b0 Fix KeyRangeIntersectionIterator count
21a30509b0 is described below
commit 21a30509b0ee95ce72c44c403f1b2804a0ade5af
Author: Jonathan Ellis
AuthorDate: Mon Jul 17 14:23:09 2023 +0200
Fix KeyRangeIntersectionIterator count
patch by Jonathan Ellis; reviewed by Andrés de la Peña
---
.../iterators/KeyRangeIntersectionIterator.java| 12 ++-
.../index/sai/iterators/KeyRangeIterator.java | 23 --
.../KeyRangeIntersectionIteratorTest.java | 6 +++---
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git
a/src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIntersectionIterator.java
b/src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIntersectionIterator.java
index f5bca7948b..63f273a2a5 100644
---
a/src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIntersectionIterator.java
+++
b/src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIntersectionIterator.java
@@ -249,6 +249,8 @@ public class KeyRangeIntersectionIterator extends
KeyRangeIterator
private static class IntersectionStatistics extends
KeyRangeIterator.Builder.Statistics
{
+private boolean empty = true;
+
@Override
public void update(KeyRangeIterator range)
{
@@ -256,7 +258,15 @@ public class KeyRangeIntersectionIterator extends
KeyRangeIterator
min = nullSafeMax(min, range.getMinimum());
// maximum of the intersection is the smallest maximum of
individual iterators
max = nullSafeMin(max, range.getMaximum());
-count += range.getCount();
+if (empty)
+{
+empty = false;
+count = range.getCount();
+}
+else
+{
+count = Math.min(count, range.getCount());
+}
}
}
diff --git
a/src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIterator.java
b/src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIterator.java
index f8bd38291b..84bf36bd59 100644
--- a/src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIterator.java
+++ b/src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIterator.java
@@ -18,10 +18,10 @@
package org.apache.cassandra.index.sai.iterators;
import java.io.Closeable;
-import java.util.List;
import com.google.common.annotations.VisibleForTesting;
import com.google.common.base.Preconditions;
+import com.google.common.collect.Iterables;
import org.apache.cassandra.index.sai.utils.PrimaryKey;
import org.apache.cassandra.utils.AbstractGuavaIterator;
@@ -29,6 +29,8 @@ import org.apache.cassandra.utils.AbstractGuavaIterator;
/**
* An abstract implementation of {@link AbstractGuavaIterator} that supports
the building and management of
* concatanation, union and intersection iterators.
+ *
+ * Only certain methods are designed to be overriden. The others are marked
private or final.
*/
public abstract class KeyRangeIterator extends
AbstractGuavaIterator implements Closeable
{
@@ -81,7 +83,8 @@ public abstract class KeyRangeIterator extends
AbstractGuavaIterator
*
* @param nextKey value to skip the iterator forward until matching
*
- * @return The next current key after the skip was performed
+ * @return The key skipped to, which will be the key returned by the
+ * next call to {@link #next()}, i.e., we are "peeking" at the next key as
part of the skip.
*/
public final PrimaryKey skipTo(PrimaryKey nextKey)
{
@@ -106,14 +109,22 @@ public abstract class KeyRangeIterator extends
AbstractGuavaIterator
return recomputeNext();
}
+/**
+ * Skip to nextKey.
+ *
+ * That is, implementations should set up the iterator state such that
+ * calling computeNext() will return nextKey if present,
+ * or the first one after it if not present.
+ */
protected abstract void performSkipTo(PrimaryKey nextKey);
-protected PrimaryKey recomputeNext()
+private PrimaryKey recomputeNext()
{
return tryToComputeNext() ? peek() : endOfData();
}
-protected boolean tryToComputeNext()
+@Override
+protected final boolean tryToComputeNext()
{
boolean hasNext = super.tryToComputeNext();
current = hasNext ? next : getMaximum();
@@ -159,9 +170,9 @@ public abstract class KeyRangeIterator extends
AbstractGuavaIterator
return statistics.count;
}
-public Builder add(List ranges)
+public Builder add(Iterable ranges)
{
-if (ranges == null || ranges.isEmpty())
+if (ranges == null || Iterables.isEmpty(ranges))
[jira] [Commented] (CASSANDRA-18658) Microbench tests fail on JDK11
[
https://issues.apache.org/jira/browse/CASSANDRA-18658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744143#comment-17744143
]
Marianne Lyne Manaog commented on CASSANDRA-18658:
--
Thank you [~e.dimitrova] and [~brandon.williams] :)
> Microbench tests fail on JDK11
> --
>
> Key: CASSANDRA-18658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18658
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Marianne Lyne Manaog
>Assignee: Marianne Lyne Manaog
>Priority: Normal
> Fix For: 4.0.12, 4.1.3, 5.0
>
> Attachments: jdk11-fail.png, jdk11-pass-cass-4.0.png,
> jdk11-pass-cass-4.1.png, jdk11-pass.png, jdk17-fail.png, jdk17-pass.png,
> jdk8-fail.png, jdk8-pass-cass-4.0.png, jdk8-pass-cass-4.1.png, jdk8-pass.png
>
>
> When I run
> {code:java}
> ant microbench -Dbenchmark.name=ReadWriteTest{code}
> using jdk8 on ds-trunk, it finishes successfully, but when I run it on jdk11
> on ds-trunk, I get this error.
> {code:java}
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@5189c629/invokeVirtual,
> from org.apache.cassandra.io.util.FileUtils (unnamed module @6cbf4322){code}
> We suspect that ant target does not use the jvmargs as other test targets do.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (a7bf85c4f3 -> 2584f4f070)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from a7bf85c4f3 Add jvm/test args to microbench add 2584f4f070 increment version to 4.0.12 No new revisions were added by this update. Summary of changes: CHANGES.txt | 7 ++- build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 13 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (7524ed5bfe -> 292e26842a)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 7524ed5bfe Merge branch 'cassandra-4.0' into cassandra-4.1 add 2584f4f070 increment version to 4.0.12 add 292e26842a Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (d6b305421a -> b2f08da641)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from d6b305421a Merge branch 'cassandra-4.1' into trunk add 2584f4f070 increment version to 4.0.12 add 292e26842a Merge branch 'cassandra-4.0' into cassandra-4.1 new b2f08da641 Merge branch 'cassandra-4.1' into trunk 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. Summary of changes: - 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-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b2f08da641ec30ddb316f876a34cda5340a1da23 Merge: d6b305421a 292e26842a Author: Stefan Miklosovic AuthorDate: Tue Jul 18 11:31:56 2023 +0200 Merge branch 'cassandra-4.1' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744135#comment-17744135 ] Jacek Lewandowski commented on CASSANDRA-17992: --- It seems that JVM upgrade tests are failing due to bouncy castle... investigating... > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18664) Move jflex from runtime to build dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18664: -- Fix Version/s: 4.0.12 (was: 4.0.11) > Move jflex from runtime to build dependencies > - > > Key: CASSANDRA-18664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18664 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.11.16, 4.0.12, 4.1.3, 5.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > JFlex depends on java-cup-runtime which has a kind of exotic license saying > that it is compatible with GPL. Therefore, we should investigate that case. > JFlex seems to be used only during the build to generate some sources for > SASI indexes. Therefore, it should be possible to move JFlex from the runtime > dependencies to the build dependencies and not include it in the distribution. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744129#comment-17744129 ] Amit Pawar commented on CASSANDRA-18464: [~mck], thanks for taking time to check this. The improvement discussed here also seen when Cassandra configured to run on say 4 to 8 cores too and my observations are listed below. # Seen 5-10% improvement in my test environment with 4-8 cores. TPCx-IOT is of type insert heavy and does range scanning. Basically, it mimics worst case scenario. # "PERIODIC-COMMIT-LOG-SYNCER" thread CPU utilization goes down and these saved cycles are available for other threads. # Any spike in insert operations can sustain for longer time due to Direct-IO and this benefits every user of Cassandra. This fix is good candidate for insert heavy type operations. So, I think it is better to push to 5.0 if possible else 5.1 is also fine. I totally understand and will agree/follow as per reviewer's feedback/suggestion, Thanks. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.x > > Attachments: CommitLogStressTest.patch, > EnableDirectIOForCommitLogUsingNativeAPI.patch, > PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch, > UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: com
[cassandra-website] branch asf-staging updated (54f3383b -> 3377e45e)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 54f3383b generate docs for 466d6ffe new 3377e45e generate docs for 466d6ffe This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (54f3383b) \ N -- N -- N refs/heads/asf-staging (3377e45e) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18659) Upgrade apache commons cli to 1.5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18659: Status: Ready to Commit (was: Review In Progress) > Upgrade apache commons cli to 1.5.0 > --- > > Key: CASSANDRA-18659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18659 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Timothy Tu >Assignee: Timothy Tu >Priority: Normal > Fix For: 5.x > > > Upgrade apache commons-cli from 1.1 (July 2007) to 1.5.0 (October 2021). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18659) Upgrade apache commons cli to 1.5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18659: Reviewers: Berenguer Blasi, Brandon Williams (was: Brandon Williams) Status: Review In Progress (was: Needs Committer) > Upgrade apache commons cli to 1.5.0 > --- > > Key: CASSANDRA-18659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18659 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Timothy Tu >Assignee: Timothy Tu >Priority: Normal > Fix For: 5.x > > > Upgrade apache commons-cli from 1.1 (July 2007) to 1.5.0 (October 2021). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18659) Upgrade apache commons cli to 1.5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744118#comment-17744118 ] Berenguer Blasi commented on CASSANDRA-18659: - Yeah guilty here for the tests for the detection of changed docs :-DDD Anyway it seems both CI runs make up for a green CI run. Also these tests can't be flaky as they only changed the checking of the output. +1 > Upgrade apache commons cli to 1.5.0 > --- > > Key: CASSANDRA-18659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18659 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Timothy Tu >Assignee: Timothy Tu >Priority: Normal > Fix For: 5.x > > > Upgrade apache commons-cli from 1.1 (July 2007) to 1.5.0 (October 2021). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744115#comment-17744115 ] Stefan Miklosovic edited comment on CASSANDRA-18624 at 7/18/23 8:50 AM: Yes, if we can not bundle both and somehow differentiate between them, we should bundle none. So this ticket transforms to a one which provides an infrastructure for hooking different crypto providers instead of setting up Corretto one as the default. The implementation for arch / x86 might probably exist as some 3rd party extension. This is all being said with the assumption we can not bundle both of them. was (Author: smiklosovic): Yes, if we can not bundle both and somehow differentiate between them, we should bundle none. So this ticket transforms to a one which provides an infrastructure for hooking different crypto providers instead of setting up Corretto one as the default. The implementation for arch / x86 might probably exists as some 3rd party extension. This is all being said with the assumption we can not bundle both of them. > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Ayushi Singh >Priority: Normal > Attachments: image.png > > Time Spent: 8h 20m > Remaining Estimate: 0h > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744115#comment-17744115 ] Stefan Miklosovic commented on CASSANDRA-18624: --- Yes, if we can not bundle both and somehow differentiate between them, we should bundle none. So this ticket transforms to a one which provides an infrastructure for hooking different crypto providers instead of setting up Corretto one as the default. The implementation for arch / x86 might probably exists as some 3rd party extension. This is all being said with the assumption we can not bundle both of them. > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Ayushi Singh >Priority: Normal > Attachments: image.png > > Time Spent: 8h 20m > Remaining Estimate: 0h > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744109#comment-17744109 ] Jacek Lewandowski commented on CASSANDRA-17992: --- The links in this comment https://issues.apache.org/jira/browse/CASSANDRA-17992?focusedCommentId=17743696&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17743696 are now valid > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744108#comment-17744108 ] Michael Semb Wever commented on CASSANDRA-18624: bq. Should not we default to in-built crypto provider instead and forcing a user to specifically enable this crypto provider if he is on x86? For the first release cycle i'm inclined to this approach. bq. Do we need to somehow differentiate or are we going to ship it for x86 only? Please no. Either we bundle with both arch deps, or neither. We cannot hardcode the architecture in the dependency's classifier. > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Ayushi Singh >Priority: Normal > Attachments: image.png > > Time Spent: 8h 20m > Remaining Estimate: 0h > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744107#comment-17744107 ] Berenguer Blasi commented on CASSANDRA-17992: - Have you got the link to this last run? > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744096#comment-17744096 ] Stefan Miklosovic edited comment on CASSANDRA-18624 at 7/18/23 8:22 AM: I made another round of the review, added bunch of comments again. I want to highlight that the patch introduces this dependency: https://github.com/apache/cassandra/pull/2490/files#r1266346053 There are two releases for this dependency, x86 and aarch. Here we depend on x86 only. What if a user is running Cassandra on ARM? How does this work in that case? Do we need to somehow differentiate or are we going to ship it for x86 only? Should not we default to in-built crypto provider instead and forcing a user to specifically enable this crypto provider if he is on x86? What I think should happen here is that there should be NoOpProvider which just does nothing so the default one in jvm is used and x86 jar in the distribution in libs and one has to explicitly turn it on. That way one avoids the situation when it is turned on by default and it is run on arm. If you want arm, you need to download that arm jar specifically, throw away x86 and configure it in yaml. was (Author: smiklosovic): I made another round of the review, added bunch of comments again. I want to highlight that the patch introduces this dependency: https://github.com/apache/cassandra/pull/2490/files#r1266346053 There are two releases for this dependency, x86 and aarch. Here we depend on x86 only. What if a user is running Cassandra on ARM? How does this work in that case? Do we need to somehow differentiate or are we going to ship it for x86 only? Should not we default to in-built crypto provider instead and forcing a user to specifically enable this crypto provider if he is on x86? What i think should happen here is that there should be NoOpProvider which just does nothing so the default one in jvm is used and x86 jar in the distribution in libs and one has to explicitly turn it on. That way one avoids the situation when it is turned on by default and it is run on arm. If you want arm, you need to download that arm jar specifically, throw away x86 and configure it in yaml. > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Ayushi Singh >Priority: Normal > Attachments: image.png > > Time Spent: 8h 20m > Remaining Estimate: 0h > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18624) Make Corretto Crypto Provider the Default
[ https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744096#comment-17744096 ] Stefan Miklosovic edited comment on CASSANDRA-18624 at 7/18/23 8:21 AM: I made another round of the review, added bunch of comments again. I want to highlight that the patch introduces this dependency: https://github.com/apache/cassandra/pull/2490/files#r1266346053 There are two releases for this dependency, x86 and aarch. Here we depend on x86 only. What if a user is running Cassandra on ARM? How does this work in that case? Do we need to somehow differentiate or are we going to ship it for x86 only? Should not we default to in-built crypto provider instead and forcing a user to specifically enable this crypto provider if he is on x86? What i think should happen here is that there should be NoOpProvider which just does nothing so the default one in jvm is used and x86 jar in the distribution in libs and one has to explicitly turn it on. That way one avoids the situation when it is turned on by default and it is run on arm. If you want arm, you need to download that arm jar specifically, throw away x86 and configure it in yaml. was (Author: smiklosovic): I made another round of the review, added bunch of comments again. I want to highlight that the patch introduces this dependency: https://github.com/apache/cassandra/pull/2490/files#r1266346053 There are two releases for this dependency, x86 and aarch. Here we depend on x86 only. What if a user is running Cassandra on ARM? How does this work in that case? Do we need to somehow differentiate or are we going to ship it for x86 only? Should not we default to in-built crypto provider instead and forcing a user to specifically enable this crypto provider if he is on x86? > Make Corretto Crypto Provider the Default > - > > Key: CASSANDRA-18624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18624 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Jordan West >Assignee: Ayushi Singh >Priority: Normal > Attachments: image.png > > Time Spent: 8h 20m > Remaining Estimate: 0h > > [Amazon Corretto Crypto Provider| > https://github.com/corretto/amazon-corretto-crypto-provider] is an > alternative provider of TLS and cryptographic functions that has significant > performance benefits for Cassandra. It is Apache 2.0 licensed and has been > deployed in several existing large fleets. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744103#comment-17744103 ] Jacek Lewandowski commented on CASSANDRA-17992: --- JVM Upgrade tests are passing on trunk so I need to figure out the problem on my branch > Upgrade Netty on 5.0 > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Jacek Lewandowski >Priority: Low > Fix For: 5.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > -We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. -->- CASSANDRA-18180 > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744102#comment-17744102 ] Michael Semb Wever commented on CASSANDRA-18464: [~amit_pawar], I suspect no one will have spare cycles to look into this for a few months. Must you have this in 5.0 (vs 5.1), and if so why? > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.x > > Attachments: CommitLogStressTest.patch, > EnableDirectIOForCommitLogUsingNativeAPI.patch, > PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch, > UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
