[ 
https://issues.apache.org/jira/browse/SOLR-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18077673#comment-18077673
 ] 

Jason Gerlowski commented on SOLR-18218:
----------------------------------------

There may be better approaches, but two strawman approaches here come to mind:
- Modify our ExecutorUtil methods to take in a "pool name" parameter that can 
be included in log messages where appropriate.
- Modify our ExecutorService implementations to take in a "pool name" at 
creation time.  Modify toString() to include this poolName.

It might also be worth exploring whether the ExecutorService toString() could 
print the name of the "active threads", though that may be tricky or overly 
verbose in some situations...

> Improve ExecutorUtil error logging
> ----------------------------------
>
>                 Key: SOLR-18218
>                 URL: https://issues.apache.org/jira/browse/SOLR-18218
>             Project: Solr
>          Issue Type: Improvement
>          Components: Server
>    Affects Versions: main(11.0)
>            Reporter: Jason Gerlowski
>            Priority: Minor
>
> On a graceful shutdown Solr's CoreContainer.shutdown method attempts to 
> shutdown a number of 'ExecutorService' (i.e. threadpool) instances.
> In most cases, Solr waits 60 seconds for each threadpool to shutdown.  If 
> threads are still running after this timeout Solr will log an error message 
> (see below) and then attempt a more forceful shutdown of the ExecutorService.
> {code}
> Threads from pool 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor@769b724c[Shutting
>  down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 
> 4] did not forcefully stop.
> {code}
> This message is great as far as it goes but it could be better.  
> Particularly, it doesn't tell admins or other debuggers *which* 
> ExecutorService was having trouble shutting down.  Was it the "async task 
> executor"?  The core-loader? The index-fingerprinter?  The "customThreadPool" 
> that we create specifically during the shutdown process?  Something else?
> A better error message here would save admins debugging shutdown hangs or 
> slowness a ton of work narrowing things down.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to