lucene-dev mailing list archives

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


Mark Miller commented on SOLR-2654:

bq. couldn't we go with this as an iterative improvement

Yeah, that's been on my mind - just didn't want to give up completely yet. If I commit this
now, it will take the pressure off for figuring out something better. Give me a bit more time
to defeat myself.

bq.  currently no directories are ever getting closed right?

Right - but the tradeoff with this is, I think, is that before Directories would be garbage
collected when they where no longer used - and now they will stick around till the SolrCore
is really closed. Not a big deal for FSDirectory impls in general, but more troublesome for
the ram based variety.

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