Hi Jerry,

Thanks for the updated details, it now makes perfect sens!

Long story short: Your Lucene index needs to be migrated as well. I
suspect you migrated only your database (full copy), hence issues.

To do migration, at Linagora, we prefer using external protocols, and
leaving the inner data structures untouched (it's just too easy to make
mistakes...).

What happens is that then you had the data in SQL database but none in
the Lucene index, hence the unaccurate search results harming the IOS
experience.

>From that point:
 - You can fix that from re-indexing data from the SQL database and
rebuild the Lucene index from it. There's webadmin(guice only) [1] and
CLI [2] support for that (though the CLI experience, the only available
option for Spring is more primitive.

lazyIndex means full scan on every search request. Expect the AWS bill
to be expansive. Expect your clients to complain about latencies. I
would be you, I'd rebuild the Lucene index at the first occasion.

Now, I also believe cascading user flags issues might be caused by some
unappropriate table structure, there was some bugs reported regarding
this. I'm unable to retrieve corresponding information.

[1]
https://github.com/apache/james-project/blob/master/src/site/markdown/server/manage-webadmin.md#reindexing-all-mails
[2]
https://github.com/apache/james-project/blob/master/src/site/markdown/server/manage-cli.md#re-indexing

Cheers,

Benoit

On 05/11/2019 07:47, Jerry Malcolm wrote:
> I'm starting a new thread for this specific issue.  One external symptom
> that has now been isolated to this problem is documented in my
> long-running (and hopefully completed) thread about iPhones losing all
> of their mail.
> 
> Here's what I know about this so far:
> 
> 1) I had no clue what 'Lucene' was or what it did.  So I've never
> touched anything in any config file related to it.  Whatever happened
> came right out of the box as far as lucene config is concern.  (ver
> 3.4+... I extracted the master branch a day or so after 3.4 was released).
> 
> 2) I have been in the process of migrating 17+ years of mail in a James
> SQL db from v3b5 on a dedicated server to ver 3.4 in Amazon Web Services
> environment.
> 
> 3) On 21Oct, I threw the switch and went live on my AWS environment.
> 
> 4) Immediately some of my clients with iPhones complained that all of
> their mail disappeared from their phone.
> 
> 5) Being an iPhone user myself, I verified the problem.  However, I
> noticed that mail arriving to the new James instance was showing up in
> the iPhone.  Just no mail pre 21Oct.
> 
> 6) Thunderbird was showing all of the old mail in the folders. But I've
> since determined that TBird uses a different imap command that goes
> straight to the JPA database to populate folders, bypassing the Lucene
> index.
> 
> 7) After two weeks of educating myself on the entire imap component and
> doing a whole lot of adding log statements and trial & error debug, the
> Lucene index became the prime suspect
> 
> 8) Today, I removed the var/store/lucene folder and rebooted. The
> iPhones now wiped out the last two weeks of email and either showed "No
> Mail" or mail that arrived in the few minutes after wiping the lucene
> folder.  Note that it STILL didn't reindex old mail, even with an index
> 'restart'.
> 
> 9) Finally on a whim, I changed indexer.xml to use "lazyIndex" instead
> of "luceneIndex".  Finally, the indexes rebuilt successfully, and the
> iPhones now show all of the mail. Success...
> 
> Summary:  lazyIndex seems to have no problems.  Not sure what's going
> wrong when luceneIndex is selected.  But it isn't right.
> 
> Do I have any mis-assumptions?  Is there something else I need to do in
> order to get Lucene to index old mail?
> 
> This has been a tough one... I think I'll take a nap now...:-)
> 
> Jerry
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to