[Akonadi] [Bug 353140] New: Akonadi needs to handle slow persistent storage.

[Garrett Kajmowicz]

https://bugs.kde.org/show_bug.cgi?id=353140

            Bug ID: 353140
           Summary: Akonadi needs to handle slow persistent storage.
           Product: Akonadi
           Version: unspecified
          Platform: Ubuntu Packages
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: server
          Assignee: kdepim-bugs at kde.org
          Reporter: gkajmowi at tbaytel.net

I have a machine at work with a slow (60ms RTT) NFS connection which hosts my
home directory. Running kmail/Akonadi against this is nearly unusable and
frequently is unable to load emails when I select them.

One proposal I have seen is to change the XDG_DATA_DIRS environment variable or
similar. This has 3 problems:
1) Changing that variable potentially impacts more applications than just
kmail/Akonadi
2) An individual machine may not have any local stable persistent storage.
3) I want my personal data to be persisted as well as to be sharable /
accessible on other machines. That is: I'm using NFS for a reason.

One method I can see for improving this architecturally is to split Akonadi
internally to have separate storage locations/engines for what I'll refer to as
cached data and authoritative data.
>From the page here:
https://blogs.kde.org/2011/11/13/akonadi-misconception-1-where-my-data
I'm using "cached data" to refer to data which is persistently stored outside
of Akonadi as the authoritative source. So this would be copies/information
about mail stored on an IMAP server, or that which might stored in a Maildir
locally.
I'm using "authoritative data" to refer to data for which Akonadi is the sole
owner. This includes "metadata added to your data", "Nepomuk tags", or "data
that is not yet syncronized to the server". This is data I do not want to lose.

By separating the storage for the cached vs. authoritative data, I could have
the authoritative data stored on a high-latency NFS server while the cached
data is stored locally on-disk or in memory.

There may be other solutions - this is merely one idea I've come up with.

Reproducible: Always

Steps to Reproduce:
1. Configure user with NFS home directory with high latency, potentially with
occasional random packet loss.
2. Configure kmail/Akonadi to point to existing IMAP server with lots of email.
3. Enjoy the unusability.

Actual Results:  
Kmail frequently stalls trying to retrieve my email. Selecting a particular
message frequently stalls indefinitely at "Retrieving Folder Contents Please
wait ..." message.

Similar to:

https://bugs.kde.org/show_bug.cgi?id=289097

Expected Results:  
I am able to select email and have it visible within a handful of seconds
consistently.
My data should be persistent.

-- 
You are receiving this mail because:
You are the assignee for the bug.