Hi all,
I finally got some time to work on this - I created SOLR-17448, and opened
a draft PR here: https://github.com/apache/solr/pull/2707. Appreciate if
you have any comments/suggestions.
Thanks,
Andrey
(face-palm) -- you were very clear but I misread it; sorry Andrey!
I agree with what you propose / imply: code should *not* call submit()
if it ignores the returned Future; it misses the point of the submit
method! execute() should be used in that case. In fact I recently
proposed this very impr
Hi David,
In the example of SolrZkClient.ProcessWatchWithExecutor#process, it should
be possible to use ExecutorService#submit and ExecutorService#execute
methods interchangeably - because either method would run the task in the
background. So I went ahead and replaced `submit` with `execute`, and
I think it's a case-by-case matter. I don't think there's something
wrong with the Executor.submit method generally.
Looking at callers of CoreContainer.runAsync, I didn't find the core
reload use-case you speak of. I did find DistribFileStore.delete and
looked closer. I do see there's an issu
Hi Andrey,
It's hard to say how much this affects users in practice, but I agree
that it sounds concerning. Definitely worth auditing our existing
uses of 'submit' IMO.
Some cases might be tough to handle. If an API call is intentionally
queueing up an operation to run asynchronously and then r
Hi all,
I'd like to bring up for discussion how Solr handles failures of various
background tasks.
Typically with an ExecutorService, the task can be offloaded to a
background thread via `execute(...)` or `submit(...)` methods:
- if using `execute(Runnable)` method, any exception thrown by the t
