[
https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-2654:
------------------------------
Attachment: SOLR-2654.patch
first rough patch -
TestReplicationHandler does not pass -
doTestReplicateAfterWrite2Slave causes any of the other replication tests run
after it to fail. Commenting it out, all tests pass.
This allows us to use the same dir instance everywhere (kind of important - we
hacked around this for ram dir specifically by using a static cache - mainly
for tests).
It does kind of make it so you must use the new approved SolrCore reload method
rather than just starting a new clore and closing the old one. But you really
should do that anyhow, so...and it's better than using a static cache IMO.
> <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
>
> Attachments: 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
