[
https://issues.apache.org/jira/browse/LUCENE-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676749#action_12676749
]
Michael McCandless commented on LUCENE-1516:
--------------------------------------------
Looks good!:
* The SegmentReaderPool class should be package private.
* You're still passing readOnly & closeDirectory into the new
DirectoryIndexReader ctor; I think you can pass in only the
writer, and then it can get all it needs from that (pool, dir,
segmentInfos)?
* Hmm... I think we should change commitMergedDeletes to use the
already computed doc ID maps, instead of loading the old deletes.
This way you don't need the old SR.
* I think you don't need SegmentInfoKey? Can't you key off of just
the SegmentInfo? I think for each segment name we only ever need
one SR instance in the pool (dir is always the same)? (The
readers we give out will make clones of these).
* Why do you applyDeletesImmediately? I think we should
buffer/flush like we normally do? That code shouldn't need to
change.
* I think getReader does need to flush, else added docs won't be
seen in the reopend reader. You should call flush(true, true,
true) -- because you want to triggerMerges, flushDocStores,
and flushDeletes.
* Are segmentInfosList/printSegmentInfosList temporary debugging?
Can you stick "nocommits" on them?
For SegmentReaderPool:
* I think IW should always use the pool API internally to load &
decRef the SRs it uses.
* If getReader has never been called, then the pool should not hold
refs, ie IW should behave exactly as it does today (get SR, use
it, commit it, close it). Ie, the pool should detect on decRef
that the RC is now 1, and release the SR.
* If getReader has been called, then the pool should hold onto an SR
as long as the writer's segmentInfos still references that
segment. This means, after a merge commits we should prune the
pool. Ie, we decRef and remove the SR from the pool, but we don't
close it since a reader may still be using it. Maybe add a
prune() method?
* Somehow, we should not let the SR commit itself on close -- that's
up to IW to decide. If getReader has not been called then IW must
commit deletes as soon as applies them (like today). Else, it's
only on closing the pool that deletes are committed. EG pending
deletes on SRs that have been merged can be freely discarded,
since those deletes "made it" into the newly merged segment.
* So I don't think we need a BG thread to do the culling.
> Integrate IndexReader with IndexWriter
> ---------------------------------------
>
> Key: LUCENE-1516
> URL: https://issues.apache.org/jira/browse/LUCENE-1516
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4
> Reporter: Jason Rutherglen
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1516.patch, LUCENE-1516.patch, LUCENE-1516.patch,
> LUCENE-1516.patch, LUCENE-1516.patch, LUCENE-1516.patch, LUCENE-1516.patch,
> LUCENE-1516.patch, LUCENE-1516.patch, LUCENE-1516.patch, LUCENE-1516.patch,
> LUCENE-1516.patch, LUCENE-1516.patch
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> The current problem is an IndexReader and IndexWriter cannot be open
> at the same time and perform updates as they both require a write
> lock to the index. While methods such as IW.deleteDocuments enables
> deleting from IW, methods such as IR.deleteDocument(int doc) and
> norms updating are not available from IW. This limits the
> capabilities of performing updates to the index dynamically or in
> realtime without closing the IW and opening an IR, deleting or
> updating norms, flushing, then opening the IW again, a process which
> can be detrimental to realtime updates.
> This patch will expose an IndexWriter.getReader method that returns
> the currently flushed state of the index as a class that implements
> IndexReader. The new IR implementation will differ from existing IR
> implementations such as MultiSegmentReader in that flushing will
> synchronize updates with IW in part by sharing the write lock. All
> methods of IR will be usable including reopen and clone.
--
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
