You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2011/08/04 19:18:28 UTC

[jira] [Commented] (SOLR-2654) not used consistently in all places Directory objects are instantiated

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

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

So the lock issue is not really a problem - but not sharing the dir is depending on the impl as I mentioned.

I first tried tackling this outside of the directory factory - this quickly gets very difficult, most due to the newIndexPath that replication uses to avoid copying a full index.

I'm now exploring simply have the base directory factory cache all directories with the path as a key - how the ram directory factory works now.

> <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
>            Priority: Critical
>             Fix For: 3.4
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org