[
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
new patch - the problem with pure ref counting is that sometimes you might hit
a point where you don't need the directory for a moment - and then you do - if
its a ram based dir that means you lose your dir data. So this is something of
a hybrid - it still ref counts, but only when a new index writer is forced open
does it allow a directory to actually be closed. So when the indexwriter jumps
to a new index, that should allow the old one to be removed once all the refs
are released. The current working directory will always be kept around. All
created directories are are tracked so that any that are not closed can be
closed when the SolrCore is actually closed (not reloaded).
All tests currently passing.
> <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, SOLR-2654.patch, SOLR-2698.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
