[
https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Rutherglen updated LUCENE-1313:
-------------------------------------
Attachment: LUCENE-1313.patch
* A single merge scheduler is used. We will need to open a new
issue for a version of ConcurrentMergeScheduler that allocates
threads perhaps based on the merge.directory? We'd also probably
want to add thread pooling.
* There's a package protected IW ctor that accepts the ram dir.
This is used in the test case for insuring we aren't creating
.cfs files in the ram dir.
* IW.optimize merges all segments (ram included) to the primary
dir
* IW.expungeDeletes merges segments with deletes, in ram ones
stay in ram (unless they won't fit), and primary dir ones are
handled as usual
* Added testOptimize, testExpungeDeletes, and some other test
cases
* Needs a test case to make sure we're merging to the primary
dir when the ram dir is full or a flush won't fit in the ram dir
* There's a mergeRamSegmentsToDir and resolveRamSegments. Two
different methods because mergeRamSegmentsToDir operates by
simply scheduling merges, resolveRamSegments operates in the
foreground like resolveExternalSegments. I'm not sure if we can
combine the two. resolveRamSegments seems to have a thread
notification problem and so hangs at times. I'll look into this
further unless it's obvious what the problem is.
* When RAM NRT is on (via the IndexWriter constructor), setting
the ram buffer size allocates half of the given number to the
DocumentsWriter buffer and half to the ram dir. It may be best
to dynamically change these numbers based on usage etc.
* Added NRTMergePolicy which is used only when RAM NRT is on. It
utilizes the regular merge policy and the ram merge policy.
* The ram dir size is pushed to DocumentsWriter
* RAMMergePolicy extends LogDocMergePolicy and defaults the
useCompoundFile and useCompoundDocStore to false
* Sorry for the whitespace stuff, I'll clean it up later, I
wanted to post the latest to get feedback
> 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, 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
