[
https://issues.apache.org/jira/browse/SOLR-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505218#comment-14505218
]
Ramkumar Aiyengar commented on SOLR-7361:
-----------------------------------------
Sorry for the late feedback.
My concern with this approach is that this can be trappy for client code. When
you are developing/testing, you might always have the cores up and running by
the time you issue requests -- and then the edge case will be exposed one day
on production when slow disk IO or a bad GC pause strikes..
If we are breaking compat anyway, why not always break it (instead of in some
cases outside developer control -- which imo is no better) and return
immediately without sleeping? In any case, at the very minimum, we would want
to do that in our tests so that we account for that situation..
> 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: Mark Miller
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7361.patch, 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
