[
https://issues.apache.org/jira/browse/SOLR-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-5043:
---------------------------
Attachment: SOLR-5043.patch
bq. For situations like SOLR-7884 i think an advanced, seriously expert, system
property that says "hey solr, under no circumstances should you try to do any
DNS lookups because i know my DNS is busted" would be a good idea, and should
be implemented by a generic helper method for use both here and in the various
parts of the disributed update/search logic in the cloud code. (with forbidden
API checks to prevent any future code other then this helper method from doing
DNS related methods)
I spent a little time looking into this, and it appears to be somewhat
intractable. There are too many InetAddress methods that _may_ do reverse DNS
lookups under the covers to try and write our own wrappers and suppress direct
calls with forbidden-API -- particularly since many of those methods are the
same ones that just return the local hostname configuration if available (when
dealing with {{InetAddress.getLocalHost()}}) or the previously specified
hostname (when dealing with {{InetAddress.getByName(String)}})
So instead I punted on trying to solve the general problem of a sysprop to say
"Don't ever do any DNS lookups" and just kept the problem constrained to
sysprop that says "Don't ever do _this_ DNS lookup" .. leaving open the
possibility of refactoring it later if there are other places where we decide
we want it to apply as well.
Robert: can you try out this patch on a machine with a configuration you know
currently causes you long delays in starting up solr, and confirm you get a
helpful WARN message instructing you to set the
{{solr.dns.prevent.reverse.lookup}} .. and then test out adding that to your
startup params and confirm it eliminates the problem?
> hostanme lookup in SystemInfoHandler should be refactored to not block core
> (re)load
> ------------------------------------------------------------------------------------
>
> Key: SOLR-5043
> URL: https://issues.apache.org/jira/browse/SOLR-5043
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Attachments: SOLR-5043-lazy.patch, SOLR-5043.patch, SOLR-5043.patch
>
>
> SystemInfoHandler currently lookups the hostname of the machine on it's init,
> and caches for it's lifecycle -- there is a comment to the effect that the
> reason for this is because on some machines (notably ones with wacky DNS
> settings) looking up the hostname can take a long ass time in some JVMs...
> {noformat}
> // on some platforms, resolving canonical hostname can cause the thread
> // to block for several seconds if nameservices aren't available
> // so resolve this once per handler instance
> //(ie: not static, so core reload will refresh)
> {noformat}
> But as we move forward with a lot more multi-core, solr-cloud, dynamically
> updated instances, even paying this cost per core-reload is expensive.
> we should refactoring this so that SystemInfoHandler instances init
> immediately, with some kind of lazy loading of the hostname info in a
> background thread, (especially since hte only real point of having that info
> here is for UI use so you cna keep track of what machine you are looking at)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
