You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the event of short TTL for DNS names, we should either cache or asynchronously update DNS entries for masters to avoid excessive refetch or possible delays in resolution.
Example:
W0314 17:07:21.496300 26257 yb_rpc.cc:274] Call yb.tserver.TabletServerService.Read 35.241.224.95:49083 => 172.24.16.4:7100 (request call id 1508417) took 4176ms (client timeout 2499ms).
W0314 17:07:22.156210 26356 net_util.cc:192] Time spent resolving address for xxx-yug-202.xxxxxx.xx: real 0.253s user 0.000s sys 0.000s
W0314 17:07:22.425374 23827 net_util.cc:192] Time spent resolving address for xxx-yug-241.xxxxxx.xx: real 0.266s user 0.000s sys 0.000s
W0314 17:07:22.827749 23826 net_util.cc:192] Time spent resolving address for xxx-yug-221.xxxxxx.xx: real 0.275s user 0.000s sys 0.000s
The text was updated successfully, but these errors were encountered:
…nd system.local tables
Summary:
While serving request to system.peers or system.local tables we are doing DNS resolution,
to convert hostname to IP address.
This diff adds parallel DNS resolution in this scenario.
So when DNS resolution takes significant time, those times would not add.
Test Plan: Jenkins
Reviewers: mihnea, robert, mikhail
Reviewed By: mikhail
Subscribers: bogdan, ybase, bharat
Differential Revision: https://phabricator.dev.yugabyte.com/D6409
In the event of short TTL for DNS names, we should either cache or asynchronously update DNS entries for masters to avoid excessive refetch or possible delays in resolution.
Example:
The text was updated successfully, but these errors were encountered: