[jira] [Resolved] (SOLR-5043) hostname lookup in SystemInfoHandler should be refactored so it's possible to not block core (re)load for long periouds on misconfigured systems

["Hoss Man (JIRA)" <ji...@apache.org>]

     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org