lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] [Updated] (SOLR-2654) <lockType/> not used consistently in all places Directory objects are instantiated
Date Sat, 13 Aug 2011 23:01:27 GMT


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:
>             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
> 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:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message