lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [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
Date Tue, 06 Dec 2016 22:09:58 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message