[jira] [Updated] (SOLR-5043) hostanme lookup in SystemInfoHandler should be refactored to not block core (re)load
[
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5043) hostanme lookup in SystemInfoHandler should be refactored to not block core (re)load
[
https://issues.apache.org/jira/browse/SOLR-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramkumar Aiyengar updated SOLR-5043:
Attachment: SOLR-5043-lazy.patch
Attached is a patch describing what I meant (untested)
> 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
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5043) hostanme lookup in SystemInfoHandler should be refactored to not block core (re)load
[
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
Here's a quick and drity patch that spins up background thread to resolve the
hostname.
in practice, this works fine -- startup and core reload times are short, and an
error eventually gets logged by the background thread if/when the JVM gives up
on resolving the hostname.
the hitch is: if we assume people might have bad DNS when running solr, we
should probably also assume they might have bad DNS when running solr tests.
As things stand on trunk today, that just means your tests run dog ass slow --
with this patch, the test will finish fast, but then the runner will fail
because it treats this background DNS thread as a leak.
probably need to figure out a better way of dealing with this.
> 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.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
