[kdepim-users] Kmail "Processing xxxxx of nnnnn messages"

[Daniel Vrátil]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20140127/0c2b4128/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users