[
https://issues.apache.org/jira/browse/SOLR-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656752#action_12656752
]
Ryan McKinley commented on SOLR-915:
------------------------------------
Overall looks reasonable...
But I'm weary of adding static classes (we just spent so much time getting rid
of them!)
Rather then adding a static SolrExecutor class, perhaps we could add a
"getExecutor()" method to to CoreContainer? This would allow it to be modified
if necessary. It would also allow it to be loaded lazily so it does not affect
the memory footprint (not sure that is a big deal or not)
> SolrCore;close() - scope to exploit parallelism among the number of
> closeHooks
> --------------------------------------------------------------------------------
>
> Key: SOLR-915
> URL: https://issues.apache.org/jira/browse/SOLR-915
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Tomcat 6, JRE 6
> Reporter: Kay Kay
> Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-915.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> In SolrCore: close() - all the way towards the end of the function - there
> seems to be a sequential list of close method invocation.
> if( closeHooks != null ) {
> for( CloseHook hook : closeHooks ) {
> hook.close( this );
> }
> }
> I believe this has scope to be parallelized ( actually the entire sequence of
> close operations , updateHandler,close() etc.) - by means of launching them
> in separate threads from an ExecutorService , for a much faster shutdown as
> the process definitely does not need to be sequential.
> This becomes all the more important in the multi-core context when we might
> want to shutdown and restart a SolrCore altogether.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
