Mailing List Archive

Readers synchronization
According to SVN history on the next version this will be available:

LUCENE-1044: IndexWriter with autoCommit=true now commits (such
that a reader can see the changes) far less often than it used to.
Previously, every flush was also a commit. You can always force a
commit by calling IndexWriter.commit(). Furthermore, in 3.0,
autoCommit will be hardwired to false (IndexWriter constructors
that take an autoCommit argument have been deprecated) (Mike
McCandless)

Does this mean that I won't need to reopen all the readers in order to see the index changes?

Thanks




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Readers synchronization [ In reply to ]
No, that's not changed. You must still reopen an IndexReader to see
changes to the index. An IndexReader always searches a point-in-time
snapshot of the index.

LUCENE-1044 does mean that you should call IndexWriter.commit() (or,
close the writer) to ensure all changes you've made become visible to
the reader.

Mike

Eric Diaz wrote:

> According to SVN history on the next version this will be available:
>
> LUCENE-1044: IndexWriter with autoCommit=true now commits (such
> that a reader can see the changes) far less often than it used to.
> Previously, every flush was also a commit. You can always force a
> commit by calling IndexWriter.commit(). Furthermore, in 3.0,
> autoCommit will be hardwired to false (IndexWriter constructors
> that take an autoCommit argument have been deprecated) (Mike
> McCandless)
>
> Does this mean that I won't need to reopen all the readers in order
> to see the index changes?
>
> Thanks
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Readers synchronization [ In reply to ]
Besides the warm up that the faq section suggests (used on solr), is there another technique or solution to have an IndexReader/Search with an updated view of an index under a concurrent scenario (web app)?

Thanks

--- On Tue, 7/8/08, Michael McCandless <lucene@mikemccandless.com> wrote:

> From: Michael McCandless <lucene@mikemccandless.com>
> Subject: Re: Readers synchronization
> To: java-user@lucene.apache.org
> Date: Tuesday, July 8, 2008, 11:12 AM
> No, that's not changed. You must still reopen an
> IndexReader to see
> changes to the index. An IndexReader always searches a
> point-in-time
> snapshot of the index.
>
> LUCENE-1044 does mean that you should call
> IndexWriter.commit() (or,
> close the writer) to ensure all changes you've made
> become visible to
> the reader.
>
> Mike
>
> Eric Diaz wrote:
>
> > According to SVN history on the next version this will
> be available:
> >
> > LUCENE-1044: IndexWriter with autoCommit=true now
> commits (such
> > that a reader can see the changes) far less often
> than it used to.
> > Previously, every flush was also a commit. You can
> always force a
> > commit by calling IndexWriter.commit().
> Furthermore, in 3.0,
> > autoCommit will be hardwired to false (IndexWriter
> constructors
> > that take an autoCommit argument have been
> deprecated) (Mike
> > McCandless)
> >
> > Does this mean that I won't need to reopen all the
> readers in order
> > to see the index changes?
> >
> > Thanks
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail:
> java-user-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail:
> java-user-help@lucene.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Readers synchronization [ In reply to ]
No other techniques that I know of...

But there is ongoing discussions/work towards making reopening a
reader much less costly. EG repopulating the field cache after reopen
is a costly operation now, but this issue:

https://issues.apache.org/jira/browse/LUCENE-1231

would make that cost be proportional to the number & size of the
changed segments since you last reopened.

There has also been discussions on creating an IndexReader
implementation that can directly search the RAM buffer in IndexWriter,
which should give very fast turnaround in searching just-indexed
documents, but that is quite a ways off...

Mike

Eric Diaz wrote:

