Bug 768326

Summary: kmail stalls when loading large imap mail directory
Product: [Fedora] Fedora Reporter: info <info>
Component: kdepimAssignee: Than Ngo <than>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: jreznik, kevin, ltinkl, rdieter, rnovacek, smparrish, than
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: kdepim-4.7.4-1.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-24 13:43:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description info@kobaltwit.be 2011-12-16 11:09:41 UTC
Description of problem:
I use kmail with multiple imap accounts on a local mail server. One of those accounts has a very large Trash folder (> 12.000 messages).

When working with kmail, it regularly stalls for minutes at a time in which you can't do anything sensible with it. In most cases these stalls seem to be because kmail is synchronizing the large Trash directory.

For example: I'm reading new mails in one imap folder (not the trash folder). When moving to the next mail, the message preview window shows
"Mapinhoud wordt opgehaald
Even geduld..."
This is Dutch and roughly translates to
"Folder contents is being fetched
Please wait..."

This can take several minutes, after which the mail is finally shown.

Another example:
Sending a mail sometimes fails with the error:
"Er trad een fout op bij het in de wachtrij voor verzending zetten: Append failed"
Which roughly translates as
An error occurred when adding to the send mail queue: Append failed"

Version-Release number of selected component (if applicable):
kdepim-4.7.3-1.fc16.i686

How reproducible:
All the time

Steps to Reproduce:
1. Create an imap account with a very large trash folder (perhaps the same happens with other folders as well, but it's the only one that's very big on my system)
2. Just try to use kmail. I get very frequent stalls during normal usage.
  
Actual results:
Switching from one mail message to another can take minutes, sending mails fail outright.

Expected results:
Switching from one mail message to another only happens with a minimal delay (ideally less than a second, but minutes is definitely too long), sending mails succeeds normally.

Additional info:
akonadiserver.error has multiple messages like this:
ItemRetrieverException :  Unable to retrieve item from resource: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. 

This is not a simple nuisance. The way kmail behaves on my system makes it completely unusable for intense mail processing.

Comment 1 Radek Novacek 2011-12-16 13:40:04 UTC
If you have enough free space on your hard disk, you can try disconnected IMAP (Accounts -> Modify -> Advanced -> Enable disconnected mode). It downloads all your emails to your computer first (it can take a lot of time) and then you can browse your email very fast. Mail folders with ~30.000 mails is loaded almost immediately for me.

As for your original issue, can you report it to the upstream bugzilla: https://bugs.kde.org/ ? Thank you

Comment 2 info@kobaltwit.be 2011-12-24 09:25:54 UTC
I have tried your workaround, but no change. I'm wondering if my akonadi cache may be corrupted or something. Is there a way to remove all local cache without deleting the actual e-mails ?
Kmail has become completely unresponsive in the meantime.

I have reported the issue upstream as
https://bugs.kde.org/show_bug.cgi?id=289133

Comment 3 info@kobaltwit.be 2011-12-24 13:43:28 UTC
Right after my last comment I discovered there was a kde update available for F16. I have installed it and the problem seems to be gone. I'll reopen the report if I experience this again.

Comment 4 Rex Dieter 2011-12-24 15:12:50 UTC
yay.