[ 
https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080687#comment-13080687
 ] 

Mark Miller commented on SOLR-2654:
-----------------------------------

So I removed the close directories hack for tests and realized that I need the 
solution I proposed above regardless - when we force open a new directory, we 
need to close the old one - because we replace it in the map (well, close it, 
or keep it around in another list/set). We cannot close it right then, because 
something still might be using it. The ref cnt dir is def coming back.

> <lockType/> not used consistently in all places Directory objects are 
> instantiated
> ----------------------------------------------------------------------------------
>
>                 Key: SOLR-2654
>                 URL: https://issues.apache.org/jira/browse/SOLR-2654
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>            Assignee: Mark Miller
>             Fix For: 3.4, 4.0
>
>         Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch
>
>
> nipunb noted on the mailing list then when configuring solr to use an 
> alternate <lockType/> (ie: simple) the stats for the SolrIndexSearcher list 
> NativeFSLockFactory being used by the Directory.
> The problem seems to be that SolrIndexConfig is not consulted when 
> constructing Directory objects used for IndexReader (it's only used by 
> SolrIndexWriter)
> I don't _think_ this is a problem in most cases since the IndexReaders should 
> all be readOnly in the core solr code) but plugins could attempt to use them 
> in other ways.  In general it seems like a really bad bug waiting to happen.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to