[
https://issues.apache.org/jira/browse/SOLR-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490391#comment-14490391
]
Shawn Heisey commented on SOLR-7361:
------------------------------------
I like the idea of having access to the admin UI responsive immediately on
startup ... if nothing else, to be able to see the progress of the startup.
Obviously any requests to cores that are not yet started must fail, but cores
that have started, as well as any functionality that doesn't depend on core
startup, should work.
There's probably more to think about and tweak. During startup, CoreAdmin and
CollectionsAdmin requests will require careful vetting. My thought here is
that about the only operation that should be allowed on things that haven't yet
started is DELETE, if we can find a way to do so safely. If deleting a core
can remove it from the startup queue entirely, it's a slight optimization.
If we aren't already doing so, this will require that we enumerate all the
cores and/or the clusterstate before listening to any kind of request on
CoreAdmin/CollectionsAdmin.
A disabling property for tests is a good interim step, but I think that the
long term goal should be to modify both the async startup and the tests so
everything works right.
> Main Jetty thread blocked by core loading delays HTTP listener from binding
> if core loading is slow
> ---------------------------------------------------------------------------------------------------
>
> Key: SOLR-7361
> URL: https://issues.apache.org/jira/browse/SOLR-7361
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Timothy Potter
> Assignee: Timothy Potter
>
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
