[ https://issues.apache.org/jira/browse/LUCENE-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364317#comment-15364317 ]
ASF subversion and git services commented on LUCENE-7302: --------------------------------------------------------- Commit 4ff882e4aa9cb7fc585213bca9344fa05d1bec5f 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=4ff882e ] LUCENE-7302: IW.getMaxCompletedSequenceNumber was returning the wrong value after IW.deleteAll > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org