lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Question about SearcherManager.maybeReopen() method.
Date Thu, 07 Nov 2013 18:40:30 GMT
The picture didn't come through to the list.

If you are really fully re-indexing and replacing the index every time
then you should just open a new IndexReader instead of trying to
.maybeReopen?  Ie, the newly opened reader cannot share any segments
with the old one, so you get no benefit from it.

But, this means, in your app you'll need to communicate when it's time
to open a new reader.

You might also want to use Lucene's replication module ... it handles
all these details.

One simple idea to try: on the machine that's doing the re-indexing,
instead of blowing away the index directory yourself, use
IndexWriter's .deleteAll, or open a new IndexWriter with
OpenMode.CREATE; each of these approaches will write the next
generation segments_N file, which when you copy over to the 2nd
machine, should reliably make openIfChanged think the index did in
fact change.



Mike McCandless

http://blog.mikemccandless.com


On Thu, Nov 7, 2013 at 11:33 AM, Alexei Morgado
<alexei_morgado@yahoo.com> wrote:
> We are not copying index files from one index to another. Will try to
> explain:
>
> 1 - We have a unix script that removes the old physical index and create a
> new one several times a day from the database.
> 2 - The SearcherManager call maybeReopen in a separate thread from the main
> application every five minutes. Only when the physical index really changed
> it is suppose to load the new one in memory.
>
>    This last step doesn't work when the old index and the new one have the
> exact sames names the files inside them. I am attaching a picture showing
> this. In production is creating the index with the files inside with the
> same exact name, we are not sure why, and the maybeReopen is confused and
> think in some way that the index didn't changed and it keeps the old one in
> memory, when the names are not the same it works fine. Look at the picture,
> it is self explanatory.
>
> Let me know if you need more information,
>
> Thanks a lot for your help,
>
> Alexei Morgado.
>
>
>
> On Thursday, November 7, 2013 6:00 AM, Michael McCandless
> <lucene@mikemccandless.com> wrote:
> It sounds like you are somehow copying over index files from one index to
> another?
>
> You shouldn't do that; use IW.addIndexes instead.
>
> Or maybe give a bigger picture of how your application works with Lucene?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Nov 6, 2013 at 6:46 PM, Alexei Morgado <AMorgado@rccl.com> wrote:
>
>> Hi guys,
>>
>> I have a question about a problem we had with the
>> SearcherManager.maybeReopen() method. This works as charm except when the
>> segments in the previous index has the exact same names as the segments in
>> the new one. In this case the maybeReopen() doesn't load the new index,
>> even though the isSearcherCurrent returns false, meaning it sees that the
>> new physical one is different from the old one. We are using lucene 3.5
>> and
>> we cannot upgrade that easily. Do you guys have any solution for this? Any
>> help will be greatly appreciated :):
>>
>>
>>
>>
>> Thanks in advance,
>>
>> Alexei Morgado.
>> Sr. JEE developer at Royal Caribbean.
>>
>
>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message