[
https://issues.apache.org/jira/browse/CASSANDRA-21539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110866#comment-18110866
]
David Capwell edited comment on CASSANDRA-21539 at 9/2/26 8:47 PM:
-------------------------------------------------------------------
This patch makes a breaking change to our public API and back ported to 4.x+
with the intent to release in a patch release; this breaks our process for
these types of changes, [~brandon.williams] / [~smiklosovic] can you revert
before we try to schedule any releases?
bq. I think we established a long time ago that system views are free to be
changed / follow different / relaxed path than system tables on disk, that is
why we just want to nuke it here
I can not find any evidence of this, only the opposite. Are there any ML
threads you can link to back up this statement? The best 2 threads I can see
are
- "Discuss CASSANDRA-16999 introduction of a column in system.peers_v2" - this
argues we should not break public api
- "DISCUSS How we version our releases" this says dev@ ML thread + deprecate +
min(2 releases, 1 year)... and even this gets pushback arguing not to break the
public api "would hugely break trust if we just decided 'well technically it's
a major release so we removed this thing'"
was (Author: dcapwell):
This patch makes a breaking change to our public API and back ported to 4.x+
with the intent to release in a patch release; this breaks our process for
these types of changes, [~brandon.williams] / [~smiklosovic] can you revert
before we try to schedule any releases?
.bq I think we established a long time ago that system views are free to be
changed / follow different / relaxed path than system tables on disk, that is
why we just want to nuke it here
I can not find any evidence of this, only the opposite. Are there any ML
threads you can link to back up this statement? The best 2 threads I can see
are
- "Discuss CASSANDRA-16999 introduction of a column in system.peers_v2" - this
argues we should not break public api
- "DISCUSS How we version our releases" this says dev@ ML thread + deprecate +
min(2 releases, 1 year)... and even this gets pushback arguing not to break the
public api "would hugely break trust if we just decided 'well technically it's
a major release so we removed this thing'"
> Querying system_views.clients causes a DNS lookup for each unique connected
> client address
> ------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21539
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
> Reporter: Nivy Kani
> Assignee: Nivy Kani
> Priority: Normal
> Fix For: 4.0.22, 4.1.13, 5.0.10, 6.0-alpha3, 7.0
>
> Attachments: 4.0-ci_summary.html, 4.0-result_details.tar.gz.zip,
> 5.0-ci_summary.html, 5.0-result_details.tar.gz, 6.0-ci_summary.html,
> 6.0-result_details.tar.gz, ci_summary-1.html, ci_summary.html,
> result_details.tar-1.gz, result_details.tar.gz
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> It looks like queries to the system_views.clients table does a DNS lookup for
> each unique address:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/virtual/ClientsTable.java#L91
>
> Given Java's internal DNS caches, this is really only potentially slow on the
> first query, but we should avoid doing DNS lookups here as a workflow that
> queries this table on each node to collect client information could
> potentially overwhelm DNS this way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
