lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/LUCENE-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329079#comment-15329079
] 

ASF subversion and git services commented on LUCENE-7302:
---------------------------------------------------------

Commit 8ed16fd1f9a03c66d4ac81ddaa7ab70359410b95 in lucene-solr's branch refs/heads/branch_6x
from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;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: https://issues.apache.org/jira/browse/LUCENE-7302
>             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
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message