A search server runs on an index periodically refreshed by an indexer
Question 1: A search server runs on an index that are periodically refreshed with newer versions. For example, it starts with c:/lucene/ind_dir_0, then later on the indexer creates c:/lucene/ind_dir_1 and so on. I would like the search server to automatically pick up the latest version when it is available. What are your suggestions? Question 2: Similar to question 1, except that the indexer re-index the whole corpus but rather just add a new segment to the existing index periodically. Should the solution be different from the first one? Thanks a lot. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-129) Finalizers are non-canonical
[
https://issues.apache.org/jira/browse/LUCENE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462579
]
wolfgang hoschek commented on LUCENE-129:
-
Just to clarify: The empty finalize() method body in MemoryIndex measurabley
improves performance of this class and it does not harm correctness because
MemoryIndex does not require the superclass semantics wrt. concurrency.
> Finalizers are non-canonical
>
>
> Key: LUCENE-129
> URL: https://issues.apache.org/jira/browse/LUCENE-129
> Project: Lucene - Java
> Issue Type: Bug
> Components: Other
>Affects Versions: unspecified
> Environment: Operating System: other
> Platform: All
>Reporter: Esmond Pitt
> Assigned To: Michael McCandless
>Priority: Minor
> Fix For: 2.1
>
>
> The canonical form of a Java finalizer is:
> protected void finalize() throws Throwable()
> {
> try
> {
>// ... local code to finalize this class
> }
> catch (Throwable t)
> {
> }
> super.finalize(); // finalize base class.
> }
> The finalizers in IndexReader, IndexWriter, and FSDirectory don't conform.
> This
> is probably minor or null in effect, but the principle is important.
> As a matter of fact FSDirectory.finaliz() is entirely redundant and could be
> removed, as it doesn't do anything that RandomAccessFile.finalize would do
> automatically.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-764) Document the temporary free space requirements of IndexWriter methods
[ https://issues.apache.org/jira/browse/LUCENE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-764. --- Resolution: Fixed > Document the temporary free space requirements of IndexWriter methods > - > > Key: LUCENE-764 > URL: https://issues.apache.org/jira/browse/LUCENE-764 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Affects Versions: 2.1 >Reporter: Michael McCandless > Assigned To: Michael McCandless >Priority: Trivial > Fix For: 2.1 > > > Just opening an issue to track fixes to javadocs around Directory > space usage of optimize(), addIndexes(*), addDocument. > This came out of a recent thread on the users list around unexpectedly > high temporary disk usage during optimize(): > http://www.gossamer-threads.com/lists/lucene/java-user/43475 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
