[ 
https://issues.apache.org/jira/browse/SOLR-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-2991:
---------------------------

    Affects Version/s: 3.1
                       3.2
                       3.3
                       3.4
                       3.5
                       3.6
                       3.6.1
        Fix Version/s:     (was: 4.0)

removing fixVersion=4.0 since the entire point of this issue is that it was 
spun off from SOLR-2654 where the underlying bug was already fixed in the 4.x 
branch.

this issue remains open should someone choose to tackle it on the 3x branch
                
> In 3X, <lockType/> not used consistently in all places Directory objects are 
> instantiated
> -----------------------------------------------------------------------------------------
>
>                 Key: SOLR-2991
>                 URL: https://issues.apache.org/jira/browse/SOLR-2991
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.6.1
>            Reporter: Mark Miller
>            Priority: Minor
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to