Bug 252164

Summary:	KMail very slow after unchecking serverside subscription
Product:	[Unmaintained] KMail Mobile	Reporter:	Sabine Faure <sabine>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	bernhard, faure, tokoe, vkrause
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Sabine Faure 2010-09-23 19:03:28 UTC

Version:           unspecified (using Devel) 
OS:                Linux

The Imap synchronization takes a very long time the first time after unchecking the serverside subscription (after that it is a lot faster).

While the Imap synchronizes Kmail-mobile is slowed down on the N900 (dialogues take longer than usual to appear, same for emails...)

Reproducible: Always

Steps to Reproduce:
- Launch Kmail-mobile
- Connect an Akonadi console to your N900
- Click on your Imap account
- Open the 'Actions' tab
- Click on 'Account'
- Click on 'Edit account'
- Uncheck the 'Enable Server-Side Subscriptions' check box (it is checked by default)
- Click on 'Ok'
- Reopen 'Actions' tab
- Click on 'Synchronize emails in account'

Actual Results:  
The Imap sync is successfully launched as you can see from Akonadi console but it syncs very slowly at least the first time (more than 10 min).

While the Imap is syncing try to open a dialogue or read an email -> it works but it is quite slow

Expected Results:  
The first synchronization of the Imap resource after unchecking the 'Enable Server-Side Subscriptions' check box should not take that long.

Opening a dialogue or reading an email should be faster while the Imap in synchronizing for the first time after unchecking the box.

N900, 4:4.5~20100922.1178352-1maemo1.1177763

Comment 1 David Faure 2010-09-29 23:41:02 UTC

One of the issues is that while the imap resource is syncing one new big folder, it cannot reply to other requests such as those triggered by trying to read a mail in kmail. So these requests time out.

A dump on the scheduler showed it quite clearly:

akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump: ResourceScheduler: Online: true
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:  current task: 1362 SyncCollection collection 741
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:  queue 0 0 tasks:
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:  queue 1 0 tasks:
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:  queue 2 0 tasks:
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:  queue 3 3 tasks:
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:    1672 ChangeReplay collection -12688 item 26080
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:    1673 ChangeReplay collection -14000 item 26081
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:    1674 ChangeReplay collection -14001 item 26082
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:  queue 4 130 tasks:
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:    1363 SyncCollection collection 742
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:    1364 SyncCollection collection 743
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:    1365 SyncCollection collection 744
akonadi_imap_resource_2(14416)/libakonadi Akonadi::ResourceScheduler::dump:    1366 SyncCollection collection 745
[...]

So while it's getting collection 741, which takes a long time because it's a new folder with many emails, the "ChangeReplay" tasks for item 26080 and following, just time out. A bit later we could indeed see dbus timeout errors in the debug output, for these items.

I don't know what the solution is, though; this seems like a major architectural issue in akonadi, where synchronous dbus calls are made to resource which could be busy with a very long task...

Comment 2 Volker Krause 2010-11-29 09:14:52 UTC

*** Bug 257177 has been marked as a duplicate of this bug. ***

Comment 3 Tobias Koenig 2011-01-10 11:33:08 UTC

Hej,

is this still the case with current version? Email performance has been improved a lot in latest version.

Ciao,
Tobias

Comment 4 Sabine Faure 2011-01-14 22:59:02 UTC

I retested this today and it works a lot better indeed:

* Opening an email to read it takes between 5 and 12 seconds
* Opening a dialogue from a tab takes about 4 s
* Launching a Composer takes about 28 s

I think this is acceptable but Volker I'll let you decide whether you wish to close that bug or not.

N900, 4:4.6~.20110114.0754.git620f98b-1maemo1.121392