I am shipping solr as a local search engine with our software, so I have no
way of controlling that environment. Many other software packages (rdbmss,
nosql engines etc.) work well in such a setup (as does solr except this
problem). The problem is that in this case (AFAICS) the host cannot be
overridden in any way (by config or system property or whatever), because
that handler is coded as it is. It is in no way a natural limitation of the
type of software or my use case. But I understand that this is probably not
frequently a problem for people, because by far most solr use is classic
server-based use.
I may suggest a patch on the devel mailing list.
On Wed, Aug 5, 2015 at 5:42 PM, Shawn Heisey <apa...@elyograg.org> wrote:
> On 8/5/2015 7:56 AM, Robert Krüger wrote:
> > OK, now that I had a reproducible setup I could debug where it hangs:
> >
> > public SystemInfoHandler(CoreContainer cc) {
> > super();
> > this.cc = cc;
> > init();
> > }
> >
> > private void init() {
> > try {
> > InetAddress addr = InetAddress.getLocalHost();
> > hostname = addr.getCanonicalHostName();
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is where it hangs
> > } catch (UnknownHostException e) {
> > //default to null
> > }
> > }
> >
> >
> > so it depends on my current network setup even for the embedded case. any
> > idea how I can stop solr from making that call?
> InetAddress.getLocalHost()
> > in this case returns some local vpn address and thus the reverse lookup
> > times out after 30 seconds. This actually happens twice, once when
> > initializing the container, again when initializing the core, so in my
> case
> > a minute per restart and looking at the code, I don't see how I can work
> > around this other than patching solr, which I am trying to avoid like
> hell.
>
> Because almost all users are using Solr in a mode where it requires the
> network, that code cannot be eliminated from Solr.
>
> It is critical that your machine's local network is set up completely
> right when you are running applications that are (normally)
> network-aware. Generally that means having relevant entries for all
> interfaces in your hosts file and making sure that the DNS resolver code
> included with the operating system is not buggy.
>
> If you're dealing with a VPN or something else where the address is
> acquired from elsewhere, then you need to make sure that the machine has
> at least two DNS servers configured, that one of them is working, and
> that the forward and reverse DNS on those servers are completely set up
> for that interface's IP address. Bugs in the DNS resolver code can
> complicate this.
>
> Thanks,
> Shawn
>
>
--
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG
www.lesspain-software.com
