[
https://issues.apache.org/jira/browse/CASSANDRA-21539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111019#comment-18111019
]
Stefan Miklosovic edited comment on CASSANDRA-21539 at 9/3/26 8:48 AM:
-----------------------------------------------------------------------
system.peers_v2 is on disk and removal of that would be way more challenging,
here only clients who read that are potentially affected. Given the arguments
in this ticket that mere presence of this column in that vtable could
destabilize other systems, I am of an opinion that its removal beats the
argument for keeping it there. We can definitely improve the situation by e.g.
commenting on this change in NEWS.txt in Upgrading section.
If you insist on keeping that column there, what we could do is to gate its
presence by a system property, by default set to true, meaning that column
would be visible, and in trunk I would set it to false (not visible by
default). If even that is not enough, then we would have that system property
set to true everywhere and it would be up to an operator to explicitly disable
it.
I think this is the only way forward to be able to not have it in that table if
people find its presence risky enough. I was also suggesting other approaches
like caching it internally in Cassandra but that yields its own problems. Other
ideas always welcome though. I find it too harsh to dedicate a completely new
table for this, that would be even more confusing. I get the argument for _v2
tables which are on disk but for this it seems to be an overkill.
I will try to find the evidence for what I said that vtables are a bit relaxed.
I would like to have these things clarified once for all, I do not think we
have ever formally codified what a public API is and it seems to be an ongoing
argument.
was (Author: smiklosovic):
system.peers_v2 is on disk and removal of that would be way more challenging,
here only clients who read that are potentially affected. Given the arguments
in this ticket that mere presence of this column in that vtable could
destabilize other systems, I am of an opinion that its removal beats the
argument for keeping it there. We can definitely improve the situation by e.g.
commenting on this change in NEWS.txt in Upgrading section.
If you insist on keeping that column there, what we could do is to gate its
presence by a system property, by default set to true, meaning that column
would be visible, and in trunk I would set it to false (not visible by
default). If even that is not enough, then we would have that system property
set to true everywhere and it would be up to an operator to explicitly disable
it.
I think this is the only way forward to be able to not have it a table if
people find its presence risky enough. I was also suggesting other approaches
like caching it internally in Cassandra but that yields its own problems. Other
ideas always welcome though. I find it too harsh to dedicate a completely new
table for this, that would be even more confusing. I get the argument for _v2
tables which are on disk but for this it seems to be an overkill.
I will try to find the evidence for what I said that vtables are a bit relaxed.
I would like to have these things clarified once for all, I do not think we
have ever formally codified what a public API is and it seems to be an ongoing
argument.
> 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]
