[
https://issues.apache.org/jira/browse/SOLR-17645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17927306#comment-17927306
]
ASF subversion and git services commented on SOLR-17645:
--------------------------------------------------------
Commit ad9141e845677d3e4c59f5d16ffbbb2930103287 in solr's branch
refs/heads/branch_9x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=ad9141e8456 ]
SOLR-17645: Gracefully handle exceptions in executor threads (#3150)
* Gracefully handle exceptions in executor threads
* Use better map methods, catch exception when refreshing terms
(cherry picked from commit b73841db19ebf75e0b0ef752c708337340f7bfb7)
> Handle executor thread failures more gracefully
> -----------------------------------------------
>
> Key: SOLR-17645
> URL: https://issues.apache.org/jira/browse/SOLR-17645
> Project: Solr
> Issue Type: Bug
> Affects Versions: 9.8
> Reporter: Houston Putman
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of SOLR-17448, we use ExecutorService.execute() much more throughout the
> codebase. This is a good thing since before we weren't doing anything with
> the Future objects that ExecutorService.submit() would return.
> One drawback however, is that in our tests, we use randomizedTesting (the
> library) to listen for uncaught exceptions in threads. I believe the change
> to ExecutorService.execute() led to this, because there is no Future to
> return that an exception was thrown.
> Usually we do well in catching exceptions in our threads, but certainly not
> always. We should audit this, to improve error handling in our code as well
> as limit test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
