[
https://issues.apache.org/jira/browse/SOLR-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-915:
-------------------------------
Attachment: SOLR-915.patch
How do you feel about this version?
Rather then make a public static function on CoreContainer -- it has a package
protected member.
-------
Looking over this again, I don't see how this helps the problem of having lots
of cores. If I follow correctly, this just helps if you have logs of long
running shutdown hooks.
If you call core1.close(), core2.close() sequentially it will still block for
one to finish before core2...
Do we we really want the parallel part in CoreContainer.shutdown()?
> 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
> Assignee: Ryan McKinley
> Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-915.patch, SOLR-915.patch, 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.
