lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: IndexSearcher and multi-threaded performance
Date Wed, 12 Nov 2008 22:00:42 GMT

: >From the user perspective: a public constructor would be the most
: obvious, and would be consistent with RAMDirectory.

A lot of the cases where system properties are currently used can't 
really be solved this way because the client isn't the one constructing 
the object.  SegmentReader's IMPL for example needs to be set "globally" 
so that the correct concrete class is used when a MultiSegmentReader goes 
to open each segment.

In the case of FSDirectory.getDirectory a static cache f Directory objects 
is maintained to ensure only one Directory object exists at any given time 
per File.

: > I think we really should open up a non-static way to choose a different
: > FSDirectory impl?  EG maybe add optional Class to FSDirectory.getDirectory?
: >  Or maybe give NIOFSDirectory a public ctor?  Or something?

A factory/provider pattern could work, but that makes the above mentioned 
caching complicated (what if one call to getDirectory for /tmp/index wants 
an NIOFSDirectory and another wants a MyFSDirectory?)

since the choice of FSDirectory varient is largly going to be based on OS, 
I can't think of any reason why a static setter method wouldn't be good 
enough in this particular case.

past discussion about alternate options for clients to control things 
these things beyond using system properties...

http://issues.apache.org/jira/browse/LUCENE-636
http://www.nabble.com/Back-Compatibility-to14918202.html#a15027970
 ...and some replies.

-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message