[
https://issues.apache.org/jira/browse/SOLR-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683209#action_12683209
]
Yonik Seeley commented on SOLR-1070:
------------------------------------
I haven't been able to reproduce any problem with normal XML update commands
(with multicore either)... seems likely related to DIH somehow.
Marc, what's the refCount on the core with too many searchers (check the admin
stats page)? It should be "2"... one because the core is in service, and one
for the request that is generating the stats page.
> IndexSearcher not closed after indexing with DataImportHandler
> --------------------------------------------------------------
>
> Key: SOLR-1070
> URL: https://issues.apache.org/jira/browse/SOLR-1070
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.4
> Environment: Debian 2.6.26-1-xen-amd64
> Tomcat 5.5
> Reporter: Marc Sturlese
> Fix For: 1.4
>
>
> What I have noticed is afecting to the nightly build using multicore. I am
> using tomcat 5.5 server and Debian 2.6.26-1-xen-amd64.
> After indexing and optimizing with DataImporthandler the old IndexSearcher is
> not being proper closed.
> To reproduce the bug I have done a full-import from a mysql database
> optimizing at the end. Once done I change the data from the database and
> index optimizing again.
> When now I do a lsof | grep solr I can see that tomcat is holding the deleted
> files from old index.
> I can see the error in the stats screen aswell... if I do 4 full-imports,
> stats will show me 3 opened IndexSearchers.
> As I index on the master and never use it to serve search requests I have
> sorted it modifying the function getSearcher in SolrCore.java
> There's a part in the source where is coded:
> // we are all done with the old searcher we used
> // for warming...
> if (currSearcherHolderF!=null){currSearcherHolderF.decref();}
> I force there to close the indexSearcher and remvoe it from the RefCounted:
> // we are all done with the old searcher we used
> // for warming...
> if (currSearcherHolderF!=null){
> currSearcherHolderF.get().close();
> currSearcherHolderF.decref();
> _searchers.remove();
> }
> As Yonik told me:
> >> Forcing it to close at the point you did is unsafe since other threads
> >> may still be using that searcher.
> My solution is definitely not good if search requests must be served on that
> core of that server...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
