lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] [Commented] (SOLR-7361) Main Jetty thread blocked by core loading delays HTTP listener from binding if core loading is slow
Date Tue, 21 Apr 2015 17:17:59 GMT


Mark Miller commented on SOLR-7361:

bq. you might always have the cores up and running by the time you issue requests

Other requests will block until the core is ready - what will that break? That is how it works
now if requests come in before the cores are loaded. Do you have a concrete example?

bq. If we are breaking compat anyway, why not always break it

If the cores are just going to load quickly, I think it's simply nicer to wait for them to
load and only have outliers straggle in later, as the system did work. Unless there are outliers,
I think it's a nicer system experience. This is a simple simulation of that approach.

It doesn't matter how long that wait is - you can set it to 0 and all the tests will pass
fine. You can certainly randomly set that to 0 in test runs.

> Main Jetty thread blocked by core loading delays HTTP listener from binding if core loading
is slow
> ---------------------------------------------------------------------------------------------------
>                 Key: SOLR-7361
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>            Reporter: Timothy Potter
>            Assignee: Mark Miller
>             Fix For: Trunk, 5.2
>         Attachments: SOLR-7361.patch, SOLR-7361.patch, SOLR-7361.patch, SOLR-7361.patch,
> During server startup, the CoreContainer uses an ExecutorService to load cores in multiple
back-ground threads but then blocks until cores are loaded, see: CoreContainer#load around
line 290 on trunk (invokeAll). From the JavaDoc on that method, we have:
> {quote}
> Executes the given tasks, returning a list of Futures holding their status and results
when all complete. Future.isDone() is true for each element of the returned list.
> {quote}
> In other words, this is a blocking call.
> This delays the Jetty HTTP listener from binding and accepting requests until all cores
are loaded. Do we need to block the main thread?
> Also, prior to this happening, the node is registered as a live node in ZK, which makes
it a candidate for receiving requests from the Overseer, such as to service a create collection
request. The problem of course is that the node listed in /live_nodes isn't accepting requests
yet. So we either need to unblock the main thread during server loading or maybe wait longer
before we register as a live node ... not sure which is the better way forward?

This message was sent by Atlassian JIRA

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

View raw message