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.

On Wed, Aug 5, 2015 at 1:54 PM, Robert Krüger <krue...@lesspain.de> wrote:

> Hi,
>
> for months/years, I have been experiencing occasional very long (30s+)
> hangs when programmatically initializing a solr container in Java. The
> application has worked for years in production with this setup without any
> problems apart from this.
>
> The code I have is this here:
>
>  public void initContainer(File solrConfig) throws Exception {
>             logger.debug("initializing solr container with config {}",
> solrConfig);
>             Preconditions.checkNotNull(solrConfig);
>             Stopwatch stopwatch = Stopwatch.createStarted();
>             container =
> CoreContainer.createAndLoad(solrConfig.getParentFile().getAbsolutePath(),
> solrConfig);
>             containerInitialized = true;
>             logger.debug("initializing solr container took {}", stopwatch);
>             if (stopwatch.elapsed(TimeUnit.MILLISECONDS) > 1000) {
>                 logger.warn("initializing solr container took very long
> ({})", stopwatch);
>             }
>         }
>
> So it is obviously the createAndLoad-Call. I posted about this a long time
> ago and people suggested checking for uncommitted soft commits but now I
> realized that I had these hangs in a test setup, where the index is created
> from scratch, so that cannot be the problem.
>
> Any ideas anyone?
>
> My config is rather simple. Is there something wring with my locking
> options that might cause this?
>
> <config>
>
>   <indexConfig>
>     <lockType>native</lockType>
>     <unlockOnStartup>true</unlockOnStartup>
>     <ramBufferSizeMB>64</ramBufferSizeMB>
>     <maxBufferedDocs>1000</maxBufferedDocs>
>   </indexConfig>
>
>   <luceneMatchVersion>LUCENE_43</luceneMatchVersion>
>
>   <updateHandler class="solr.DirectUpdateHandler2">
>     <autoCommit>
>        <maxDocs>1000</maxDocs>
>        <maxTime>10000</maxTime>
>        <openSearcher>false</openSearcher>
>     </autoCommit>
>   </updateHandler>
>
>   <requestDispatcher handleSelect="true" >
>     <requestParsers enableRemoteStreaming="false"
> multipartUploadLimitInKB="2048" />
>   </requestDispatcher>
>
>   <requestHandler name="standard" class="solr.StandardRequestHandler"
> default="true" />
>   <requestHandler name="/update" class="solr.UpdateRequestHandler" />
>   <requestHandler name="/admin/"
> class="org.apache.solr.handler.admin.AdminHandlers" />
>
>   <filterCache class="solr.LRUCache" size="512" initialSize="512"
> autowarmCount="256"/>
>   <queryResultCache class="solr.LRUCache" size="512" initialSize="512"
> autowarmCount="256"/>
>   <documentCache class="solr.LRUCache" size="10000" initialSize="512"
> autowarmCount="0"/>
>
>   <admin>
>     <defaultQuery>solr</defaultQuery>
>   </admin>
>
> </config>
>
> Thank you in advance,
>
> Robert
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Reply via email to