[
https://issues.apache.org/jira/browse/SOLR-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-5043.
----------------------------
Resolution: Fixed
Assignee: Hoss Man
Fix Version/s: 6.4
master (7.0)
bq. Is anything keeping you from pushing this into one of the next updates?
Sorry -- i lost track of it and didn't see your previous comment verifying hat
the patch orked out for you.
bq. The only question I have is why you don't set the host name to the inet
address (or maybe even the result of getHostName?) in the case when the DNS
lookup is suppressed. ...
well, 2 reasons...
#1) conceptually, i don't like the idea of redefining what SystemInfoHandler
reports as the {{host}} value ... this has always ment "Either The Canonical
Hostname of null if it can't be determined" and I don't really like the idea
that _sometimes_ it's something else -- partciularly when the primary usecase
that might lead to "sometimes" is missconfigured DNS -- i don't want to give
users the impression "The (canonical) hostname of this solr node is {{foobar}}"
when {{foobar}} is just some locally configured hostname and that name can't
actaully be used to connect to the solr node.
Adding distinct SystemInfoHandler variables for the IP Addr, or (locally
configured) hostname might be conceptually ok -- but personally i don't see
much value, and leads me to...
#2) the way the InetAddress API is designed, just calling
{{InetAddress.getLocalHost()}} causes a DNS lookup to happen -- leading to the
whole potential long pause delay this issue was opened about (perhaps not
necessarily in the same misconfiguration situation you face, but it could in
other misconfiguration situations). Likewise, {{getHostName()}} will do a
reverse lookup in some situations if there isn't any locally configured
hostname.
The bottom line being: since the entire predicate for this issue is "Sometimes
people have badly configure DNS and/or hostname settings, and we should give
them a way to make life less painful" I didn't want to make too many
assumptions about the specific nature of _how_ their DNS and/or hostname
settings might be badly configured and/or introduce similar problems or more
complexity in just trying to get the IP addr.
> hostname lookup in SystemInfoHandler should be refactored so it's possible to
> not block core (re)load for long periouds on misconfigured systems
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-5043
> URL: https://issues.apache.org/jira/browse/SOLR-5043
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: master (7.0), 6.4
>
> 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]
