[
https://issues.apache.org/jira/browse/SOLR-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683191#action_12683191
]
Marc Sturlese commented on SOLR-1070:
-------------------------------------
Yes, I saw it uses CommitUpdateCommand, wich executes a commit from
DirectUpdateHandler2.java. Haven't tried to index via xml with tomcat.
Seems that some code is not decrementing the reference decref() from
SolrIndexSearcher once it's done
> 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.
