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

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

Okay, looks like i am close to having this figured out - I changed tactics to 
do the ref counting in the dir factory, and then having the user release the 
directory. For whatever reason, this made things easier to debug. I found an 
issue I had that was making the previous attempt difficult, and also what looks 
like a nasty bug (more to come) that was compounding the issue. Still a fair 
amount to try and do to finish this off as I want, but making progress.

> <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, 
> 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