Re: Kmail "Processing xxxxx of nnnnn messages"

On Monday 27 of January 2014 11:11:38 ianseeks wrote:
> On Monday 27 Jan 2014 11:19:25 Daniel Vrátil wrote:
> > On Sunday 26 of January 2014 17:14:33 ianseeks wrote:
> > > Hi
> > > 
> > > This message appears at the bottom left hand corner of the Kmail window
> > > during startup.  What is it doing?
> > > It stops Kmail marking messages as read whilst its going on.  Should
> > > this
> > > be a thread that runs in background and not affecting the foreground
> > > tasks?
> > 
> > It's showing how many emails in the just-opened folder have been retrieved
> > from Akonadi and sorted into threads.
> > 
> > During the process emails are constantly being fetched from Akonadi, and
> > because KMail uses only one "channel" to talk to Akonadi, it can't send
> > your request to mark an email as read until all messages are fetched and
> > the channel is free again.
> 
> Thanks for the explanation.  As there is a graphic part to this process of
> "marking as read", can't that be done whilst the actual update to the email
> storage is queued to be done once the "channel" becomes available again. 

Theoretically, yes, but the code and design is quite complicated. Might 
require a lot of changes.

> Is
> this "single channel" design a bit limiting, should there not be multi-
> threaded access in this day and age? (i don't know anything about akonadi
> really so i'm just throwing ideas in the air)

After a bit more check, it turned out that we already use two channels (one 
for fetching emails and one for writing changes), so the bottleneck is most 
probably on the Akonadi server, which is being too busy feeding KMail emails, 
and so it is unable to process the "Mark as read" request. I'll try to check 
whether we can optimize this somehow using priorities. Again, there are some 
related bug reports/feature requests regarding this.

Dan

> > I don't think there's anything we can do about it at this point, but in
> > future we would like to make Akonadi and KMail smarter, so that they only
> > fetch the emails you can see on the screen and then fetch more on demand
> > as
> > you scroll down. This will solve your problem, as well as many other
> > performance and memory issues :-)
> 
> Sounds like a possible solution or work-around. I presume the idea of
> caching the emails in the old "Mail" folders was dismissed.
> 
> > Cheers,
> > Dan
> > 
> > > regards
> > > 
> > > Ian
> > > _______________________________________________
> > > KDE PIM users mailing list
> > > Subscription management:
> > > https://mail.kde.org/mailman/listinfo/kdepim-users
> 
> _______________________________________________
> KDE PIM users mailing list
> Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

-- 
Daniel Vrátil
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAABAgAGBQJS5kLMAAoJEMWdYU9vSuNIC1QH/0vu+9q9UneozZeARQoiBToh
FQq5OZA7LgFxvMdoC1/LreKoDbZVCf3/tyYJkkglpxEndrCJ4/2JnPJ9b5u0UPba
wrrYHgaqXz7A+fFNld57foIuCS5j05K/NMNAX/4UsFZf00i20J00Ld88efwQxvvl
YPmYNQ8L1+7vzg+DhpWalmOn7LQdF1c49AwkZrKzFUDDC7QldJAQgZVcj6mPzZio
QxVm0V5XgpRarwOF2bxHCH5jWnIbRDcyYTFzEbwiOptLcxz4p4kl75KY1Bzu49Fc
Obsj29QhgBoef7A+XClMhI3TDQbpougUo3efLSteOiAMarJSiLsLCP7ODWPxXdI=
=AJEF
-----END PGP SIGNATURE-----