lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7302) IndexWriter should tell you the order of indexing operations
Date Tue, 14 Jun 2016 08:15:11 GMT


ASF subversion and git services commented on LUCENE-7302:

Commit 8ed16fd1f9a03c66d4ac81ddaa7ab70359410b95 in lucene-solr's branch refs/heads/branch_6x
from Mike McCandless
[;h=8ed16fd ]

LUCENE-7302: ensure IW.getMaxCompletedSequenceNumber only reflects a change after NRT reader
refresh would also see it

> IndexWriter should tell you the order of indexing operations
> ------------------------------------------------------------
>                 Key: LUCENE-7302
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: master (7.0), 6.2
>         Attachments: LUCENE-7032.patch, LUCENE-7132.patch
> Today, when you use multiple threads to concurrently index, Lucene
> knows the effective order that those operations were applied to the
> index, but doesn't return that information back to you.
> But this is important to know, if you want to build a reliable search
> API on top of Lucene.  Combined with the recently added NRT
> replication (LUCENE-5438) it can be a strong basis for an efficient
> distributed search API.
> I think we should return this information, since we already have it,
> and since it could simplify servers (ES/Solr) on top of Lucene:
>   - They would not require locking preventing the same id from being
>     indexed concurrently since they could instead check the returned
>     sequence number to know which update "won", for features like
>     "realtime get".  (Locking is probably still needed for features
>     like optimistic concurrency).
>   - When re-applying operations from a prior commit point, e.g. on
>     recovering after a crash from a transaction log, they can know
>     exactly which operations made it into the commit and which did
>     not, and replay only the truly missing operations.
> Not returning this just hurts people who try to build servers on top
> with clear semantics on crashing/recovering ... I also struggled with
> this when building a simple "server wrapper" on top of Lucene
> (LUCENE-5376).

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message