[
https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704995#action_12704995
]
Michael McCandless commented on LUCENE-1313:
--------------------------------------------
Patch looks good! Some comments:
* I don't think the caller should provide the RAMDir... and we
should have a getter to get it. I think this should be
under-the-hood. This is simply a nice way for IW to use RAM as
buffer in the presence of frequent NRT readers being opened.
* If NRT is never used, the behavior of IW should be unchanged
(which is not the case w/ this patch I think). RAMDir should be
created the first time a flush is done due to NRT creation.
* StoredFieldsWriter & TermVectorsTermsWriter now writes to
IndexWriter.getFlushDirectory(), which is confusing because that
method returns the RAMDir if set? Shouldn't this be the opposite?
(Ie it should flush to IndexWriter.getDirectory()? Or we should
change getFlushDiretory to NOT return the ramdir?)
* Why did you need to add synchronized to some of the SegmentInfo
files methods? (What breaks if you undo that?). The contract
here is IW protects access to SegmentInfo/s.
* The MergePolicy needs some smarts when it's dealing w/ RAM. EG it
should not do a merge of more than XXX% of total RAM usage (should
flush to the real directory instead).
* Nothing is calling the new ramOverLimit?
* Still some noise (MockRAMDir, DocFieldProcessorPerThread, some
changes in LogMergePolicy)
> Realtime Search
> ---------------
>
> Key: LUCENE-1313
> URL: https://issues.apache.org/jira/browse/LUCENE-1313
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index
> Affects Versions: 2.4.1
> Reporter: Jason Rutherglen
> Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1313.jar, LUCENE-1313.patch, LUCENE-1313.patch,
> LUCENE-1313.patch, LUCENE-1313.patch, LUCENE-1313.patch, LUCENE-1313.patch,
> LUCENE-1313.patch, lucene-1313.patch, lucene-1313.patch, lucene-1313.patch,
> lucene-1313.patch
>
>
> Realtime search with transactional semantics.
> Possible future directions:
> * Optimistic concurrency
> * Replication
> Encoding each transaction into a set of bytes by writing to a RAMDirectory
> enables replication. It is difficult to replicate using other methods
> because while the document may easily be serialized, the analyzer cannot.
> I think this issue can hold realtime benchmarks which include indexing and
> searching concurrently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
