Hi, On 24 July 2015 at 11:11, Tommaso Teofili <tommaso.teof...@gmail.com> wrote:
> Hi Ian, > > 2015-07-24 11:11 GMT+02:00 Ian Boston <i...@tfd.co.uk>: > > > Hi Tommaso, > > > > My knowledge of Solr is not anything like as deep as yours. I would like > to > > check what I know is correct, to avoid sharing the wrong information. > > > > In [1] the first test does not commit and is backed by a RAMDirectory > > shared by the reader and writer. Does that mean that Lucene natively only > > supports NRT inside a single JVM, and if the JVM dies anything not hard > > committed (if the RAMDirectory was backed by a FileDirectory) would be > lost > > > > yes, exactly. > > > > or is recovery of soft commits and pre-soft commits now handled > > automatically in Lucene4. > > > > no, that's not part of Lucene as far as I know; that's Solr allowing soft > commits [1], which use Lucene's NRT capabilities and a transaction log [2], > if JVM crashes soft commits are recovered from the transaction log and > re-executed once Solr is restarted. > Thank you for the information, especially [2]. My knowledge was out of date. The transaction log did not exist in SolrCloud when I last looked at the source code and was only available as a commercial component from Lucidworks. For reference, the only difference between SolrCloud4 as described in [2] and ES appears to be that SolrCloud4 works on source documents whereas ES works on digested versions of a document (ie properties only). At some point prior to releasing the code I looked at, SolrCloud4 must have switched from segment based replication in favour of document based replication. Best Regards Ian > > > > > > Last time I looked at the source code was shortly before Lucene 4.0 was > > released which was some years back. > > > > Regards, > Tommaso > > [1] : > > http://wiki.apache.org/solr/UpdateXmlMessages#A.22commit.22_and_.22optimize.22 > [2] : > > http://lucidworks.com/blog/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/ > > > > > > Best Regards > > Ian > > > > On 24 July 2015 at 09:49, Tommaso Teofili <tommaso.teof...@gmail.com> > > wrote: > > > > > I think the proposal makes sense; in the end NRT is something that is > > > inherently supported by Lucene (see an example [1]) and, as Ian > > mentioned, > > > something that has been similarly implemented in ES and Solr. > > > > > > I think it'd be possible though to make use of Lucene's NRT capability > by > > > changing a bit the code that creates an IndexReader [2] to use > > > DirectoryReader#open(IndexWriter,boolean) [3]. > > > > > > My 2 cents, > > > Tommaso > > > > > > [1] : https://gist.github.com/mocobeta/4640263 > > > [2] : > > > > > > > > > https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/IndexNode.java#L94 > > > [3] : > > > > > > > > > https://lucene.apache.org/core/4_7_0/core/org/apache/lucene/index/DirectoryReader.html#open(org.apache.lucene.index.IndexWriter > > > , > > > boolean) > > > > > > 2015-07-24 10:23 GMT+02:00 Michael Marth <mma...@adobe.com>: > > > > > > > > > > > >The reason I preferred using Lucene is that current > > > > >property index only support single condition evaluation. > > > > > > > > I did not know this. That’s a strong argument in favour of using > > Lucene. > > > > > > > > > >
