You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/06/05 09:51:59 UTC

[jira] [Commented] (LUCENE-7302) IndexWriter should tell you the order of indexing operations

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

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

Commit b1fb142af003386f985b4c4ad1a583d009d49e41 in lucene-solr's branch refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b1fb142 ]

LUCENE-7302: Merge branch 'sequence_numbers'


> 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: 6.1, master (7.0)
>
>         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