[
https://issues.apache.org/jira/browse/SOLR-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656679#action_12656679
]
Kay Kay commented on SOLR-915:
------------------------------
Yes- We are having a system with multiple cores , for different (Lucene)
indexes in memory . Also - we have a much less-frequent writer and
high-frequency multiple readers for the same directory.
The tests that I have run uses threadpools ( FixedPools for now). We also a
couple of custom handlers , that are SolrCoreAware , that adds closehooks (
addCloseHook() in SolrCore ) through the inform method. The closehooks do some
io heavylifting - which I believe has scope to be exploited. Solr, as much as
being a server, also serves the purpose of an API , for custom request handlers
to be extended. So - my concern here is that the close() for a single SolrCore
instance also takes significant importance, even though it is all about
unwinding resource acquisition.
ps: I am not a big fan of running multiple SolrCore on a single app server
since architecturally (also from the point of deploying it ) - it is not
intuitive / scalable. But until we move towards separating out - this is
something we need to live with.
> 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
> Environment: Tomcat 6, JRE 6
> Reporter: Kay Kay
> 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.
