[
https://issues.apache.org/jira/browse/CASSANDRA-21539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111183#comment-18111183
]
David Capwell commented on CASSANDRA-21539:
-------------------------------------------
bq. here only clients who read that are potentially affected
Yes, this is how we discovered this change; we were affected.
bq. I am of an opinion that its removal beats the argument for keeping it there
That goes against the rules for such removal and require a dev ML thread with
consensus to do. The process today is to depreciate and remove in 7.0 or 8.0
bq. Given the arguments in this ticket that mere presence of this column in
that vtable could destabilize other systems
it only destabilize because it resolves, we don't need to resolve to keep us
stable. Ariel was also a fan of making the behavior a config; I am not though
(won't block, I just don't see the value, think his configs are don't resolve,
null, or resolve).
We also should create check style as this isn't the first time this DNS lookup
has hit us; its been a issue in the past with inet type... its way too easy to
do the wrong thing.
bq. I get the argument for _v2 tables which are on disk but for this it seems
to be an overkill.
I strongly disagree here; no user cares about disk or not... it's a public API.
We as a project have not created such a process to allow breaking changes to
vtables; they are part of the public API and go through the same process as all
other public API changes.
bq. I will try to find the evidence for what I said that vtables are a bit
relaxed,
Please do share. I searched the full ML history and can not find any evidence,
only strong opinions about not breaking apis and that vtables are part of the
public api.
bq. 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.
We are in agreement here, It would be good to have a real clear way to point
to. It seems very clear to me with regard to what's in CQL layer, but when it
comes to the java code its very hard... we have a lot of ways we can and should
improve this
> 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]
