Bug 340052 - akonadi lockup on sync 'trash' (sqlite backend)
Summary: akonadi lockup on sync 'trash' (sqlite backend)
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 1.13.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-17 11:30 UTC by Christian Quast
Modified: 2017-01-07 22:08 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Quast 2014-10-17 11:30:58 UTC
Dear developers,

a while back I reported a bug (https://bugs.kde.org/show_bug.cgi?id=337366) concerning lock-ups in the akonadi server. After switching to the QSQLITE driver, as suggested in the comments, everything worked fine.

Now I upgraded to KDE 4.14 / akonadi-runtime 1.13.0 and the server locks up again. However, the symptoms are quite different from what I reported in the previous bug report (so I am not sure if this bug reported is related the old report, I am still using the QSQLITE driver according to my akonadiserverrc).

This time, akonadi / kontakt only locks up when trying to sync trash folders (as far as I can tell) and only if the folders contains more than XXX number of mails and/or YYY number of unread mails. Today, XXX was about 400 and YYY was about 240. I have mailing list folders containing many more mails than this (a few thousand) but generally less unread mails, except one containing about 550 unread mails and 4000 mails in total but these folders work fine. The main difference is that mails in the mailing list folders are automatically moved to these folders by the mail server, not akonadi / kontakt.

Compared to last time when shutting down akonadi took 20 or more seconds, this time akonadi shuts down immediately (within two or three seconds) when using `akonadictl stop`.  But akonadi / kontakt locks up as soon as the trash folder is accessed either by selecting it manually, or by moving mails to that folder. Also,  it doesn't matter how long akonadi / kontakt was running before the lock-ups as compared to the previous bug report. 

When I empty the trash folder using the web interface of the mail server then akonadi / kontakt work fine until the trash folder fills up again. This has happened two or three times before on both configured IMAP accounts and emptying the trash folders always helped.

This problem started when updating to 4.14.0. Currently, I run 4.14.2 and I still have the problem. On my laptop I am still running 4.13.x I don't have this problem connecting to the same IMAP servers, using the same settings while the trash folders are filled up.

I didn't notice anything of particular interest in the akonadi / kontakt output when starting the programs from the command line.

Platform: opensuse 13.1 using the KDE stable build service

Software versions:
akonadi-4.14.2-1.1.x86_64
akonadi-runtime-1.13.0-1.1.x86_64
baloo-pim-4.14.1-2.1.x86_64
kdepim4-4.14.2-1.1.x86_64
kdepim4-runtime-4.14.2-1.1.x86_64
kdepimlibs4-4.14.2-1.1.x86_64
libakonadi4-4.14.2-1.1.x86_64
libakonadiprotocolinternals1-1.13.0-1.1.x86_64
libbaloopim4-4.14.1-2.1.x86_64
libkdepim4-4.14.2-1.1.x86_64
libkdepimlibs4-4.14.2-1.1.x86_64
libkdepimlibs4-devel-4.14.2-1.1.x86_64

Reproducible: Only if thrash folders contain a few hundred (unread) mails.

Steps to Reproduce:
1. normally use kmail / akonadi
2. delete unread mails that pile up in the trash folder

Actual Results:  
At some point akonadi / kmail locks up when trying to sync trash folders.

Expected Results:  
Trash folder will be synced
Comment 1 Denis Kurz 2016-09-24 20:41:40 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 2 Denis Kurz 2017-01-07 22:08:47 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.