[
https://issues.apache.org/jira/browse/SOLR-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675252#comment-13675252
]
Alexander Kanarsky commented on SOLR-2991:
------------------------------------------
While I agree that this is a minor issue since the index readers/searchers
should not be directly using lock factory set, it makes sense to have a
consistent lock types between readers and writers. Proposed patch seems to fix
the problem, it just ensures the proper lock factory is set after the opening
of the Directory. I reused the static method in SolrIndexWriter, but since the
method does not really belongs to the SolrIndexWriter it could be shared
between readers and writers.
> 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
> Attachments: SOLR-2991.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.
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]
