[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545278#comment-17545278
]
Berenguer Blasi commented on CASSANDRA-17667:
-
Just moved to in progress to reflect you're working on it #collaborating
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
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 (ddeb63d1 -> 250ad8c2)
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 ddeb63d1 generate docs for 700ff74c new 250ad8c2 generate docs for 700ff74c 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 (ddeb63d1) \ N -- N -- N refs/heads/asf-staging (250ad8c2) 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 4740078 -> 4740078 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-17305) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_parallel_upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545201#comment-17545201
]
Ekaterina Dimitrova commented on CASSANDRA-17305:
-
I couldn't reproduce it -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1683/workflows/52efff0a-60d1-43ac-8898-b0c1dd6cf70b/jobs/11800/steps]
Also, stable in Butler since we fixed our infra issues so I am closing the
ticket for now. The test just timeout a few times when we had issues with the
infra it seems. We will monitor and reopen in case something changes for
different reasons.
> Test Failure:
> dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_parallel_upgrade
> -
>
> Key: CASSANDRA-17305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17305
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Failed 2 times in the last 29 runs. Flakiness: 7%, Stability: 93%
> Error Message
> Failed: Timeout >900.0s
> {code}
> Stacktrace
> self =
> object at 0x7f19858d59d0>
> def test_parallel_upgrade(self):
> """
> Test upgrading cluster all at once (requires cluster downtime).
> """
> > self.upgrade_scenario()
> upgrade_tests/upgrade_through_versions_test.py:313:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:435: in upgrade_scenario
> cluster.stop()
> ../venv/lib/python3.8/site-packages/ccmlib/cluster.py:576: in stop
> if not node.stop(wait=wait, signal_event=signal_event, **kwargs):
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = , wait = True
> wait_other_notice = False, signal_event = , kwargs = {}
> still_running = True, wait_time_sec = 16, i = 4
> def stop(self, wait=True, wait_other_notice=False,
> signal_event=signal.SIGTERM, **kwargs):
> """
> Stop the node.
> - wait: if True (the default), wait for the Cassandra process
> to be
> really dead. Otherwise return after having sent the kill
> signal.
> - wait_other_notice: return only when the other live nodes of
> the
> cluster have marked this node has dead.
> - signal_event: Signal event to send to Cassandra; default is to
> let Cassandra clean up and shut down properly (SIGTERM [15])
> - Optional:
> + gently: Let Cassandra clean up and shut down properly;
> unless
>false perform a 'kill -9' which shuts down faster.
> """
> if self.is_running():
> if wait_other_notice:
> marks = [(node, node.mark_log()) for node in
> list(self.cluster.nodes.values()) if node.is_live() and node is not self]
>
> if common.is_win():
> # Just taskkill the instance, don't bother trying to shut it
> down gracefully.
> # Node recovery should prevent data loss from hard shutdown.
> # We have recurring issues with nodes not stopping /
> releasing files in the CI
> # environment so it makes more sense just to murder it hard
> since there's
> # really little downside.
>
> # We want the node to flush its data before shutdown as some
> tests rely on small writes being present.
> # The default Periodic sync at 10 ms may not have flushed
> data yet, causing tests to fail.
> # This is not a hard requirement, however, so we swallow any
> exceptions this may throw and kill anyway.
> if signal_event is signal.SIGTERM:
> try:
> self.flush()
> except:
> common.warning("Failed to flush node: {0} on
> shutdown.".format(self.name))
> pass
>
> os.system("taskkill /F /PID " + str(self.pid))
> if self._find_pid_on_windows():
> common.warning("Failed to terminate node: {0} with pid:
> {1}".format(self.name, self.pid))
> else:
> # Determine if the signal event should be updated to keep API
> compatibility
> if 'gently' in kwargs and kwargs['gently'] is False:
> signal_event = signal.SIGKILL
>
> os.kill(self.pid, signal_event)
>
[jira] [Updated] (CASSANDRA-17305) Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_parallel_upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17305:
Resolution: Cannot Reproduce
Status: Resolved (was: Open)
> Test Failure:
> dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_parallel_upgrade
> -
>
> Key: CASSANDRA-17305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17305
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Failed 2 times in the last 29 runs. Flakiness: 7%, Stability: 93%
> Error Message
> Failed: Timeout >900.0s
> {code}
> Stacktrace
> self =
> object at 0x7f19858d59d0>
> def test_parallel_upgrade(self):
> """
> Test upgrading cluster all at once (requires cluster downtime).
> """
> > self.upgrade_scenario()
> upgrade_tests/upgrade_through_versions_test.py:313:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:435: in upgrade_scenario
> cluster.stop()
> ../venv/lib/python3.8/site-packages/ccmlib/cluster.py:576: in stop
> if not node.stop(wait=wait, signal_event=signal_event, **kwargs):
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = , wait = True
> wait_other_notice = False, signal_event = , kwargs = {}
> still_running = True, wait_time_sec = 16, i = 4
> def stop(self, wait=True, wait_other_notice=False,
> signal_event=signal.SIGTERM, **kwargs):
> """
> Stop the node.
> - wait: if True (the default), wait for the Cassandra process
> to be
> really dead. Otherwise return after having sent the kill
> signal.
> - wait_other_notice: return only when the other live nodes of
> the
> cluster have marked this node has dead.
> - signal_event: Signal event to send to Cassandra; default is to
> let Cassandra clean up and shut down properly (SIGTERM [15])
> - Optional:
> + gently: Let Cassandra clean up and shut down properly;
> unless
>false perform a 'kill -9' which shuts down faster.
> """
> if self.is_running():
> if wait_other_notice:
> marks = [(node, node.mark_log()) for node in
> list(self.cluster.nodes.values()) if node.is_live() and node is not self]
>
> if common.is_win():
> # Just taskkill the instance, don't bother trying to shut it
> down gracefully.
> # Node recovery should prevent data loss from hard shutdown.
> # We have recurring issues with nodes not stopping /
> releasing files in the CI
> # environment so it makes more sense just to murder it hard
> since there's
> # really little downside.
>
> # We want the node to flush its data before shutdown as some
> tests rely on small writes being present.
> # The default Periodic sync at 10 ms may not have flushed
> data yet, causing tests to fail.
> # This is not a hard requirement, however, so we swallow any
> exceptions this may throw and kill anyway.
> if signal_event is signal.SIGTERM:
> try:
> self.flush()
> except:
> common.warning("Failed to flush node: {0} on
> shutdown.".format(self.name))
> pass
>
> os.system("taskkill /F /PID " + str(self.pid))
> if self._find_pid_on_windows():
> common.warning("Failed to terminate node: {0} with pid:
> {1}".format(self.name, self.pid))
> else:
> # Determine if the signal event should be updated to keep API
> compatibility
> if 'gently' in kwargs and kwargs['gently'] is False:
> signal_event = signal.SIGKILL
>
> os.kill(self.pid, signal_event)
>
> if wait_other_notice:
> for node, mark in marks:
> node.watch_log_for_death(self, from_mark=mark)
> else:
> time.sleep(.1)
>
> still_running = self.is_running()
> if still_running and wait:
> wait_time_sec = 1
> for i in xrange(0, 7):
> # we'll do
[jira] [Commented] (CASSANDRA-16391) Migrate dependency handling from maven-ant-tasks to resolver-ant-tasks
[
https://issues.apache.org/jira/browse/CASSANDRA-16391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545199#comment-17545199
]
Abe Ratnofsky commented on CASSANDRA-16391:
---
[~mck] is there a reason why we didn't fully remove Maven Ant Tasks? It's still
in use to create POMs, even though artifact resolution has been migrated to
Maven Artifact Resolver Ant Tasks as part of this ticket.
I'm asking because MAT is fully retired, not receiving security updates, and
has open CVEs in pinned dependency versions. I'm working on getting around this
by migrating completely to MARAT, but it's lacking a few features we currently
depend on in MAT. I'd love to just push a dependency update to MAT (update
plexus-utils2); do you know if there's an avenue for that within Apache?
> Migrate dependency handling from maven-ant-tasks to resolver-ant-tasks
> --
>
> Key: CASSANDRA-16391
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16391
> Project: Cassandra
> Issue Type: Task
> Components: Build, Dependencies
>Reporter: Michael Semb Wever
>Priority: High
> Fix For: 4.0-rc1, 4.0
>
>
> Cassandra resolves dependencies and generates maven pom files through the use
> of [maven-ant-tasks|http://maven.apache.org/ant-tasks/]. This is no longer a
> supported project.
> The recommended upgrade is to
> [resolver-ant-tasks|http://maven.apache.org/resolver-ant-tasks/]. It follows
> similar APIs so shouldn't be too impactful a change.
> The existing maven-ant-tasks has caused [some headaches
> already|https://issues.apache.org/jira/browse/CASSANDRA-16359] with internal
> super poms referencing insecure http:// central maven repository URLs that
> are no longer supported.
> We should also take the opportunity to
> - define the "test" scope (classpath) for those dependencies only used for
> tests (currently we are packaging test dependencies into the release binary
> artefact),
> - remove the jar files stored in the git repo under the "lib/" folder.
> These two above points have to happen in tandem, as the jar files under
> {{lib/}} are those that get bundled into the {{build/dist/lib/}} and hence
> the binary artefact. That is, all jar files under {{lib/}} are the project's
> "compile" scope, and all other dependencies defined in build.xml are either
> "provided" or "test" scope. These different scopes for dependencies are
> currently configured in different maven-ant-tasks poms. See
> https://github.com/apache/cassandra/commit/d43b9ce5092f8879a1a66afebab74d86e9e127fb#r45659668
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17634) Fix test: dtest-upgrade.upgrade_tests.drop_compact_storage_upgrade_test.TestDropCompactStorage.test_drop_compact_storage_mixed_cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-17634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545198#comment-17545198
]
Ekaterina Dimitrova commented on CASSANDRA-17634:
-
I didn't manage to reproduce this one in CircleCI -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1684/workflows/c07b84c2-071b-4974-9de8-f3baaf13b5eb.]
It seems flaky in Butler on 4.0, 4.1 and trunk. With that said I will test it
tomorrow whether it wasn't flaky when it was introduced for 4.0 but covered by
the recently fixed python dtest bug where tests were not marked failing even if
there are errors in some nodes logs.
If that is the case, this wouldn't be a beta blocker as it won't be a
regression. To be verified...
> Fix test:
> dtest-upgrade.upgrade_tests.drop_compact_storage_upgrade_test.TestDropCompactStorage.test_drop_compact_storage_mixed_cluster
> --
>
> Key: CASSANDRA-17634
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17634
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> From
> https://ci-cassandra.apache.org/job/Cassandra-4.1/24/testReport/dtest-upgrade.upgrade_tests.drop_compact_storage_upgrade_test/TestDropCompactStorage/test_drop_compact_storage_mixed_cluster/
> {noformat}
> Error Message
> test teardown failure
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [NonPeriodicTasks:1] 2022-05-18 11:36:18,780
> LogTransaction.java:398 - SSTableTidier ran with no existing data file for an
> sstable that was not new', [node2] 'ERROR [NonPeriodicTasks:1] 2022-05-18
> 11:36:18,788 LogTransaction.java:250 - Unable to delete
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-vk4cgziz/test/node2/data0/system_schema/columns-24101c25a2ae3af787c1b40ee1aca33f/nb_txn_upgradesstables_bbe470a4-d69e-11ec-8d33-579a578037c7.log
> as it does not exist, see debug log file for stack trace', [node2] 'ERROR
> [NonPeriodicTasks:1] 2022-05-18 11:36:18,821 LogTransaction.java:250 - Unable
> to delete
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-vk4cgziz/test/node2/data0/system_schema/columns-24101c25a2ae3af787c1b40ee1aca33f/nb_txn_upgradesstables_bbe4709a-d69e-11ec-8d33-579a578037c7.log
> as it does not exist, see debug log file for stack trace', [node2] 'ERROR
> [CompactionExecutor:1] 2022-05-18 11:36:29,589 JVMStabilityInspector.java:68
> - Exception in thread
> Thread[CompactionExecutor:1,5,CompactionExecutor]\njava.lang.NullPointerException:
> null\n\tat
> org.apache.cassandra.db.lifecycle.LogFile.makeRecord(LogFile.java:346)\n\tat
> org.apache.cassandra.db.lifecycle.LogFile.contains(LogFile.java:381)\n\tat
> org.apache.cassandra.db.lifecycle.LogTransaction.obsoleted(LogTransaction.java:183)\n\tat
>
> org.apache.cassandra.db.lifecycle.Helpers.prepareForObsoletion(Helpers.java:136)\n\tat
>
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.doPrepare(LifecycleTransaction.java:206)\n\tat
>
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:168)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:386)\n\tat
>
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:168)\n\tat
>
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:106)\n\tat
>
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:168)\n\tat
>
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:179)\n\tat
>
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:116)\n\tat
>
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:218)\n\tat
>
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)\n\tat
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)\n\tat
>
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)\n\tat
>
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:299)\n\tat
> org.apache.cassandra.concurrent.FutureTask$2.call(FutureTask.java:98)\n\tat
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)\n\tat
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)\n\tat
> java.util.concurrent.ThreadPoolExecut
[jira] [Updated] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-17677:
---
Test and Documentation Plan: PR available here:
https://github.com/apache/cassandra/pull/1658
Status: Patch Available (was: In Progress)
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17675) Revert the removal and deprecate withBufferSizeInMB(int size) in favor of the new withBufferSizeInMiB(int size)
[ https://issues.apache.org/jira/browse/CASSANDRA-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17675: Status: Needs Committer (was: Patch Available) > Revert the removal and deprecate withBufferSizeInMB(int size) in favor of the > new withBufferSizeInMiB(int size) > --- > > Key: CASSANDRA-17675 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17675 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > _withBufferSizeInMB(int size)_ was renamed in 4.1. > The right way to do it was to deprecate it and add the new one > _withBufferSizeInMiB(int size)_ > Add back _withBufferSizeInMB(int size)_ -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17584) Fix flaky test - org.apache.cassandra.db.virtual.GossipInfoTableTest.testSelectAllWithStateTransitions
[ https://issues.apache.org/jira/browse/CASSANDRA-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545185#comment-17545185 ] Ekaterina Dimitrova commented on CASSANDRA-17584: - I was not able to reproduce it in CircleCI - But it seems flaky in Butler in both 4.1 and trunk. It seems it was added end of March and ticket opened in April, so it might be test issue from the very beginning. I haven't compared the tests but I see that nodetool gossipinfo and this table should be providing the same info. The nodetool gossipinfo test is stable though. [~frankgh], [~yifanc], [~stefan.miklosovic], can anyone of you, please, take a look into this one? > Fix flaky test - > org.apache.cassandra.db.virtual.GossipInfoTableTest.testSelectAllWithStateTransitions > -- > > Key: CASSANDRA-17584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17584 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Tables >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.1-beta, 4.x > > > h3. Error Message > ['LOAD' is expected to be null] expected: but was: > h3. Stacktrace > junit.framework.AssertionFailedError: ['LOAD' is expected to be null] > expected: but was: at > org.apache.cassandra.db.virtual.GossipInfoTableTest.assertValue(GossipInfoTableTest.java:174) > at > org.apache.cassandra.db.virtual.GossipInfoTableTest.testSelectAllWithStateTransitions(GossipInfoTableTest.java:96) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17584) Fix flaky test - org.apache.cassandra.db.virtual.GossipInfoTableTest.testSelectAllWithStateTransitions
[ https://issues.apache.org/jira/browse/CASSANDRA-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545185#comment-17545185 ] Ekaterina Dimitrova edited comment on CASSANDRA-17584 at 6/1/22 10:43 PM: -- I was not able to reproduce it in CircleCI - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17584-4.1&filter=all But it seems flaky in Butler in both 4.1 and trunk. It seems it was added end of March and ticket opened in April, so it might be test issue from the very beginning. I haven't compared the tests but I see that nodetool gossipinfo and this table should be providing the same info. The nodetool gossipinfo test is stable though. [~frankgh], [~yifanc], [~stefan.miklosovic], can anyone of you, please, take a look into this one? was (Author: e.dimitrova): I was not able to reproduce it in CircleCI - But it seems flaky in Butler in both 4.1 and trunk. It seems it was added end of March and ticket opened in April, so it might be test issue from the very beginning. I haven't compared the tests but I see that nodetool gossipinfo and this table should be providing the same info. The nodetool gossipinfo test is stable though. [~frankgh], [~yifanc], [~stefan.miklosovic], can anyone of you, please, take a look into this one? > Fix flaky test - > org.apache.cassandra.db.virtual.GossipInfoTableTest.testSelectAllWithStateTransitions > -- > > Key: CASSANDRA-17584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17584 > Project: Cassandra > Issue Type: Bug > Components: Feature/Virtual Tables >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.1-beta, 4.x > > > h3. Error Message > ['LOAD' is expected to be null] expected: but was: > h3. Stacktrace > junit.framework.AssertionFailedError: ['LOAD' is expected to be null] > expected: but was: at > org.apache.cassandra.db.virtual.GossipInfoTableTest.assertValue(GossipInfoTableTest.java:174) > at > org.apache.cassandra.db.virtual.GossipInfoTableTest.testSelectAllWithStateTransitions(GossipInfoTableTest.java:96) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17618) Fix flaky org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545172#comment-17545172
]
Brandon Williams edited comment on CASSANDRA-17618 at 6/1/22 10:36 PM:
---
This looks like it was broken in CASSANDRA-17044.
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/508/workflows/59f6dfb4-4d12-4320-8312-7d42bbb3043c/jobs/5899]
are 500 runs on the commit just before it that succeed, and
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/509/workflows/612d851b-f163-4c0c-bfa7-1690d652c012/jobs/5900/parallel-runs/2?filterBy=ALL]
are 500 against it where there were 3 failures. [~jlewandowski] [~ifesdjeen]
can you take a look?
was (Author: brandon.williams):
This looks like is was broken in CASSANDRA-17044.
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/508/workflows/59f6dfb4-4d12-4320-8312-7d42bbb3043c/jobs/5899]
are 500 runs on the commit just before it that succeed, and
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/509/workflows/612d851b-f163-4c0c-bfa7-1690d652c012/jobs/5900/parallel-runs/2?filterBy=ALL]
are 500 against it where there were 3 failures. [~jlewandowski] [~ifesdjeen]
can you take a look?
> Fix flaky
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
> --
>
> Key: CASSANDRA-17618
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17618
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta
>
>
> The test is flaky on 4.1:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1604/workflows/243a20a5-eda2-4c28-95e8-ab6c4f85a891/jobs/10911
> {code:java}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest.lambda$testConnectionsAreRejectedWithInvalidConfig$81c80a4a$1(InternodeEncryptionEnforcementTest.java:91)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17663) Ensure FileStreamTask cannot compromise shared channel proxy for system table when interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542627#comment-17542627
]
Caleb Rackliffe edited comment on CASSANDRA-17663 at 6/1/22 10:06 PM:
--
Due to some complications w/ the new Simulator code, the 4.1/trunk patch
(outside the new test) is slightly different than 4.0. The basic idea is the
same though...get a preferred IP/connect-to address before control transfers to
a possibly interruptible thread.
|4.1|trunk|
|[patch|https://github.com/apache/cassandra/pull/1648]|[patch|https://github.com/apache/cassandra/pull/1649]|
|[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17663-4.1&filter=all]|[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17663-trunk&filter=all]|
CC [~benedict]
was (Author: maedhroz):
Due to some complications w/ the new Simulator code, the 4.1/trunk patch
(outside the new test) is slightly different than 4.0. The basic idea is the
same though...get a preferred IP/connect-to address before control transfers to
a possibly interruptible thread.
|4.0|trunk|
|[patch|https://github.com/apache/cassandra/pull/1648]|[patch|https://github.com/apache/cassandra/pull/1649]|
|[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17663-4.1&filter=all]|[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17663-trunk&filter=all]|
CC [~benedict]
> Ensure FileStreamTask cannot compromise shared channel proxy for system table
> when interrupted
> --
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
>
[jira] [Commented] (CASSANDRA-17663) Ensure FileStreamTask cannot compromise shared channel proxy for system table when interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545173#comment-17545173
]
Caleb Rackliffe commented on CASSANDRA-17663:
-
Thanks to [~jonmeredith] and [~dcapwell] for the reviews.
At this point, all I'm waiting for is a final round of testing for the 3
branches...
> Ensure FileStreamTask cannot compromise shared channel proxy for system table
> when interrupted
> --
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> {noformat}
> ...and...
> {noformat}
> ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[CompactionExecutor:12,1,main]
> org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.seekToCurrentRangeStart(BigTableScanner.java:196)
>
> at
> org.apache.cassandra.io.sstable.f
[jira] [Commented] (CASSANDRA-17618) Fix flaky org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545172#comment-17545172
]
Brandon Williams commented on CASSANDRA-17618:
--
This looks like is was broken in CASSANDRA-17044.
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/508/workflows/59f6dfb4-4d12-4320-8312-7d42bbb3043c/jobs/5899]
are 500 runs on the commit just before it that succeed, and
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/509/workflows/612d851b-f163-4c0c-bfa7-1690d652c012/jobs/5900/parallel-runs/2?filterBy=ALL]
are 500 against it where there were 3 failures. [~jlewandowski] [~ifesdjeen]
can you take a look?
> Fix flaky
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
> --
>
> Key: CASSANDRA-17618
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17618
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta
>
>
> The test is flaky on 4.1:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1604/workflows/243a20a5-eda2-4c28-95e8-ab6c4f85a891/jobs/10911
> {code:java}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest.lambda$testConnectionsAreRejectedWithInvalidConfig$81c80a4a$1(InternodeEncryptionEnforcementTest.java:91)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17656) jvm-dtest upgrade tests run all supported pairs of upgrades between from/to but does not actually test all patches from/to
[
https://issues.apache.org/jira/browse/CASSANDRA-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545164#comment-17545164
]
David Capwell commented on CASSANDRA-17656:
---
think we came to agreement!!! upgrades method now does the following
{code}
upgradesTo(from, CURRENT);
upgradesFrom(CURRENT, to);
{code}
and added the 2 new methods upgradesTo (upgrade all paths where from changes
but to is fixed) and upgradesFrom (upgrade all paths where too changes but from
is fixed); this allows test authors to switch back to older logic if desired,
but keeps the default focused on CURRENT
> jvm-dtest upgrade tests run all supported pairs of upgrades between from/to
> but does not actually test all patches from/to
> --
>
> Key: CASSANDRA-17656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17656
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> The current upgrade from/to logic is based off a list filter on from/to
> pairs, and runs the test multiple times for each pair; this does not actually
> validate that the different paths upgrade cleanly.
> Instead, we need to test each supported path; example 3.0 -> 4.2
> {code}
> 3.0.28 -> [4.2]
> 3.0.28 -> [3.11.14, 4.2]
> 3.0.28 -> [4.1-alpha1, 4.2]
> 3.0.28 -> [4.0.5, 4.2]
> 3.0.28 -> [3.11.14, 4.1-alpha1, 4.2]
> 3.0.28 -> [3.11.14, 4.0.5, 4.2]
> 3.0.28 -> [4.0.5, 4.1-alpha1, 4.2]
> 3.0.28 -> [3.11.14, 4.0.5, 4.1-alpha1, 4.2]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17643) Add utests_system_keyspace_directory to pre-commit tests workflow in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545130#comment-17545130 ] Ekaterina Dimitrova commented on CASSANDRA-17643: - Well, didn't manage to reproduce also with mid resources. I feel it might be something temporary. [~jmckenzie], from your experience with that area, do you think I should open a ticket or we can monitor for some time if it repeats again? > Add utests_system_keyspace_directory to pre-commit tests workflow in CircleCI > -- > > Key: CASSANDRA-17643 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17643 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: High > Fix For: 4.0.5, 4.1-beta > > > utests_system_keyspace_directory tests get broken every now and then but we > don't have them added in Jenkins and they are not mandatory pre-commit in > CircleCI. > A quick first step to have a better monitoring on those is to add them at > least being mandatory ran before a commit in CircleCI -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17669) CentOS/RHEL installation requires JRE not available in Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-17669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17669:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> CentOS/RHEL installation requires JRE not available in Java 11
> --
>
> Key: CASSANDRA-17669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17669
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> h2. Background
> A user [reported on Stack
> Overflow|https://stackoverflow.com/questions/72377621/] and the DataStax
> Developers [dtsx.io/discord|https://dtsx.io/discord] an issue with installing
> Cassandra when only Java 11 is installed.
> h2. Symptoms
> Attempts to install Cassandra using YUM requires Java 8:
> {noformat}
> $ sudo yum install cassandra
> Dependencies resolved.
>
> Package Architecture
> Version Repository
> Size
>
> Installing:
> cassandranoarch
> 4.0.4-1 cassandra
> 45 M
> Installing dependencies:
> java-1.8.0-openjdk x86_64
> 1:1.8.0.312.b07-2.el8_5 appstream
> 341 k
> java-1.8.0-openjdk-headless x86_64
> 1:1.8.0.312.b07-2.el8_5 appstream
> 34 M
> Installing weak dependencies:
> gtk2 x86_64
> 2.24.32-5.el8appstream
> 3.4 M
> Transaction Summary
>
> Install 4 Packages
> {noformat}
> Similarly, attempts to install the RPM results in:
> {noformat}
> $ sudo rpm -i cassandra-4.0.4-1.noarch.rpm
> warning: cassandra-4.0.4-1.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID
> 7e3e87cb: NOKEY
> error: Failed dependencies:
> jre >= 1.8.0 is needed by cassandra-4.0.4-1.noarch{noformat}
> h2. Root cause
> Package installs on CentOS and RHEL platforms has [a dependency on JRE
> 1.8+|https://github.com/apache/cassandra/blob/trunk/redhat/cassandra.spec#L49]:
> {noformat}
> Requires: jre >= 1.8.0{noformat}
> However, JRE is no longer available in Java 11. From the [JDK 11 release
> notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html]:
> {quote}In this release, the JRE or Server JRE is no longer offered. Only the
> JDK is offered.
> {quote}
> h2. Workaround
> Override the dependency check when installing the RPM with the {{--nodeps}}
> option:
> {noformat}
> $ sudo rpm --nodeps -i cassandra-4.0.4-1.noarch.rpm {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17669) CentOS/RHEL installation requires JRE not available in Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-17669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545128#comment-17545128
]
Brandon Williams edited comment on CASSANDRA-17669 at 6/1/22 8:24 PM:
--
Debian conventions remain the same, I only added the j11 equivalents. For
redhat it looks like 'jre-11' is provided, so I went with that and installing
the package Just Worked when I had java 11 installed, but would prefer to try
and install 1.8 if nothing was present already. I think this probably works
for the best.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-4.0]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1747/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1747/pipeline]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-4.1]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1748/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1748/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1749/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1749/pipeline]|
was (Author: brandon.williams):
Debian conventions remain the same, I only added the j11 equivalents. For
redhat it looks like 'jre-11' is provided, so I went with that and installing
the package Just Worked when I had java 11 installed, but would prefer to try
and install 1.8 if nothing was present already. I think this probably works
for the best.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-4.0]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1747/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1747/pipeline]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-4.1]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1748/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1748/pipeline]|
[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1749/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1749/pipeline]|
> CentOS/RHEL installation requires JRE not available in Java 11
> --
>
> Key: CASSANDRA-17669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17669
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> h2. Background
> A user [reported on Stack
> Overflow|https://stackoverflow.com/questions/72377621/] and the DataStax
> Developers [dtsx.io/discord|https://dtsx.io/discord] an issue with installing
> Cassandra when only Java 11 is installed.
> h2. Symptoms
> Attempts to install Cassandra using YUM requires Java 8:
> {noformat}
> $ sudo yum install cassandra
> Dependencies resolved.
>
> Package Architecture
> Version Repository
> Size
>
> Installing:
> cassandranoarch
> 4.0.4-1 cassandra
> 45 M
> Installing dependencies:
> java-1.8.0-openjdk x86_64
> 1:1.8.0.312.b07-2.el8_5 appstream
> 341 k
> java-1.8.0-openjdk-headless x86_64
> 1:1.8.0.312.b07-2.el8_5 appstream
> 34 M
> Installing weak dependencies:
> gtk2 x86_64
> 2.24.32-5.el8appstream
> 3.4 M
> Transaction Summary
>
> Install 4 Packages
> {noformat}
> Si
[jira] [Commented] (CASSANDRA-17669) CentOS/RHEL installation requires JRE not available in Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-17669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545128#comment-17545128
]
Brandon Williams commented on CASSANDRA-17669:
--
Debian conventions remain the same, I only added the j11 equivalents. For
redhat it looks like 'jre-11' is provided, so I went with that and installing
the package Just Worked when I had java 11 installed, but would prefer to try
and install 1.8 if nothing was present already. I think this probably works
for the best.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-4.0]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1747/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1747/pipeline]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-4.1]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1748/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1748/pipeline]|
[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17699-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1749/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1749/pipeline]|
> CentOS/RHEL installation requires JRE not available in Java 11
> --
>
> Key: CASSANDRA-17669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17669
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> h2. Background
> A user [reported on Stack
> Overflow|https://stackoverflow.com/questions/72377621/] and the DataStax
> Developers [dtsx.io/discord|https://dtsx.io/discord] an issue with installing
> Cassandra when only Java 11 is installed.
> h2. Symptoms
> Attempts to install Cassandra using YUM requires Java 8:
> {noformat}
> $ sudo yum install cassandra
> Dependencies resolved.
>
> Package Architecture
> Version Repository
> Size
>
> Installing:
> cassandranoarch
> 4.0.4-1 cassandra
> 45 M
> Installing dependencies:
> java-1.8.0-openjdk x86_64
> 1:1.8.0.312.b07-2.el8_5 appstream
> 341 k
> java-1.8.0-openjdk-headless x86_64
> 1:1.8.0.312.b07-2.el8_5 appstream
> 34 M
> Installing weak dependencies:
> gtk2 x86_64
> 2.24.32-5.el8appstream
> 3.4 M
> Transaction Summary
>
> Install 4 Packages
> {noformat}
> Similarly, attempts to install the RPM results in:
> {noformat}
> $ sudo rpm -i cassandra-4.0.4-1.noarch.rpm
> warning: cassandra-4.0.4-1.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID
> 7e3e87cb: NOKEY
> error: Failed dependencies:
> jre >= 1.8.0 is needed by cassandra-4.0.4-1.noarch{noformat}
> h2. Root cause
> Package installs on CentOS and RHEL platforms has [a dependency on JRE
> 1.8+|https://github.com/apache/cassandra/blob/trunk/redhat/cassandra.spec#L49]:
> {noformat}
> Requires: jre >= 1.8.0{noformat}
> However, JRE is no longer available in Java 11. From the [JDK 11 release
> notes|https://www.oracle.com/java/technologies/javase/11-relnote-issues.html]:
> {quote}In this release, the JRE or Server JRE is no longer offered. Only the
> JDK is offered.
> {quote}
> h2. Workaround
> Override the dependency check when installing the RPM with the {{--nodeps}}
> option:
> {noformat}
> $ sudo rpm --nodeps -i cassandra-4.0.4-1.noarch.rpm {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...
[jira] [Commented] (CASSANDRA-17609) Fix org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams-cdc (from org.apache.cassandra.db.compaction.CompactionsCQLTest-cdc)
[
https://issues.apache.org/jira/browse/CASSANDRA-17609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545079#comment-17545079
]
Brandon Williams commented on CASSANDRA-17609:
--
It looks like we also need to run this against 4.1.
> Fix
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams-cdc
> (from org.apache.cassandra.db.compaction.CompactionsCQLTest-cdc)
> -
>
> Key: CASSANDRA-17609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17609
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta
>
>
> {color:#172b4d}[https://ci-cassandra.apache.org/job/Cassandra-4.1/5/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testLCSThresholdParams_cdc_2/]{color}
> h3.
> {code:java}
> Error Message
> expected:<50> but was:<51>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<50> but was:<51> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams(CompactionsCQLTest.java:419)
> 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)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17609) Fix org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams-cdc (from org.apache.cassandra.db.compaction.CompactionsCQLTest-cdc)
[
https://issues.apache.org/jira/browse/CASSANDRA-17609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17609:
-
Reviewers: Brandon Williams, Brandon Williams
Brandon Williams, Brandon Williams (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
Nice job! This makes perfect sense and CI looks good, +1.
> Fix
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams-cdc
> (from org.apache.cassandra.db.compaction.CompactionsCQLTest-cdc)
> -
>
> Key: CASSANDRA-17609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17609
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta
>
>
> {color:#172b4d}[https://ci-cassandra.apache.org/job/Cassandra-4.1/5/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testLCSThresholdParams_cdc_2/]{color}
> h3.
> {code:java}
> Error Message
> expected:<50> but was:<51>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<50> but was:<51> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams(CompactionsCQLTest.java:419)
> 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)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17594) Fix flaky python-tests due to connection getting closed
[
https://issues.apache.org/jira/browse/CASSANDRA-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17594:
--
Status: Ready to Commit (was: Review In Progress)
> Fix flaky python-tests due to connection getting closed
> ---
>
> Key: CASSANDRA-17594
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17594
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We log unknown exceptions at the networking level, which includes case where
> the remote side closes the connection (such as the cases caused by shutting
> down), depending on how quickly the instances shutdown, this could cause
> python-dtest to fail for random tests with a message such as
> {code}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [WARN [epollEventLoopGroup-5-9] 2022-05-03T16:47:03,800
> ExceptionHandlers.java:134 - Unknown exception in client networking
> io.netty.channel.unix.Errors$NativeIoException: writeAddress(..) failed:
> Connection reset by peer, WARN [epollEventLoopGroup-5-9]
> 2022-05-03T16:47:03,800 ExceptionHandlers.java:134 - Unknown exception in
> client networking
> io.netty.channel.unix.Errors$NativeIoException: writeAddress(..) failed:
> Connection reset by peer]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17594) Fix flaky python-tests due to connection getting closed
[
https://issues.apache.org/jira/browse/CASSANDRA-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17594:
--
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
latest commit
{code}
commit 7bc8467233af69391efeaf74ef87a73c0ea9ceb1 (HEAD -> trunk, upstream/trunk)
Author: David Capwell
Date: Wed Jun 1 10:57:09 2022 -0700
Fix flaky python-tests due to connection getting closed
Patch by David Capwell; reviewed by Caleb Rackliffe for CASSANDRA-17594
{code}
> Fix flaky python-tests due to connection getting closed
> ---
>
> Key: CASSANDRA-17594
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17594
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We log unknown exceptions at the networking level, which includes case where
> the remote side closes the connection (such as the cases caused by shutting
> down), depending on how quickly the instances shutdown, this could cause
> python-dtest to fail for random tests with a message such as
> {code}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [WARN [epollEventLoopGroup-5-9] 2022-05-03T16:47:03,800
> ExceptionHandlers.java:134 - Unknown exception in client networking
> io.netty.channel.unix.Errors$NativeIoException: writeAddress(..) failed:
> Connection reset by peer, WARN [epollEventLoopGroup-5-9]
> 2022-05-03T16:47:03,800 ExceptionHandlers.java:134 - Unknown exception in
> client networking
> io.netty.channel.unix.Errors$NativeIoException: writeAddress(..) failed:
> Connection reset by peer]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Fix flaky python-tests due to connection getting closed Patch by David Capwell; reviewed by Caleb Rackliffe for CASSANDRA-17594
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 7bc84672 Fix flaky python-tests due to connection getting closed Patch
by David Capwell; reviewed by Caleb Rackliffe for CASSANDRA-17594
7bc84672 is described below
commit 7bc8467233af69391efeaf74ef87a73c0ea9ceb1
Author: David Capwell
AuthorDate: Wed Jun 1 10:57:09 2022 -0700
Fix flaky python-tests due to connection getting closed
Patch by David Capwell; reviewed by Caleb Rackliffe for CASSANDRA-17594
---
dtest_setup.py | 9 -
hintedhandoff_test.py | 3 +++
materialized_views_test.py | 2 ++
repair_tests/deprecated_repair_test.py | 14 ++
4 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/dtest_setup.py b/dtest_setup.py
index 6a396b8e..50509e66 100644
--- a/dtest_setup.py
+++ b/dtest_setup.py
@@ -47,7 +47,14 @@ def retry_till_success(fun, *args, **kwargs):
def default_ignore_log_patterns():
# to allow tests to append to the list, make sure to create a new list as
the output
# to this function, else multiple tests could corrupt the default set
-return ['.*\[epollEventLoopGroup-.*\].*- Unknown exception in client
networking.*: Connection reset by peer']
+return ['failed: Connection reset by peer',
+r'Invalid or unsupported protocol version \(5\)',
+# See python-driver, SHA a7295e103023e12152fc0940906071b18356def3
+# cassandra/__init__.py
+r'Invalid or unsupported protocol version \(65\)', # DSE_V1
+r'Invalid or unsupported protocol version \(66\)', # DSE_V2
+'Beta version of the protocol used',
+]
class DTestSetup(object):
diff --git a/hintedhandoff_test.py b/hintedhandoff_test.py
index 65be1830..5f127661 100644
--- a/hintedhandoff_test.py
+++ b/hintedhandoff_test.py
@@ -182,6 +182,9 @@ class TestHintedHandoff(Tester):
@ported_to_in_jvm('4.0')
@pytest.mark.no_vnodes
def test_hintedhandoff_decom(self):
+self.fixture_dtest_setup.ignore_log_patterns = [
+'Could not update repaired ranges.*Giving up'
+]
self.cluster.populate(4).start()
[node1, node2, node3, node4] = self.cluster.nodelist()
session = self.patient_cql_connection(node1)
diff --git a/materialized_views_test.py b/materialized_views_test.py
index 438dbd70..6f547881 100644
--- a/materialized_views_test.py
+++ b/materialized_views_test.py
@@ -342,6 +342,7 @@ class TestMaterializedViews(Tester):
session = self.prepare(consistency_level=ConsistencyLevel.QUORUM)
session.execute("CREATE TABLE t (id int, v int, PRIMARY KEY (id, v))")
+session.cluster.control_connection.wait_for_schema_agreement()
for i in range(5):
for j in range(1):
@@ -349,6 +350,7 @@ class TestMaterializedViews(Tester):
session.execute(("CREATE MATERIALIZED VIEW t_by_v AS SELECT * FROM t
WHERE v IS NOT NULL "
"AND id IS NOT NULL PRIMARY KEY (v, id)"))
+session.cluster.control_connection.wait_for_schema_agreement()
logger.debug("wait for view to build")
self._wait_for_view("ks", "t_by_v")
diff --git a/repair_tests/deprecated_repair_test.py
b/repair_tests/deprecated_repair_test.py
index 958fee4d..75c770e4 100644
--- a/repair_tests/deprecated_repair_test.py
+++ b/repair_tests/deprecated_repair_test.py
@@ -85,6 +85,13 @@ class TestDeprecatedRepairAPI(Tester):
Collection hosts, boolean
fullRepair,
String... columnFamilies)
"""
+# when giving token ranges, there needs to be logic to make sure we
have partitions for
+# those tokens... which self._deprecated_repair_jmx does not do... for
this reason most
+# runs will not actually trigger repair and will abort (we check
logging, which will happen
+# still).
+self.fixture_dtest_setup.ignore_log_patterns = [
+'Nothing to repair for'
+]
opt =
self._deprecated_repair_jmx("forceRepairRangeAsync(java.lang.String,java.lang.String,java.lang.String,boolean,java.util.Collection,java.util.Collection,boolean,[Ljava.lang.String;)",
["0", "1000", "ks", True, ["dc1"],
[], False, ["cf"]])
assert opt["parallelism"], "parallel" if is_win() else "sequential" ==
opt
@@ -122,6 +129,13 @@ class TestDeprecatedRepairAPI(Tester):
boolean isLocal, boolean fullRepair,
String... columnFamilies)
"""
+# when giving token ranges, there needs to be logic to make sure we
have partitions for
+# those tokens... which self._depr
[jira] [Assigned] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero reassigned CASSANDRA-17677:
--
Assignee: Francisco Guerrero
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17676) When a node is bootstrapping it gets the whole gossip state but applies in random order causing some cases where StorageService will fail causing an instance to not
[ https://issues.apache.org/jira/browse/CASSANDRA-17676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17676: -- Fix Version/s: 4.2 (was: 4.x) Since Version: 2.0.0 Source Control Link: https://github.com/apache/cassandra/commit/2dcf7d221672ce5ca15dbeb666a8fedb7ec805ff Resolution: Fixed Status: Resolved (was: Ready to Commit) > When a node is bootstrapping it gets the whole gossip state but applies in > random order causing some cases where StorageService will fail causing an > instance to not show up in TokenMetadata > - > > Key: CASSANDRA-17676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17676 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.2 > > > When gossip state has a causal relationship, the order the state gets applied > needs to match this relationship, and when it doesn’t it can cause bootstrap > (which apply the whole state in an empty state) to see missing data or > instances -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: When a node is bootstrapping it gets the whole gossip state but applies in random order causing some cases where StorageService will fail causing an instance to not s
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 740cec41d2 When a node is bootstrapping it gets the whole gossip state
but applies in random order causing some cases where StorageService will fail
causing an instance to not show up in TokenMetadata
740cec41d2 is described below
commit 740cec41d2d67783a463bd18f70221de331928df
Author: David Capwell
AuthorDate: Wed Jun 1 08:49:44 2022 -0700
When a node is bootstrapping it gets the whole gossip state but applies in
random order causing some cases where StorageService will fail causing an
instance to not show up in TokenMetadata
patch by David Capwell; reviewed by Blake Eggleston for CASSANDRA-17676
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/gms/Gossiper.java| 46 +-
.../org/apache/cassandra/gms/VersionedValue.java | 3 ++
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index fb75bc510d..30dfdf763c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * When a node is bootstrapping it gets the whole gossip state but applies in
random order causing some cases where StorageService will fail causing an
instance to not show up in TokenMetadata (CASSANDRA-17676)
* Add CQLSH command SHOW REPLICAS (CASSANDRA-17577)
* Add guardrail to allow disabling of SimpleStrategy (CASSANDRA-17647)
* Change default directory permission to 750 in packaging (CASSANDRA-17470)
diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java
b/src/java/org/apache/cassandra/gms/Gossiper.java
index 4c72166a9d..8041eed034 100644
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@ -85,6 +85,7 @@ import static org.apache.cassandra.net.Verb.GOSSIP_DIGEST_SYN;
import static
org.apache.cassandra.utils.FBUtilities.getBroadcastAddressAndPort;
import static org.apache.cassandra.utils.Clock.Global.currentTimeMillis;
import static org.apache.cassandra.utils.Clock.Global.nanoTime;
+import static org.apache.cassandra.gms.VersionedValue.BOOTSTRAPPING_STATUS;
/**
* This module is responsible for Gossiping information for the local
endpoint. This abstraction
@@ -1500,11 +1501,54 @@ public class Gossiper implements
IFailureDetectionEventListener, GossiperMBean
return pieces[0];
}
+/**
+ * Gossip offers no happens-before relationship, but downstream
subscribers assume a happens-before relationship
+ * before being notified! To attempt to be nicer to subscribers, this
{@link Comparator} attempts to order EndpointState
+ * within a map based off a few heuristics:
+ *
+ * STATUS - some STATUS depends on other instance STATUS, so make
sure they are last; eg. BOOT, and BOOT_REPLACE
+ * generation - normally defined as system clock millis, this can
be skewed and is a best effort
+ * address - tie breaker to make sure order is consistent
+ *
+ *
+ * Problems:
+ * Generation is normally defined as system clock millis, which can be
skewed and in-consistent cross nodes
+ * (generations do not have a happens-before relationship, so ordering is
sketchy at best).
+ *
+ * Motivations:
+ * {@link Map#entrySet()} returns data in effectivlly random order, so can
get into a situation such as the following example.
+ * {@code
+ * 3 node cluster: n1, n2, and n3
+ * n2 goes down and n4 does host replacement and fails before completion
+ * h5 tries to do a host replacement against n4 (ignore the fact this
doesn't make sense)
+ * }
+ * In that case above, the {@link Map#entrySet()} ordering can be random,
causing h4 to apply before h2, which will
+ * be rejected by subscripers (only after updating gossip causing zero
retries).
+ */
+private static Comparator>
STATE_MAP_ORDERING =
+((Comparator>) (e1, e2) -> {
+// check status first, make sure bootstrap status happens-after all
others
+if (BOOTSTRAPPING_STATUS.contains(getGossipStatus(e1.getValue(
+return 1;
+if (BOOTSTRAPPING_STATUS.contains(getGossipStatus(e2.getValue(
+return -1;
+return 0;
+})
+.thenComparingInt((Entry e) ->
e.getValue().getHeartBeatState().getGeneration())
+.thenComparing(Entry::getKey);
+
+private static Iterable>
order(Map epStateMap)
+{
+List> list = new
ArrayList<>(epStateMap.entrySet());
+Collections.sort(list, STATE_MAP_ORDERING);
+return list;
+}
+
@VisibleForTesting
public void applyStateLocally(Map
epStateMap)
{
checkProperThreadForStateMutation();
-for (Entry entry :
epStateMap.entrySet())
+for (Entry entry :
order(epStateM
[jira] [Updated] (CASSANDRA-17609) Fix org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams-cdc (from org.apache.cassandra.db.compaction.CompactionsCQLTest-cdc)
[
https://issues.apache.org/jira/browse/CASSANDRA-17609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17609:
--
Test and Documentation Plan: Repeated runs of the affected test suite are
included.
Status: Patch Available (was: In Progress)
> Fix
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams-cdc
> (from org.apache.cassandra.db.compaction.CompactionsCQLTest-cdc)
> -
>
> Key: CASSANDRA-17609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17609
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta
>
>
> {color:#172b4d}[https://ci-cassandra.apache.org/job/Cassandra-4.1/5/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testLCSThresholdParams_cdc_2/]{color}
> h3.
> {code:java}
> Error Message
> expected:<50> but was:<51>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<50> but was:<51> at
> org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams(CompactionsCQLTest.java:419)
> 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)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17609) Fix org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams-cdc (from org.apache.cassandra.db.compaction.CompactionsCQLTest-cdc)
[
https://issues.apache.org/jira/browse/CASSANDRA-17609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545060#comment-17545060
]
Andres de la Peña commented on CASSANDRA-17609:
---
The test can also fail without CDC, also with a pretty low flakiness, as it is
shown by [this repeated
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1641/workflows/7dd9bb59-3e8f-4889-ab84-bcfe4aca6297].
As a clue, the test passes when running isolated from the rest of the tests on
{{{}CompactionsCQLTest{}}}. This is shown by [this other
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1637/workflows/287964de-8ab3-4c84-8c03-bdc87fd8858e].
So it seems that the problem is due to the interaction with the other tests.
If we dig into the logs we can find the messages informing about the 50 flushes
requested by the test. Thanks to the changes recently introduced by
CASSANDRA-17034, those flushes have a "reason" property that is included in the
the log message. The reason for the 50 flushes explicitly requested by the test
is {{{}UNIT_TESTS{}}}. However, the logs for the failed runs contain an
additional flush with {{COMMITLOG_DIRTY}} as the reason. Also, those flushes
seem to appear among messages generated by the asynchronous {{CQLTester}} task
that cleans up the data of the previous tests:
{code:java}
...
[junit-timeout] INFO [OptionalTasks:1] 2022-05-30 16:05:45,164
ColumnFamilyStore.java:1010 - Enqueuing flush of cql_test_keyspace.table_07,
Reason: COMMITLOG_DIRTY, Usage: 0.745KiB (0%) on-heap, 400.133KiB (0%) off-heap
[junit-timeout] INFO [OptionalTasks:1] 2022-05-30 16:05:45,165
ColumnFamilyStore.java:1010 - Enqueuing flush of system.local, Reason:
COMMITLOG_DIRTY, Usage: 0.370KiB (0%) on-heap, 0.289KiB (0%) off-heap
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,166
LogTransaction.java:242 - Unfinished transaction log, deleting
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big-Data.db
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,166
SSTable.java:127 - Deleting sstable:
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,166
PathUtils.java:74 - Deleting file during startup:
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big-Index.db
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,166
PathUtils.java:74 - Deleting file during startup:
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big-CompressionInfo.db
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,166
PathUtils.java:74 - Deleting file during startup:
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big-Statistics.db
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,167
PathUtils.java:74 - Deleting file during startup:
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big-Digest.crc32
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,167
PathUtils.java:74 - Deleting file during startup:
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big-Filter.db
[junit-timeout] INFO [PerDiskMemtableFlushWriter_0:1] 2022-05-30 16:05:45,167
Flushing.java:145 - Writing Memtable-sstable_activity@215544135(0.422KiB
serialized bytes, 54 ops, 13.236KiB (0%) on-heap, 2.008KiB (0%) off-heap),
flushed range = [null, null)
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,167
PathUtils.java:74 - Deleting file during startup:
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big-TOC.txt
[junit-timeout] INFO [NonPeriodicTasks:1] 2022-05-30 16:05:45,167
PathUtils.java:74 - Deleting file during startup:
/tmp/cassandra/build/test/cassandra/data/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/nb-29-big-Summary.db
[junit-timeout] INFO [PerDiskMemtableFlushWriter_0:2] 2022-05-30 16:05:45,174
Flushing.java:145 - Writing Memtable-sstable_activity_v2@1687505407(0.422KiB
serialized bytes, 54 ops, 13.236KiB (0%) on-heap, 1.875KiB (0%) off-heap),
flushed range = [null, null)
[junit-timeout] INFO [PerDiskMemtableFlushWriter_0:2] 2022-05-30 16:05:45,175
Flushing.java:171 - Completed flushing
/tmp/cassandra/build/test/cassandra/data/system/sstable_activity_v2-62efe31f3be8310c8d298963439c1288/nb-8-big-Data.db
(2.455KiB) for commitlog position CommitLogPosition(segmentId=1653926717793,
position=102496)
[junit-timeout] INFO [PerDiskMemtableFlushWriter_0:1] 2022-05-30 16:05:45,175
Flushing.java:171 - Completed flushing
/tmp/cassandra/build/test/cassandra/
[jira] [Updated] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17677:
Description:
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoaderOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected from the Cassandra config parameters and unused
at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
{{and add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
was:
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoadOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected from the Cassandra config parameters and unused
at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
{{and add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoaderOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17677:
Description:
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoadOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected from the Cassandra config parameters and unused
at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
{{and add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
was:
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoadOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected and unused at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
{{and add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoadOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected from the Cassandra config parameters and
> unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17643) Add utests_system_keyspace_directory to pre-commit tests workflow in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545050#comment-17545050 ] Ekaterina Dimitrova commented on CASSANDRA-17643: - Hey [~jmckenzie], I was about to ping you for advice on that one whether it is worth a ticket as you've been working in that area a lot. I can't reproduce it locally and in CircleCI (only tried the low resources though, I will bump also one run with medium) - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1681/workflows/f50d85b3-3fc3-4c3e-b410-a441848d1635/jobs/11788/tests#failed-test-0] One thing is certain, the CircleCI config change cannot trigger this failure. > Add utests_system_keyspace_directory to pre-commit tests workflow in CircleCI > -- > > Key: CASSANDRA-17643 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17643 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: High > Fix For: 4.0.5, 4.1-beta > > > utests_system_keyspace_directory tests get broken every now and then but we > don't have them added in Jenkins and they are not mandatory pre-commit in > CircleCI. > A quick first step to have a better monitoring on those is to add them at > least being mandatory ran before a commit in CircleCI -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17389) JVM Crashing with SIGSEGV for Cassandra 3.11.3
[
https://issues.apache.org/jira/browse/CASSANDRA-17389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545048#comment-17545048
]
Muhammad commented on CASSANDRA-17389:
--
Since the JVM crashes appear to be happening in the compiled code, I tried
excluding the problematic frame from the C2 compilation as suggested
[here|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/crashes002.html#CIHDIBJA].
After running through a few iterations, it appears that the last crash seen is
[here|https://github.com/apache/cassandra/blob/cassandra-3.11.3/src/java/org/apache/cassandra/io/sstable/IndexSummary.java#L145].
{code:java}
# SIGSEGV (0xb) at pc=0x7f847e068dac, pid=20576, tid=0x7f6d51a45700
#
# JRE version: OpenJDK Runtime Environment (8.0_322-b06) (build 1.8.0_322-b06)
# Java VM: OpenJDK 64-Bit Server VM (25.322-b06 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# J 12860 C2
org.apache.cassandra.io.sstable.IndexSummary.getPositionInSummary(I)I (12
bytes) @ 0x7f847e068dac [0x7f847e068d60+0x4c]
#{code}
> JVM Crashing with SIGSEGV for Cassandra 3.11.3
> --
>
> Key: CASSANDRA-17389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17389
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muhammad
>Priority: Normal
> Attachments: hs_err.txt
>
>
> I am running a Cassandra 3.11.3 cluster with latest Corretto-8 and seeing JVM
> crashes with SIGSEGV signal at random intervals across various Cassandra
> nodes. This crash seems to happen more frequently while I am doing rolling
> restarts on the cluster.
> I am attaching the JVM error report for the crashes that are observed here in
> this case. [^hs_err.txt]
> Looking at the error report, it appears that the problematic frame is
> {*}binarySearch{*}, which ultimately calls
> [this|https://github.com/apache/cassandra/blob/cassandra-3.11.3/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java#L175].
> As per my knowledge, it is not recommended to use the sun.misc.Unsafe
> outside the JDK. Could you please advice here.
> Thanks.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17666) Option to disable write path during streaming for CDC enabled tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17666: -- Reviewers: Josh McKenzie > Option to disable write path during streaming for CDC enabled tables > > > Key: CASSANDRA-17666 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17666 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Change Data Capture >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > For the CDC-enabled tables, a special write path is employed during > streaming. The mutations streamed are written into commit log first. > There are scenarios that the commit logs can accumulate, which lead to > failure of streaming and blocking writes. > I'd like to propose adding a dynamic toggle to disable the special write path > for CDC during streaming. > Please note that the toggle is a trade-off. Because the special write path is > there in the hope to ensure data consistency. Turning it off allows the > streaming to pass, but in some extreme scenarios, the downstream CDC > consumers may have holes in the stream, depending on how they consumes the > commit logs. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17677:
Fix Version/s: 4.1-beta
4.1.x
4.x
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoadOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected and unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]}}
> {{And add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17677:
Description:
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoadOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected and unused at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
{{And add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
was:
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoadOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected and unused at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]}}
{{And add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoadOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected and unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{And add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17677:
Description:
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoadOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected and unused at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
{{and add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
was:
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoadOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected and unused at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
{{And add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoadOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected and unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
> {{and add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
[
https://issues.apache.org/jira/browse/CASSANDRA-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17677:
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Tool/bulk load
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
> --
>
> Key: CASSANDRA-17677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> {{entire_sstable_stream_throughput_outbound and
> entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
> CASSANDRA-17065.They were added to the LoadOptions class but they are not
> loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part
> of this ticket we need to fix the BulkLoader, also those properties should be
> advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
> for the bulk loader because those are not loaded and those variables in
> LoaderOptions are disconnected and unused at the moment. }}
> It will be good also to update the doc here -
> [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]}}
> {{And add a test that those are loaded properly when used with the
> BulkLoader. }}
> {{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17677) Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle
Ekaterina Dimitrova created CASSANDRA-17677:
---
Summary: Fix BulkLoader to load entireSSTableThrottle and
entireSSTableInterDcThrottle
Key: CASSANDRA-17677
URL: https://issues.apache.org/jira/browse/CASSANDRA-17677
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
{{entire_sstable_stream_throughput_outbound and
entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in
CASSANDRA-17065.They were added to the LoadOptions class but they are not
loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of
this ticket we need to fix the BulkLoader, also those properties should be
advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234
for the bulk loader because those are not loaded and those variables in
LoaderOptions are disconnected and unused at the moment. }}
It will be good also to update the doc here -
[https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]}}
{{And add a test that those are loaded properly when used with the BulkLoader.
}}
{{CC [~frankgh] }}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17594) Fix flaky python-tests due to connection getting closed
[
https://issues.apache.org/jira/browse/CASSANDRA-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545035#comment-17545035
]
Jon Meredith commented on CASSANDRA-17594:
--
+1 - it's hard to tell how the dtest runs really went after time/changes, but I
think it's good. Will double-check Jenkins once this merges.
> Fix flaky python-tests due to connection getting closed
> ---
>
> Key: CASSANDRA-17594
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17594
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: NA
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We log unknown exceptions at the networking level, which includes case where
> the remote side closes the connection (such as the cases caused by shutting
> down), depending on how quickly the instances shutdown, this could cause
> python-dtest to fail for random tests with a message such as
> {code}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [WARN [epollEventLoopGroup-5-9] 2022-05-03T16:47:03,800
> ExceptionHandlers.java:134 - Unknown exception in client networking
> io.netty.channel.unix.Errors$NativeIoException: writeAddress(..) failed:
> Connection reset by peer, WARN [epollEventLoopGroup-5-9]
> 2022-05-03T16:47:03,800 ExceptionHandlers.java:134 - Unknown exception in
> client networking
> io.netty.channel.unix.Errors$NativeIoException: writeAddress(..) failed:
> Connection reset by peer]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17643) Add utests_system_keyspace_directory to pre-commit tests workflow in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545010#comment-17545010 ] Josh McKenzie commented on CASSANDRA-17643: --- Poor, poor GroupCommitLogTest. [CI Results] Branch: 4.1, build number: 47 butler url: [https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-4.1/Cassandra-4.1] jenkins url: [https://ci-cassandra.apache.org/job/Cassandra-4.1/47/] JIRA: CASSANDRA-17643 commit url: [https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=3d7d064cd297b88a327edff5091404679e11d6fd] affected paths: * .circleci/config-2_1.yml.high_res.patch * .circleci/config.yml * .circleci/config-2_1.yml.mid_res.patch * .circleci/config.yml.MIDRES * .circleci/config.yml.HIGHRES * .circleci/config-2_1.yml * .circleci/config.yml.LOWRES Build Result: UNSTABLE Passing Tests: 47192 Failing Tests: 64 ||Test|Failures|JIRA| |org.apache.cassandra.utils.memory.LongBufferPoolTest.testPoolAllocateWithRecyclePartially|6 of 45|CASSANDRA-16681?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testTruncateWithoutSnapshot[3]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testRecoveryWithEmptyLog[4]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testTruncateWithoutSnapshotNonDurable[3]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testOutOfOrderLogDiscardWithCompaction[3]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.distributed.upgrade.CompactStorageImplicitNullInClusteringTest.testImplicitNullInClusteringWithCompactStorage|1 of 45|CASSANDRA-17642?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testRecoveryWithIdMismatch[5]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.distributed.upgrade.MixedModeFrom3UnloggedBatchTest.testSimpleStrategy|3 of 45|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testOutOfOrderLogDiscard[3]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testOutOfOrderLogDiscard[4]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testDontDeleteIfDirty[5]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testExceedRecordLimitWithMultiplePartitions[5]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testDeleteIfNotDirty[4]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testRecoveryWithGarbageLog_fail[5]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.cql3.ViewComplexTTLTest.testUpdateColumnInViewPKWithTTLWithFlush[3]|9 of 45|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testRecoveryWithNegativeSizeArgument[4]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testRecoveryWithNegativeSizeArgument[5]-cdc|1 of 45|CASSANDRA-17232?| |dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_4_1_x_To_indev_trunk.test_bootstrap|1 of 45|[Multiple JIRAs found|https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20resolution%20%3D%20unresolved%20and%20summary%20~%20%22*TestUpgrade*%22]| |org.apache.cassandra.cql3.validation.operations.AggregationTest.testEmptyListAndNullInitcond|1 of 45|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testRecoveryWithShortMutationSize[3]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation|11 of 45|CASSANDRA-17461?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testOutOfOrderLogDiscardWithCompaction[4]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testRecoveryWithCollectionClusteringKeysStatic[4]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testOutOfOrderLogDiscard[5]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.cql3.validation.operations.CompactStorageTest.testEmptyRestrictionValue|5 of 45|CASSANDRA-17674?| |org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.testRangeQuery|3 of 45|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testOutOfOrderFlushRecovery[5]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testRecoveryWithCollectionClusteringKeysStatic[5]-cdc|1 of 45|CASSANDRA-17232?| |org.apache.cassandra.distributed.test.SchemaTest.readRepairWithCompaction|10 of 45|CASSANDRA-
[jira] [Commented] (CASSANDRA-17213) CompactStorageUpgradeTest.compactStorageUpgradeTest fails w/OOM
[ https://issues.apache.org/jira/browse/CASSANDRA-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545008#comment-17545008 ] Josh McKenzie commented on CASSANDRA-17213: --- [CI Results] Branch: 4.1, build number: 46 butler url: https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-4.1/Cassandra-4.1 jenkins url: https://ci-cassandra.apache.org/job/Cassandra-4.1/46/ JIRA: CASSANDRA-17213 commit url: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=8a9ba8866db6162a7b7352a260122d6e3c219567 affected paths: * test/distributed/org/apache/cassandra/distributed/upgrade/DropCompactStorageWithClusteringAndValueColumnTest.java * test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorageSingleColumnTest.java * test/distributed/org/apache/cassandra/distributed/upgrade/DropCompactStorageBeforeUpgradeSSTablesTest.java * test/distributed/org/apache/cassandra/distributed/upgrade/DropCompactStorageWithDeletesAndWritesTest.java * test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorageMultiColumnTest.java * test/distributed/org/apache/cassandra/distributed/upgrade/DropCompactStorageTest.java * test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage2to3UpgradeTest.java * test/distributed/org/apache/cassandra/distributed/upgrade/DropCompactStorageTester.java Build Result: UNSTABLE Passing Tests: 47504 Failing Tests: 10 ||Test|Failures|JIRA|| |org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability|7 of 44|[CASSANDRA-17310?|https://issues.apache.org/jira/browse/CASSANDRA-17310]| |org.apache.cassandra.net.ConnectionTest.testTimeout-compression|1 of 44|[CASSANDRA-16677?|https://issues.apache.org/jira/browse/CASSANDRA-16677]| |org.apache.cassandra.distributed.test.SchemaTest.readRepairWithCompaction|9 of 44|[CASSANDRA-17641?|https://issues.apache.org/jira/browse/CASSANDRA-17641]| |org.apache.cassandra.distributed.test.SchemaTest.readRepair|9 of 44|[CASSANDRA-17641?|https://issues.apache.org/jira/browse/CASSANDRA-17641]| |org.apache.cassandra.db.commitlog.GroupCommitLogTest.testExceedRecordLimitWithMultiplePartitions[3]|1 of 44|[CASSANDRA-17232?|https://issues.apache.org/jira/browse/CASSANDRA-17232]| |org.apache.cassandra.distributed.upgrade.CompactStoragePagingTest.testPagingWithCompactStorage|1 of 44|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252] |org.apache.cassandra.cql3.validation.entities.TupleTypeTest.testNestedTuple|5 of 44|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252] |dtest-novnode.bootstrap_test.TestBootstrap.test_bootstrap_with_reset_bootstrap_state|1 of 44|[Multiple JIRAs found|https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20resolution%20%3D%20unresolved%20and%20summary%20~%20"*TestBootstrap*";] |dtest.cqlsh_tests.test_cqlsh.TestCqlsh.test_describe_describes_non_default_compaction_parameters|1 of 44|[CASSANDRA-17322?|https://issues.apache.org/jira/browse/CASSANDRA-17322]| |org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRowDeletionTie-compression|6 of 44|[CASSANDRA-17458?|https://issues.apache.org/jira/browse/CASSANDRA-17458]| > CompactStorageUpgradeTest.compactStorageUpgradeTest fails w/OOM > --- > > Key: CASSANDRA-17213 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17213 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Josh McKenzie >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.28, 3.11.14, 4.0.5, 4.1-alpha, 4.2 > > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/882/testReport/org.apache.cassandra.distributed.upgrade/CompactStorageUpgradeTest/compactStorageUpgradeTest/] > h3. Error Message > GC overhead limit exceeded > h3. Stacktrace > java.lang.OutOfMemoryError: GC overhead limit exceeded at > sun.net.www.ParseUtil.encodePath(ParseUtil.java:105) at > sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:969) at > sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:1056) at > sun.misc.URLClassPath.getResource(URLClassPath.java:249) at > java.net.URLClassLoader$1.run(URLClassLoader.java:366) at > java.net.URLClassLoader$1.run(URLClassLoader.java:363) at > java.security.AccessController.doPrivileged(Native Method) at > java.net.URLClassLoader.findClass(URLClassLoader.java:362) at > org.apache.cassandra.distributed.shared.InstanceClassLoader.findClass(InstanceClassLoader.java:140) > at > org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:123) > at > org.apache.cassandra.distributed
[jira] [Commented] (CASSANDRA-17616) Add in Circle CI an option to run in a loop tests for the new j8_jvm_dtests_vnode job
[ https://issues.apache.org/jira/browse/CASSANDRA-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545006#comment-17545006 ] Josh McKenzie commented on CASSANDRA-17616: --- [CI Results] Branch: 4.1, build number: 40 butler url: https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-4.1/Cassandra-4.1 jenkins url: https://ci-cassandra.apache.org/job/Cassandra-4.1/40/ JIRA: CASSANDRA-17616 commit url: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=0f58db94658ee4fa4af49e9499fb2dbe85e8b075 affected paths: * .circleci/config.yml.MIDRES * .circleci/config.yml.HIGHRES * .circleci/config-2_1.yml * .circleci/generate.sh * .circleci/config.yml.LOWRES * .circleci/config.yml Build Result: UNSTABLE Passing Tests: 46327 Failing Tests: 13 ||Test|Failures|JIRA|| |org.apache.cassandra.cql3.validation.entities.TupleTypeTest.testNestedTuple|3 of 38|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252] |org.apache.cassandra.distributed.upgrade.MixedModeFrom3LoggedBatchTest.testSimpleStrategy|3 of 38|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252] |org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageImplicitNullInClusteringTest|7 of 38|[CASSANDRA-17642?|https://issues.apache.org/jira/browse/CASSANDRA-17642]| |org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRowDeletionTie-cdc|5 of 38|[CASSANDRA-17458?|https://issues.apache.org/jira/browse/CASSANDRA-17458]| |org.apache.cassandra.cql3.validation.operations.CompactStorageTest.testUpdateWithMultiplePartitionKeyComponents|1 of 38|[CASSANDRA-17674?|https://issues.apache.org/jira/browse/CASSANDRA-17674]| |org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation|10 of 38|[CASSANDRA-17461?|https://issues.apache.org/jira/browse/CASSANDRA-17461]| |junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest|3 of 38|[Multiple JIRAs found|https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20resolution%20%3D%20unresolved%20and%20summary%20~%20"*test*";] |org.apache.cassandra.cql3.validation.operations.CompactStorageTest.testGroupByWithoutPaging|3 of 38|[CASSANDRA-17674?|https://issues.apache.org/jira/browse/CASSANDRA-17674]| |dtest-upgrade.upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_indev_3_0_x_To_indev_4_1_x.test_no_clustering|2 of 38|[CASSANDRA-12809?|https://issues.apache.org/jira/browse/CASSANDRA-12809]| |org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability|5 of 38|[CASSANDRA-17310?|https://issues.apache.org/jira/browse/CASSANDRA-17310]| |junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASTest|1 of 38|[Multiple JIRAs found|https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20resolution%20%3D%20unresolved%20and%20summary%20~%20"*test*";] |org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.testIndexOnPartitionKeyInsertExpiringColumn|3 of 38|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252] |org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest|2 of 38|[CASSANDRA-17583?|https://issues.apache.org/jira/browse/CASSANDRA-17583]| > Add in Circle CI an option to run in a loop tests for the new > j8_jvm_dtests_vnode job > -- > > Key: CASSANDRA-17616 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17616 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.1-alpha, 4.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Similar to the python dtests we need to be able to run in a loop with/without > vnodes the in-jvm tests. Very convenient during debugging flaky tests -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17659) Mention some undocumented behaviors of native protocol v5
[ https://issues.apache.org/jira/browse/CASSANDRA-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545004#comment-17545004 ] Josh McKenzie commented on CASSANDRA-17659: --- Nothing this ticket touched obviously. :) [CI Results] Branch: 4.1, build number: 39 butler url: [https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-4.1/Cassandra-4.1] jenkins url: [https://ci-cassandra.apache.org/job/Cassandra-4.1/39/] JIRA: CASSANDRA-17659 commit url: [https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=1322f03afad6390f25a962369f27ccf446cbaa5f] affected paths: * doc/native_protocol_v5.spec Build Result: UNSTABLE Passing Tests: 46965 Failing Tests: 18 ||Test|Failures|JIRA| |dtest.hintedhandoff_test.TestHintedHandoff.test_hintedhandoff_window|1 of 37|CASSANDRA-17144?| |org.apache.cassandra.distributed.upgrade.MixedModeFrom3LoggedBatchTest.testSimpleStrategy|2 of 37|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]| |org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.testIndexOnFrozenUDT|3 of 37|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]| |org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie-cdc|2 of 37|CASSANDRA-17458?| |org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageImplicitNullInClusteringTest|6 of 37|CASSANDRA-17642?| |org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageColumnDeleteTest|4 of 37|CASSANDRA-17642?| |org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability|4 of 37|CASSANDRA-17310?| |org.apache.cassandra.tools.TopPartitionsTest.testServiceTopPartitionsSingleTable-cdc|6 of 37|CASSANDRA-17649?| |org.apache.cassandra.distributed.test.PaxosRepairTest.paxosRepairVersionGate|2 of 37|CASSANDRA-17573?| |dtest-upgrade.upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_indev_3_11_x_To_indev_4_1_x.test_expanded_list_item_conditional|1 of 37|CASSANDRA-12809?| |dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD.test_parallel_upgrade_with_internode_ssl|1 of 37|CASSANDRA-17296?| |org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation|9 of 37|CASSANDRA-17461?| |org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.testCanQuerySecondaryIndex|2 of 37|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]| |org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.testIndexOnRegularColumnInsertExpiringColumnWithFlush|5 of 37|[No JIRA found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]| |org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRowDeletionTie|6 of 37|CASSANDRA-17458?| |org.apache.cassandra.distributed.test.ring.BootstrapTest.readWriteDuringBootstrapTest|5 of 37|[Multiple JIRAs found|https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20resolution%20%3D%20unresolved%20and%20summary%20~%20%22*BootstrapTest*%22]| |org.apache.cassandra.distributed.test.SchemaTest.readRepairWithCompaction|6 of 37|CASSANDRA-17641?| |org.apache.cassandra.distributed.upgrade.MixedModeFrom3ReplicationTest.testSimpleStrategy|2 of 37|CASSANDRA-17636?| > Mention some undocumented behaviors of native protocol v5 > - > > Key: CASSANDRA-17659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17659 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Andrea Leopardi >Assignee: Andrea Leopardi >Priority: Normal > Fix For: 4.0.5, 4.1-beta > > Attachments: 17659-trunk.txt > > > [Patch as a GitHub PR to my own > fork|https://github.com/whatyouhide/cassandra/pull/1] > Some things in the native protocol v5 are undocumented: > * Integers in the outer framing format are little endian > * There is no mention of the parameters used to tweak the CRC24 algorithm > * No mention of the fact that if the uncompressed payload length in Section > 2.2 is 0, then the "compressed payload" should not be decompressed -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17660) jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
[
https://issues.apache.org/jira/browse/CASSANDRA-17660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545001#comment-17545001
]
Josh McKenzie commented on CASSANDRA-17660:
---
[CI Results]
Branch: 4.1, build number: 38
butler url:
https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-4.1/Cassandra-4.1
jenkins url: https://ci-cassandra.apache.org/job/Cassandra-4.1/38/
JIRA: CASSANDRA-17660
commit url:
https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=fb8bf30c6d1b6f893a77a74b9e8b4223e5497dd4
affected paths:
* src/java/org/apache/cassandra/net/PingMessage.java
Build Result: UNSTABLE
Passing Tests: 48053
Failing Tests: 12
||Test|Failures|JIRA||
|org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRowDeletionTie-compression|4
of 36|[CASSANDRA-17458?|https://issues.apache.org/jira/browse/CASSANDRA-17458]|
|org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability|3
of 36|[CASSANDRA-17310?|https://issues.apache.org/jira/browse/CASSANDRA-17310]|
|org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest.testRangeQuery|2
of 36|[No JIRA
found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]
|dtest-upgrade.upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_11_x_To_indev_4_1_x.test_indexed_with_eq|1
of 36|[CASSANDRA-17627?|https://issues.apache.org/jira/browse/CASSANDRA-17627]|
|org.apache.cassandra.cql3.ViewComplexTTLTest.testUpdateColumnInViewPKWithTTLWithFlush[3]|8
of 36|[No JIRA
found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]
|org.apache.cassandra.distributed.test.SchemaTest.readRepairWithCompaction|5 of
36|[CASSANDRA-17641?|https://issues.apache.org/jira/browse/CASSANDRA-17641]|
|org.apache.cassandra.net.ProxyHandlerConnectionsTest.testExpireSome-cdc|6 of
36|[CASSANDRA-17301?|https://issues.apache.org/jira/browse/CASSANDRA-17301]|
|org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV30Test.testAvailability|6
of 36|[CASSANDRA-17307?|https://issues.apache.org/jira/browse/CASSANDRA-17307]|
|dtest-offheap.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|2
of 36|[CASSANDRA-11268?|https://issues.apache.org/jira/browse/CASSANDRA-11268]|
|org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation|8
of 36|[CASSANDRA-17461?|https://issues.apache.org/jira/browse/CASSANDRA-17461]|
|org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairUpdate|2
of 36|[No JIRA
found|https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252]
|dtest-offheap.repair_tests.repair_test.TestRepair.test_dead_sync_participant|2
of 36|[Multiple JIRAs
found|https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20and%20resolution%20%3D%20unresolved%20and%20summary%20~%20"*TestRepair*";]
> jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
> -
>
> Key: CASSANDRA-17660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17660
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.28, 3.11.14
>
>
> trunk jvm upgrade tests periodically fail due to the ping message not being
> able to be serialized on 3.x branches. We need support for jvm-dtest even if
> we ignore the messages.
> {code}
> Suppressed: java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.net.PingMessage$PingMessageSerializer.serialize(PingMessage.java:45)
> at
> org.apache.cassandra.net.PingMessage$PingMessageSerializer.serialize(PingMessage.java:41)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:362)
> at
> org.apache.cassandra.distributed.impl.Instance$1.allowIncomingMessage(Instance.java:302)
> at
> org.apache.cassandra.net.MessagingService.receive(MessagingService.java:866)
> at
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:224)
> at
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:193)
> at
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:96)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17676) When a node is bootstrapping it gets the whole gossip state but applies in random order causing some cases where StorageService will fail causing an instance to no
[ https://issues.apache.org/jira/browse/CASSANDRA-17676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544989#comment-17544989 ] David Capwell commented on CASSANDRA-17676: --- Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17676-trunk-81E3A7B3-80E0-40AD-914A-4A9BEFA7077F]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17676-trunk-81E3A7B3-80E0-40AD-914A-4A9BEFA7077F]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1746/]| > When a node is bootstrapping it gets the whole gossip state but applies in > random order causing some cases where StorageService will fail causing an > instance to not show up in TokenMetadata > - > > Key: CASSANDRA-17676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17676 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > When gossip state has a causal relationship, the order the state gets applied > needs to match this relationship, and when it doesn’t it can cause bootstrap > (which apply the whole state in an empty state) to see missing data or > instances -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17244) Fix org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition
[ https://issues.apache.org/jira/browse/CASSANDRA-17244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544961#comment-17544961 ] Ekaterina Dimitrova commented on CASSANDRA-17244: - Hey, [~dcapwell] (sorry, I am super annoying today :(), but did you have the chance to look at what [~azotcsit] mentioned? > Fix > org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition > -- > > Key: CASSANDRA-17244 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17244 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x, 4.x > > > org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition > failed > [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1354/testReport/junit/org.apache.cassandra.distributed.test.trackwarnings/TombstoneCountWarningTest/failThresholdSinglePartition/] > I didn't find any other occurrences but seems to me legit failure. > CC [~dcapwell] as I think you were working on those and probably you will > make better assessment than me. :) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17575) forceCompactionForTokenRange when using a wrapped range may include sstables not within that range
[ https://issues.apache.org/jira/browse/CASSANDRA-17575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544960#comment-17544960 ] Ekaterina Dimitrova commented on CASSANDRA-17575: - [~dcapwell], I was wondering whether you had the chance to look at this? > forceCompactionForTokenRange when using a wrapped range may include sstables > not within that range > -- > > Key: CASSANDRA-17575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17575 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: David Capwell >Priority: Normal > Fix For: 4.1-beta, 4.1.x > > > This was found in CASSANDRA-17537 > When you compact the range (32, 31] this should include everything BUT 32, > but in the test > org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest#testTokenRangeCompaction > it found that SSTables with the bounds (32, 32) were getting included in the > set of SSTables to compact -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17566) Fix flaky test - org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
[
https://issues.apache.org/jira/browse/CASSANDRA-17566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544956#comment-17544956
]
Ekaterina Dimitrova commented on CASSANDRA-17566:
-
[~dcapwell] I noticed you are also the original author of the test, maybe you
can bring some light here?
> Fix flaky test -
> org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
> ---
>
> Key: CASSANDRA-17566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17566
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Seen on jenkins here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1083/testReport/org.apache.cassandra.distributed.test.repair/ForceRepairTest/force_2/]
>
> and circle here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/42f936c7-2ede-4fbf-957c-5fb4e461dd90/jobs/5160/tests#failed-test-1
> {noformat}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, --force, --full] was not successful
> stdout:
> [2022-04-20 15:11:01,402] Starting repair command #2
> (1701a090-c0bc-11ec-9898-07c796ce6a49), repairing keyspace
> distributed_test_keyspace with repair options (parallelism: parallel, primary
> range: false, incremental: false, job threads: 1, ColumnFamilies: [],
> dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 3, pull repair:
> false, force repair: true, optimise streams: false, ignore unreplicated
> keyspaces: false, repairPaxos: true, paxosOnly: false)
> [2022-04-20 15:11:11,406] Repair command #2 failed with error Did not get
> replies from all endpoints.
> [2022-04-20 15:11:11,408] Repair command #2 finished with error
> stderr:
> error: Repair job has failed with the error message: Repair command #2 failed
> with error Did not get replies from all endpoints.. Check the logs on the
> repair participants for further details
> -- StackTrace --
> java.lang.RuntimeException: Repair job has failed with the error message:
> Repair command #2 failed with error Did not get replies from all endpoints..
> Check the logs on the repair participants for further details
> at
> org.apache.cassandra.tools.RepairRunner.progress(RepairRunner.java:137)
> at
> org.apache.cassandra.utils.progress.jmx.JMXNotificationProgressListener.handleNotification(JMXNotificationProgressListener.java:77)
> at
> javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:275)
> at
> javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:352)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17553) NPE in RangeTombstoneTest.overlappingRangeTest-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544953#comment-17544953
]
Ekaterina Dimitrova commented on CASSANDRA-17553:
-
I saw similar failures in other tests these days. There was some ticket
[~dcapwell] is working on. Not sure whether it is related. Probably he can
confirm?
> NPE in RangeTombstoneTest.overlappingRangeTest-compression
> --
>
> Key: CASSANDRA-17553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17553
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Caleb Rackliffe
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> The trace looks something like this on trunk:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.RangeTombstoneTest.overlappingRangeTest(RangeTombstoneTest.java:437)
> 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)
> {noformat}
> See
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1078/testReport/org.apache.cassandra.db/RangeTombstoneTest/overlappingRangeTest_compression/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16974) Fix org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
[
https://issues.apache.org/jira/browse/CASSANDRA-16974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544950#comment-17544950
]
Ekaterina Dimitrova commented on CASSANDRA-16974:
-
I think in that case we can close it for now and reopen in case it reappears
again. Checked again Butler, still no failures.
> Fix
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
>
>
> Key: CASSANDRA-16974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16974
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5
> is
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/junit/org.apache.cassandra.distributed.test/UnableToParseClientMessageTest/badHeader_version_5_v5_/]
> on trunk
> {code:java}
> Error Message
> Expecting actual not to be empty
> Stacktrace
> junit.framework.AssertionFailedError:
> Expecting actual not to be empty
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.test(UnableToParseClientMessageTest.java:158)
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader(UnableToParseClientMessageTest.java:99)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16974) Fix org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
[
https://issues.apache.org/jira/browse/CASSANDRA-16974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16974:
Resolution: Cannot Reproduce
Status: Resolved (was: Open)
> Fix
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
>
>
> Key: CASSANDRA-16974
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16974
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5
> is
> [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/junit/org.apache.cassandra.distributed.test/UnableToParseClientMessageTest/badHeader_version_5_v5_/]
> on trunk
> {code:java}
> Error Message
> Expecting actual not to be empty
> Stacktrace
> junit.framework.AssertionFailedError:
> Expecting actual not to be empty
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.test(UnableToParseClientMessageTest.java:158)
> at
> org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader(UnableToParseClientMessageTest.java:99)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17489) Test Failures: org.apache.cassandra.metrics and a few others failing for the same reasons
[
https://issues.apache.org/jira/browse/CASSANDRA-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544944#comment-17544944
]
Ekaterina Dimitrova commented on CASSANDRA-17489:
-
[~benedict], [~bdeggleston] did anyone of you have the time to look into those?
Pre-commit system-keyspace-directory tests were not run as at that point they
were not mandatory pre-commit (corrected for visibility the other day as they
are not run in Jenkins at the moment). These are the last consistently failing
tests for 4.1 and trunk (only a few flakes out there)
> Test Failures: org.apache.cassandra.metrics and a few others failing for the
> same reasons
> -
>
> Key: CASSANDRA-17489
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17489
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Urgent
> Fix For: 4.1-beta
>
>
> There are 10 tests failing in CircleCI - utests_system_keyspace_directory
> This test target is not presented in Jenkins.
>
> The tests fail for the same reason:
> {code:java}
> java.lang.RuntimeException: java.nio.file.NoSuchFileException:
> build/test/cassandra/data/system/_paxos_repair_state/ballot.meta.tmp at
> org.apache.cassandra.io.util.SequentialWriter.openChannel(SequentialWriter.java:128)
> at
> org.apache.cassandra.io.util.SequentialWriter.(SequentialWriter.java:161)
> at
> org.apache.cassandra.io.util.SequentialWriter.(SequentialWriter.java:150)
> at
> org.apache.cassandra.service.paxos.uncommitted.PaxosBallotTracker.flush(PaxosBallotTracker.java:130)
> at
> org.apache.cassandra.service.paxos.uncommitted.PaxosStateTracker.maybeRebuild(PaxosStateTracker.java:309)
> at
> org.apache.cassandra.service.paxos.PaxosState.maybeRebuildUncommittedState(PaxosState.java:122)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:368)
> at
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:655)
> at
> org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
> at org.apache.cassandra.metrics.CQLMetricsTest.setup(CQLMetricsTest.java:53)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/data/system/_paxos_repair_state/ballot.meta.tmp at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
> at java.nio.channels.FileChannel.open(FileChannel.java:287) at
> java.nio.channels.FileChannel.open(FileChannel.java:335) at
> org.apache.cassandra.io.util.SequentialWriter.openChannel(SequentialWriter.java:113){code}
> The tests started failing every time after CEP 14 was committed.
> For reference:
> * build before -
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1484/workflows/88cac38a-ee0c-46e2-a6a7-5c364ff04f3e/jobs/9680
> * build after -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1485/workflows/c3f56ec1-2ef0-4e61-b689-c7764934827d/jobs/9682]
> I think the only unrelated is
> {code:java}
> testTokenGenerator_single_rack_or_single_rf{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17625) Test Failure: dtest-offheap.auth_test.TestAuth.test_system_auth_ks_is_alterable (from Cassandra dtests)
[
https://issues.apache.org/jira/browse/CASSANDRA-17625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544938#comment-17544938
]
Ekaterina Dimitrova commented on CASSANDRA-17625:
-
{quote}Well this failed on jenkins not circle iiuc. And we know sometimes they
repro on one place but not another.
{quote}
True, but it doesn't fail in Jenkins too after the infra issues were solved.
If currently the other tests go with default 10 and we don't see a need to
raise it, but this one starts failing with more than 3 times longer delay I
would love to know why tbh. Now you spent the time to confirm that it was just
our infra. The infra is fixed and I don't see a reason to make it 6 times the
default delay.
Maybe [~jmckenzie] as a reporter or anyone else can also express opinion here.
> Test Failure:
> dtest-offheap.auth_test.TestAuth.test_system_auth_ks_is_alterable (from
> Cassandra dtests)
> ---
>
> Key: CASSANDRA-17625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17625
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> Flaked a couple times on 4.1
> {code}
> Error Message
> cassandra.DriverException: Keyspace metadata was not refreshed. See log for
> details.
> {code}
> https://ci-cassandra.apache.org/job/Cassandra-4.1/14/testReport/dtest-offheap.auth_test/TestAuth/test_system_auth_ks_is_alterable/
> Nightlies archive if above dropped:
> https://nightlies.apache.org/cassandra/ci-cassandra.apache.org/job/Cassandra-4.1/14/testReport/dtest-offheap.auth_test/TestAuth/test_system_auth_ks_is_alterable/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17491) WEBSITE - Descriptions of Slack channels in Community section is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544911#comment-17544911
]
Erick Ramirez commented on CASSANDRA-17491:
---
I've completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch 'asf-site' set up to track remote branch 'asf-site' from 'origin'.
Switched to a new branch 'asf-site'
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at ddeb63d1 generate docs for 700ff74c
$ git push -f origin asf-site
Username for 'https://github.com': erickramirezau
Password for 'https://erickramire...@github.com':
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/apache/cassandra-website.git
+ 68a1b82a...ddeb63d1 asf-site -> asf-site (forced update){noformat}
The updated Community page is now live on the site –
https://cassandra.apache.org/_/community.html
> WEBSITE - Descriptions of Slack channels in Community section is incorrect
> --
>
> Key: CASSANDRA-17491
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17491
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Brandon Williams
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot_20220327_063323.png,
> c17491-02-proposed_layout.png, c17491-03-community_page.png
>
>
> https://cassandra.apache.org/_/community.html#how-to-contribute
> Among other things, this says #cassandra-dev is for results of automated
> builds.
> !Screenshot_20220327_063323.png|width=500!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
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 (68a1b82a -> ddeb63d1)
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a change to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 68a1b82a generate docs for ae4a90ca add 700ff74c WEBSITE - Added spaces in Community page Dev slack section patch by Erick Ramirez; reviewed by Brandon Williams for CASSANDRA-17491 add ddeb63d1 generate docs for 700ff74c 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 (68a1b82a) \ N -- N -- N refs/heads/asf-site (ddeb63d1) 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: content/_/community.html | 9 + content/search-index.js| 2 +- .../source/modules/ROOT/pages/community.adoc | 8 +++- site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 bytes 4 files changed, 17 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17491) WEBSITE - Descriptions of Slack channels in Community section is incorrect
[ https://issues.apache.org/jira/browse/CASSANDRA-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544910#comment-17544910 ] Erick Ramirez commented on CASSANDRA-17491: --- Th updated Community page is now in staging -- https://cassandra.staged.apache.org/_/community.html > WEBSITE - Descriptions of Slack channels in Community section is incorrect > -- > > Key: CASSANDRA-17491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17491 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.0.x, 4.1.x > > Attachments: Screenshot_20220327_063323.png, > c17491-02-proposed_layout.png, c17491-03-community_page.png > > > https://cassandra.apache.org/_/community.html#how-to-contribute > Among other things, this says #cassandra-dev is for results of automated > builds. > !Screenshot_20220327_063323.png|width=500! -- This message was sent by Atlassian Jira (v8.20.7#820007) - 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 (68a1b82a -> ddeb63d1)
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 68a1b82a generate docs for ae4a90ca add 700ff74c WEBSITE - Added spaces in Community page Dev slack section patch by Erick Ramirez; reviewed by Brandon Williams for CASSANDRA-17491 new ddeb63d1 generate docs for 700ff74c 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 (68a1b82a) \ N -- N -- N refs/heads/asf-staging (ddeb63d1) 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/_/community.html | 9 + content/search-index.js| 2 +- .../source/modules/ROOT/pages/community.adoc | 8 +++- site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078 bytes 4 files changed, 17 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17491) WEBSITE - Descriptions of Slack channels in Community section is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544897#comment-17544897
]
Erick Ramirez edited comment on CASSANDRA-17491 at 6/1/22 1:19 PM:
---
Submitted a new patch:
||Branch||PR||
|{{trunk}}|[#136|https://github.com/apache/cassandra-website/pull/136]|
!c17491-03-community_page.png|width=300!
was (Author: JIRAUSER285101):
Submitted a new patch:
||Branch||PR||
|{{trunk}}|[#136|https://github.com/apache/cassandra-website/pull/136]|
> WEBSITE - Descriptions of Slack channels in Community section is incorrect
> --
>
> Key: CASSANDRA-17491
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17491
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Brandon Williams
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot_20220327_063323.png,
> c17491-02-proposed_layout.png, c17491-03-community_page.png
>
>
> https://cassandra.apache.org/_/community.html#how-to-contribute
> Among other things, this says #cassandra-dev is for results of automated
> builds.
> !Screenshot_20220327_063323.png|width=500!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17491) WEBSITE - Descriptions of Slack channels in Community section is incorrect
[ https://issues.apache.org/jira/browse/CASSANDRA-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17491: -- Attachment: c17491-03-community_page.png > WEBSITE - Descriptions of Slack channels in Community section is incorrect > -- > > Key: CASSANDRA-17491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17491 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.0.x, 4.1.x > > Attachments: Screenshot_20220327_063323.png, > c17491-02-proposed_layout.png, c17491-03-community_page.png > > > https://cassandra.apache.org/_/community.html#how-to-contribute > Among other things, this says #cassandra-dev is for results of automated > builds. > !Screenshot_20220327_063323.png|width=500! -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17491) WEBSITE - Descriptions of Slack channels in Community section is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544902#comment-17544902
]
Erick Ramirez commented on CASSANDRA-17491:
---
The website content is getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#136|https://github.com/apache/cassandra-website/pull/136]|[700ff74
|https://github.com/apache/cassandra-website/commit/700ff74c4de50e230b0b8ccbaaa6e051a9e4895a]|[#307|https://ci-cassandra.apache.org/job/cassandra-website/307/]|
> WEBSITE - Descriptions of Slack channels in Community section is incorrect
> --
>
> Key: CASSANDRA-17491
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17491
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Brandon Williams
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot_20220327_063323.png,
> c17491-02-proposed_layout.png
>
>
> https://cassandra.apache.org/_/community.html#how-to-contribute
> Among other things, this says #cassandra-dev is for results of automated
> builds.
> !Screenshot_20220327_063323.png|width=500!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17491) WEBSITE - Descriptions of Slack channels in Community section is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17491:
--
Fix Version/s: 4.0.x
4.1.x
Since Version: 4.0.0
Source Control Link:
https://github.com/apache/cassandra-website/commit/700ff74c4de50e230b0b8ccbaaa6e051a9e4895a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#136|https://github.com/apache/cassandra-website/pull/136]|[700ff74
|https://github.com/apache/cassandra-website/commit/700ff74c4de50e230b0b8ccbaaa6e051a9e4895a]|
> WEBSITE - Descriptions of Slack channels in Community section is incorrect
> --
>
> Key: CASSANDRA-17491
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17491
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Brandon Williams
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot_20220327_063323.png,
> c17491-02-proposed_layout.png
>
>
> https://cassandra.apache.org/_/community.html#how-to-contribute
> Among other things, this says #cassandra-dev is for results of automated
> builds.
> !Screenshot_20220327_063323.png|width=500!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17491) WEBSITE - Descriptions of Slack channels in Community section is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544897#comment-17544897
]
Erick Ramirez commented on CASSANDRA-17491:
---
Submitted a new patch:
||Branch||PR||
|{{trunk}}|[#136|https://github.com/apache/cassandra-website/pull/136]|
> WEBSITE - Descriptions of Slack channels in Community section is incorrect
> --
>
> Key: CASSANDRA-17491
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17491
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Brandon Williams
>Assignee: Erick Ramirez
>Priority: Normal
> Attachments: Screenshot_20220327_063323.png,
> c17491-02-proposed_layout.png
>
>
> https://cassandra.apache.org/_/community.html#how-to-contribute
> Among other things, this says #cassandra-dev is for results of automated
> builds.
> !Screenshot_20220327_063323.png|width=500!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: WEBSITE - Added spaces in Community page Dev slack section patch by Erick Ramirez; reviewed by Brandon Williams for CASSANDRA-17491
This is an automated email from the ASF dual-hosted git repository. erickramirezau 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 700ff74c WEBSITE - Added spaces in Community page Dev slack section patch by Erick Ramirez; reviewed by Brandon Williams for CASSANDRA-17491 700ff74c is described below commit 700ff74c4de50e230b0b8ccbaaa6e051a9e4895a Author: Erick Ramirez AuthorDate: Wed Jun 1 07:30:04 2022 + WEBSITE - Added spaces in Community page Dev slack section patch by Erick Ramirez; reviewed by Brandon Williams for CASSANDRA-17491 --- site-content/source/modules/ROOT/pages/community.adoc | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/site-content/source/modules/ROOT/pages/community.adoc b/site-content/source/modules/ROOT/pages/community.adoc index 0a3e84a9..605538ef 100644 --- a/site-content/source/modules/ROOT/pages/community.adoc +++ b/site-content/source/modules/ROOT/pages/community.adoc @@ -182,16 +182,22 @@ To participate and join the following channels. [.btn] https://s.apache.org/slack-invite[Sign up for a Slack account,window=blank] + + Strictly for questions or discussions related to Cassandra development. [.btn] https://app.slack.com/client/T4S1WH2J3/CK23JSY2K[#cassandra-dev,window=blank] + + Results of automated test builds. [.btn] https://app.slack.com/client/T4S1WH2J3/CS6CA748J[#cassandra-builds,window=blank] + + Results of patch test builds. [.btn] @@ -433,4 +439,4 @@ Aleksey Yeschenko, Alex Petrov, Aaron Morton, Anthony Elder, Ariel Weisberg, Bla -- -// end meet communityh \ No newline at end of file +// end meet communityh - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17672) WEBSITE - June 2022 blog "Apache Cassandra Changelog #16"
[
https://issues.apache.org/jira/browse/CASSANDRA-17672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544892#comment-17544892
]
Erick Ramirez commented on CASSANDRA-17672:
---
I’ve completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch ‘asf-site’ set up to track remote branch ‘asf-site’ from ‘origin’.
Switched to a new branch ‘asf-site’
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at 68a1b82a generate docs for ae4a90ca
$ git push -f origin asf-site
Username for ‘https://github.com’: erickramirezau
Password for ‘https://erickramire...@github.com’:
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/apache/cassandra-website.git
+ 20a02133...68a1b82a asf-site -> asf-site (forced update){noformat}
The blog post is now live on the site –
https://cassandra.apache.org/_/blog/Apache-Cassandra-Changelog-16-June-2022.html
> WEBSITE - June 2022 blog "Apache Cassandra Changelog #16"
> -
>
> Key: CASSANDRA-17672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17672
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: NA
>
> Attachments: c17672-01-blog_index.png, c17672-02-blog_post.png
>
>
> This ticket is to capture the work associated with publishing the May 2022
> blog "Apache Cassandra Changelog #16"
> If this blog cannot be published by the *June 2, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
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 (20a02133 -> 68a1b82a)
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard 20a02133 generate docs for c01fd28b
add ae4a90ca BLOG - Changelog #16
add 68a1b82a generate docs for ae4a90ca
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 (20a02133)
\
N -- N -- N refs/heads/asf-site (68a1b82a)
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:
.../blog/apache-cassandra-world-party-logo.png | Bin 0 -> 162197 bytes
content/_/blog.html| 24
...> Apache-Cassandra-Changelog-16-June-2022.html} | 121 +
content/search-index.js| 2 +-
.../blog/apache-cassandra-world-party-logo.png | Bin 0 -> 162197 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +
.../Apache-Cassandra-Changelog-16-June-2022.adoc | 113 +++
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
8 files changed, 216 insertions(+), 69 deletions(-)
create mode 100644 content/_/_images/blog/apache-cassandra-world-party-logo.png
copy content/_/blog/{Apache-Cassandra-Changelog-15-May-2022.html =>
Apache-Cassandra-Changelog-16-June-2022.html} (61%)
create mode 100644
site-content/source/modules/ROOT/images/blog/apache-cassandra-world-party-logo.png
create mode 100644
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-Changelog-16-June-2022.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544851#comment-17544851
]
Berenguer Blasi commented on CASSANDRA-17667:
-
I would first try to see why it doesn't fail on pre 4.0. As relying on regexp
to detect comments on non-parsed CQL sounds like trouble. I don't understand
why it worked pre 4.0 tbh.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
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 (fa2e920f -> 68a1b82a)
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 fa2e920f generate docs for ae4a90ca new 68a1b82a generate docs for ae4a90ca 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 (fa2e920f) \ N -- N -- N refs/heads/asf-staging (68a1b82a) 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 4740078 -> 4740078 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] [Comment Edited] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544812#comment-17544812
]
Attila Homoki edited comment on CASSANDRA-17667 at 6/1/22 11:03 AM:
No worries [~bereng] :)
Yes, the culprit is the {{strip_comment_blocks}} function which been committed
to {{cqlsh.py}} in 2020 :
[https://github.com/apache/cassandra/commit/1b1b87cfe3a9a93c393d1f3c1e003394260edeb5]
and the function hasn't been changed since it was introduced.
This is the original JIRA: https://issues.apache.org/jira/browse/CASSANDRA-15802
This is the code part which causing the problem:
{code:java}
if '/*' in result:
result = re.sub('[/][*].*', "", result)
in_comment = True
if '*/' in result:
result = re.sub('.*[*][/]', "", result){code}
As a fix, I'm thinking about modifying the above part to prevent the
replacements of the "/{*}" or "{*}/" if these are found in single quote
enclosed string literals.
Any thoughts?
was (Author: JIRAUSER289805):
No worries [~bereng] :)
Yes, the culprit is the {{strip_comment_blocks}} function which been committed
to {{cqlsh.py}} in 2020 :
[https://github.com/apache/cassandra/commit/1b1b87cfe3a9a93c393d1f3c1e003394260edeb5]
and the function hasn't been changed since it was introduced.
This is the original JIRA: https://issues.apache.org/jira/browse/CASSANDRA-15802
This is the code part which causing the problem:
{code:java}
if '/*' in result:
result = re.sub('[/][*].*', "", result)
in_comment = True
if '*/' in result:
result = re.sub('.*[*][/]', "", result){code}
As a fix, I'm thinking about modifying the above part to prevent the
replacements of the "/*" or "*/" if these are found in single quote enclosed
string literals.
Any thoughts?
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544812#comment-17544812
]
Attila Homoki commented on CASSANDRA-17667:
---
No worries [~bereng] :)
Yes, the culprit is the {{strip_comment_blocks}} function which been committed
to {{cqlsh.py}} in 2020 :
[https://github.com/apache/cassandra/commit/1b1b87cfe3a9a93c393d1f3c1e003394260edeb5]
and the function hasn't been changed since it was introduced.
This is the original JIRA: https://issues.apache.org/jira/browse/CASSANDRA-15802
This is the code part which causing the problem:
{code:java}
if '/*' in result:
result = re.sub('[/][*].*', "", result)
in_comment = True
if '*/' in result:
result = re.sub('.*[*][/]', "", result){code}
As a fix, I'm thinking about modifying the above part to prevent the
replacements of the "/*" or "*/" if these are found in single quote enclosed
string literals.
Any thoughts?
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17670) Flaky CompactStorageTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544803#comment-17544803 ] Andres de la Peña commented on CASSANDRA-17670: --- Great, looks good to me, +1 > Flaky CompactStorageTest > > > Key: CASSANDRA-17670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17670 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1.x, 4.x > > > CompactStorageTest has been showing flaky behavior mainly due to timeouts > such as > [here|https://ci-cassandra.apache.org/job/Cassandra-4.1/43/testReport/org.apache.cassandra.cql3.validation.operations/CompactStorageTest/testAlterWithCompactNonStaticFormat/] -- This message was sent by Atlassian Jira (v8.20.7#820007) - 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 (967a6f00 -> fa2e920f)
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 967a6f00 generate docs for ae4a90ca new fa2e920f generate docs for ae4a90ca 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 (967a6f00) \ N -- N -- N refs/heads/asf-staging (fa2e920f) 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 4740078 -> 4740078 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-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544787#comment-17544787
]
Berenguer Blasi commented on CASSANDRA-17667:
-
Apologies [~ahomoki] I hadn't noticed you had picked up this one as I hadn't
refreshed the page. I started looking and the problem is in
{{cqlsh.py#strip_comment_blocks}}. I haven't traced the diffs across versions
to see what changed though. Let me know if you don't have the time and I'll
take over. I just wanted to spare some duplicate work by sharing my findings :-)
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17667:
---
Assignee: Attila Homoki (was: Berenguer Blasi)
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Attila Homoki
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17667:
---
Assignee: Berenguer Blasi (was: Attila Homoki)
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.1.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17661) Adding support to perform certificate based internode authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544770#comment-17544770 ] Jyothsna Konisa commented on CASSANDRA-17661: - Link to the CI: https://app.circleci.com/pipelines/github/jyothsnakonisa/cassandra?branch=internode-auth&filter=all > Adding support to perform certificate based internode authentication > > > Key: CASSANDRA-17661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17661 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > Changes are to be made in IInternodeAuthenticator interface to support > certificate based authentication and to add a new pipeline in > InboundConnectionInitiator should be added to perform certificate based > authentication for internode communications. -- This message was sent by Atlassian Jira (v8.20.7#820007) - 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 (493d3de5 -> 967a6f00)
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 493d3de5 generate docs for ae4a90ca new 967a6f00 generate docs for ae4a90ca 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 (493d3de5) \ N -- N -- N refs/heads/asf-staging (967a6f00) 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 4740078 -> 4740078 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-17601) IllegalStateException with prepared queries selecting static columns in mixed 3.0.x/4.x clusters
[
https://issues.apache.org/jira/browse/CASSANDRA-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544755#comment-17544755
]
Benjamin Lerer commented on CASSANDRA-17601:
Sorry [~jonmeredith] I was busy with some other tasks. I will have a look at it
this week.
> IllegalStateException with prepared queries selecting static columns in mixed
> 3.0.x/4.x clusters
>
>
> Key: CASSANDRA-17601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17601
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Consistency/Coordination
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta, 4.x
>
>
> Clusters that contain prepared statements that partially select static
> columns before the upgrade will fail to execute those statements coordinated
> from the 4.x nodes until the upgrade completes.
> h2. Reproduction
> Setup (before upgrade)
> {code:java}
> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor':3}
> CREATE TABLE ks1.tbl1 (pk1 int,
> ck2 int,
> s3 int static,
> s4 int static,
> c5 int,
> PRIMARY KEY (pk1, ck2));
> INSERT INTO ks1.tbl1 (pk1, ck2, s3, s4, c5) VALUES (1, 2, 3, 4, 5);
> {code}
> Prepared Statement (prepare before upgrade)
> {code:java}
> SELECT c5, s3 FROM ks1.tbl1 WHERE pk1 = ? AND ck2 = ?;
> {code}
> Exception on 3.0.x nodes (when executing prepared statement after upgrade)
> {code:java}
> java.lang.IllegalStateException: [s3, s4] is not a subset of [s3] at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:566)
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:498)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializeRowBody(UnfilteredSerializer.java:235)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:209)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:141)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:129)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:140)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:95)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:80)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:191)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:181)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:177)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:335)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:91)
> at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:77)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:93)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:44)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> Exception on 4.0.x nodes (when executing prepared statement after upgrade)
> {code:java}
> java.lang.IllegalStateException: [ColumnDefinition{name=s3,
> type=org.apache.cassandra.db.marshal.IntType, kind=STATIC, position=-1},
> ColumnDefinition{name=s4, type=org.apache.cassandra.db.marshal.IntType,
> kind=STATIC, position=-1}] is not a subset of [s3]
> at org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:555)
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:487)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializeRowBody(UnfilteredSerializer.java:216)
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(Unfil
[jira] [Commented] (CASSANDRA-17602) sstableloader not respecting conf-path flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544752#comment-17544752
]
Stefan Miklosovic commented on CASSANDRA-17602:
---
[~brandon.williams] [~e.dimitrova] I rewrote the patch, I am catching all
exceptions which may happen in init method in loader and I am reacting in the
tests accordingly. So now it does not matter what environment we are testing it
in and exception handling in the code is more solid. Would you please take a
second look?
[https://github.com/apache/cassandra/pull/1632/files]
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1745/]
[https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-17602]
> sstableloader not respecting conf-path flag
> ---
>
> Key: CASSANDRA-17602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17602
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Aswin Karthik
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello,
> sstableloader does not seem to respect the config file flag (-f) and the
> storage port flag.
>
> We run our cluster on a different storage port with encryption. We construct
> a YAML with {{server_encryption_options}} and {{client_encryption_options}}
> and pass the storage port flag (both {{-sp}} and {{-ssp}}).
>
> However, we noticed that both the storage port flag and encryption settings
> are getting picked from the default config file {{conf/cassandra.yaml}} and
> ends up connecting to 7000 port unencrypted. As a workaround, we have added
> the storage port configuration to the YAML and copy our configuration file
> and overwrite the {{conf/cassandra.yaml}} and it is working now.
>
> Also to be noted that using the {{-f}} works in Cassandra 3.x. The bug seems
> to be present in 4.x versions only.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17670) Flaky CompactStorageTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544745#comment-17544745 ] Berenguer Blasi commented on CASSANDRA-17670: - Hi [~adelapena]100 green repeats for a total of 8.3K tests run [here|https://app.circleci.com/pipelines/github/bereng/cassandra/671/workflows/f3da43b0-acf0-4df6-9feb-04ae07919e12/jobs/5990] > Flaky CompactStorageTest > > > Key: CASSANDRA-17670 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17670 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1.x, 4.x > > > CompactStorageTest has been showing flaky behavior mainly due to timeouts > such as > [here|https://ci-cassandra.apache.org/job/Cassandra-4.1/43/testReport/org.apache.cassandra.cql3.validation.operations/CompactStorageTest/testAlterWithCompactNonStaticFormat/] -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