> Besides the warm up that the faq section suggests (used on solr), is
> there another technique or solution to have an IndexReader/Search
> with an updated view of an index under a concurrent scenario (web
> app)?
>
> Thanks
>
> --- On Tue, 7/8/08, Michael McCandless <lucene@mikemccandless.com>
> wrote:
>
>> From: Michael McCandless <lucene@mikemccandless.com>
>> Subject: Re: Readers synchronization
>> To: java-user@lucene.apache.org
>> Date: Tuesday, July 8, 2008, 11:12 AM
>> No, that's not changed. You must still reopen an
>> IndexReader to see
>> changes to the index. An IndexReader always searches a
>> point-in-time
>> snapshot of the index.
>>
>> LUCENE-1044 does mean that you should call
>> IndexWriter.commit() (or,
>> close the writer) to ensure all changes you've made
>> become visible to
>> the reader.
>>
>> Mike
>>
>> Eric Diaz wrote:
>>
>>> According to SVN history on the next version this will
>> be available:
>>>
>>> LUCENE-1044: IndexWriter with autoCommit=true now
>> commits (such
>>> that a reader can see the changes) far less often
>> than it used to.
>>> Previously, every flush was also a commit. You can
>> always force a
>>> commit by calling IndexWriter.commit().
>> Furthermore, in 3.0,
>>> autoCommit will be hardwired to false (IndexWriter
>> constructors
>>> that take an autoCommit argument have been
>> deprecated) (Mike
>>> McCandless)
>>>
>>> Does this mean that I won't need to reopen all the
>> readers in order
>>> to see the index changes?
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> java-user-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail:
>> java-user-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail:
>> java-user-help@lucene.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Readers synchronization [ In reply to ]
Is there any plan to change this behavior? meaning that by default a reader will see the current index?

Thanks in advance

--- On Tue, 7/8/08, Michael McCandless <lucene@mikemccandless.com> wrote:

> From: Michael McCandless <lucene@mikemccandless.com>
> Subject: Re: Readers synchronization
> To: java-user@lucene.apache.org, ediaz666@yahoo.com
> Date: Tuesday, July 8, 2008, 11:58 AM
> No other techniques that I know of...
>
> But there is ongoing discussions/work towards making
> reopening a
> reader much less costly. EG repopulating the field cache
> after reopen
> is a costly operation now, but this issue:
>
> https://issues.apache.org/jira/browse/LUCENE-1231
>
> would make that cost be proportional to the number &
> size of the
> changed segments since you last reopened.
>
> There has also been discussions on creating an IndexReader
>
> implementation that can directly search the RAM buffer in
> IndexWriter,
> which should give very fast turnaround in searching
> just-indexed
> documents, but that is quite a ways off...
>
> Mike
>
> Eric Diaz wrote:
>
> > Besides the warm up that the faq section suggests
> (used on solr), is
> > there another technique or solution to have an
> IndexReader/Search
> > with an updated view of an index under a concurrent
> scenario (web
> > app)?
> >
> > Thanks
> >
> > --- On Tue, 7/8/08, Michael McCandless
> <lucene@mikemccandless.com>
> > wrote:
> >
> >> From: Michael McCandless
> <lucene@mikemccandless.com>
> >> Subject: Re: Readers synchronization
> >> To: java-user@lucene.apache.org
> >> Date: Tuesday, July 8, 2008, 11:12 AM
> >> No, that's not changed. You must still reopen
> an
> >> IndexReader to see
> >> changes to the index. An IndexReader always
> searches a
> >> point-in-time
> >> snapshot of the index.
> >>
> >> LUCENE-1044 does mean that you should call
> >> IndexWriter.commit() (or,
> >> close the writer) to ensure all changes you've
> made
> >> become visible to
> >> the reader.
> >>
> >> Mike
> >>
> >> Eric Diaz wrote:
> >>
> >>> According to SVN history on the next version
> this will
> >> be available:
> >>>
> >>> LUCENE-1044: IndexWriter with autoCommit=true
> now
> >> commits (such
> >>> that a reader can see the changes) far less
> often
> >> than it used to.
> >>> Previously, every flush was also a commit.
> You can
> >> always force a
> >>> commit by calling IndexWriter.commit().
> >> Furthermore, in 3.0,
> >>> autoCommit will be hardwired to false
> (IndexWriter
> >> constructors
> >>> that take an autoCommit argument have been
> >> deprecated) (Mike
> >>> McCandless)
> >>>
> >>> Does this mean that I won't need to reopen
> all the
> >> readers in order
> >>> to see the index changes?
> >>>
> >>> Thanks
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> >> java-user-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail:
> >> java-user-help@lucene.apache.org
> >>>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> java-user-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail:
> >> java-user-help@lucene.apache.org
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail:
> java-user-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail:
> java-user-help@lucene.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Readers synchronization [ In reply to ]
Not that I know of.

Mike

Eric Diaz wrote:

> Is there any plan to change this behavior? meaning that by default a
> reader will see the current index?
>
> Thanks in advance
>
> --- On Tue, 7/8/08, Michael McCandless <lucene@mikemccandless.com>
> wrote:
>
>> From: Michael McCandless <lucene@mikemccandless.com>
>> Subject: Re: Readers synchronization
>> To: java-user@lucene.apache.org, ediaz666@yahoo.com
>> Date: Tuesday, July 8, 2008, 11:58 AM
>> No other techniques that I know of...
>>
>> But there is ongoing discussions/work towards making
>> reopening a
>> reader much less costly. EG repopulating the field cache
>> after reopen
>> is a costly operation now, but this issue:
>>
>> https://issues.apache.org/jira/browse/LUCENE-1231
>>
>> would make that cost be proportional to the number &
>> size of the
>> changed segments since you last reopened.
>>
>> There has also been discussions on creating an IndexReader
>>
>> implementation that can directly search the RAM buffer in
>> IndexWriter,
>> which should give very fast turnaround in searching
>> just-indexed
>> documents, but that is quite a ways off...
>>
>> Mike
>>
>> Eric Diaz wrote:
>>
>>> Besides the warm up that the faq section suggests
>> (used on solr), is
>>> there another technique or solution to have an
>> IndexReader/Search
>>> with an updated view of an index under a concurrent
>> scenario (web
>>> app)?
>>>
>>> Thanks
>>>
>>> --- On Tue, 7/8/08, Michael McCandless
>> <lucene@mikemccandless.com>
>>> wrote:
>>>
>>>> From: Michael McCandless
>> <lucene@mikemccandless.com>
>>>> Subject: Re: Readers synchronization
>>>> To: java-user@lucene.apache.org
>>>> Date: Tuesday, July 8, 2008, 11:12 AM
>>>> No, that's not changed. You must still reopen
>> an
>>>> IndexReader to see
>>>> changes to the index. An IndexReader always
>> searches a
>>>> point-in-time
>>>> snapshot of the index.
>>>>
>>>> LUCENE-1044 does mean that you should call
>>>> IndexWriter.commit() (or,
>>>> close the writer) to ensure all changes you've
>> made
>>>> become visible to
>>>> the reader.
>>>>
>>>> Mike
>>>>
>>>> Eric Diaz wrote:
>>>>
>>>>> According to SVN history on the next version
>> this will
>>>> be available:
>>>>>
>>>>> LUCENE-1044: IndexWriter with autoCommit=true
>> now
>>>> commits (such
>>>>> that a reader can see the changes) far less
>> often
>>>> than it used to.
>>>>> Previously, every flush was also a commit.
>> You can
>>>> always force a
>>>>> commit by calling IndexWriter.commit().
>>>> Furthermore, in 3.0,
>>>>> autoCommit will be hardwired to false
>> (IndexWriter
>>>> constructors
>>>>> that take an autoCommit argument have been
>>>> deprecated) (Mike
>>>>> McCandless)
>>>>>
>>>>> Does this mean that I won't need to reopen
>> all the
>>>> readers in order
>>>>> to see the index changes?
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>> java-user-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail:
>>>> java-user-help@lucene.apache.org
>>>>>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> java-user-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail:
>>>> java-user-help@lucene.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> java-user-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail:
>> java-user-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail:
>> java-user-help@lucene.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>


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