Re: Akonadi dsaster
Daniel Vrátil <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Organization | KDE |
| Message-ID | <2103853.vaGgvUZQrU@mjollnir> |
On Saturday, October 8, 2016 12:39:30 AM CEST Martin Steigerwald wrote: > Hello! > > Am Mittwoch, 5. Oktober 2016, 09:19:19 CEST schrieb O. Sinclair: > > It is, and sorry for rant, but it is quite simply embarrasing that K9 > > mail on my android phone works better than KMail 5.x > > > > Akonadi was/is probably a nice concept but crash in this version not > > only on a daily but basically hourly basis. Noone seems to know just why > > the database thing goes bonkers all the time. > > > > I am dead tired of "akonadictl stop", "akondictl fsck" and "akonadictl > > start". Then wait while the mails from IMAP are downloaded once again > > though it is set to "offline IMAP". > > > > Can we "deAkonadi" KMail? > > While I still think Akonadi has some severe issues like moving of 1000nds of > mails from one maildir folder to another is almost as inefficient as it can > get and moving a complete folder even more so… > > and akonadi being basically single-tasking so that a background folder > synchronisation blocks out KMail… > > as well as Akonadi + Exchange IMAP something just not displaying new mail > via IMAP push to inbox without akonadictl stop ; start … Can I just get away with blaming silly Exchange? :-) I have an IMAP patch that adds loooots of debug messages to the IMAP resource session handling. Would you be able to compile the IMAP resource with it, so we maybe get more details as to what stalls the resource? > I do not have anything near daily crashes. > > This hints to me that something on your setup is different to my setup. > > And believe me I am probably one of the users with the most insane amount of > mails and folders in maildirs *ever*. > > More than 1 million mails in my regular maildir and I bet more than 500000 > maybe even another 1 million in archival folders that I excluded from > Akonadi Search indexing. > > I think its about time I also try to exclude IMAP folders from indexing… yet > I think with IMAP there may be the issue that it just doesn´t respect the > folder indexing setting. Or maybe its even completely ignored… but since I > didn´t access the archival folders anymore since last clearing Akonadi > search_db they are not indexed. It's true that the indexer currently ignores the NoIndexing attribute. That's bug and should be fixed. > > I agree that most likely crashes could be in Akonadi search. If there is a > special Xapian version that crashes, thats bad. That bug in Xapian 1.4 unfortunately hit a lot of users and led to a lot of frustration I'm afraid. > But there could be also > other reasons for crashes. Akonadi search is basically a renamed Baloo for > mails and there is a thread on kde-ml and kde-frameworks-ml now that Baloo > basically contains no error checking whatsoever for LMDB database accesses. > Dunno whether that applies to current incarnation of Akonadi search too. Akonadi Search is based on the old Xapian-based Baloo, which had a good error handling. Dan > > > In anyway, Akonadi for me is pretty much stable. I didn´t see an Akonadi > crash anymore in a time longer than I remember. > > So if its crashing for you *daily*, something seems to be different and it > could be helpful to stop ranting… and start describing what setup you > actually have. (That said I completely get the ranting part. Having issues > like that with a mail client you depend on is %&/§)=$/%. I completely get > that). > > Thanks, -- Daniel Vrátil www.dvratil.cz | [email protected] IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
signature.asc
(application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYAIhXAAoJEE1pVXrssTaDzb4QAI0xmVCZYCFJLcLa2/846Ajg JldE4vdHc/Vtkmj3EZIMISxo9INxiWVtY7WdvxwSlRN0+eT6zuHMzeOXIN6uVAjO kkDZujkL19e8kyFUVyxikNJ3rIF696z4jJu716hIUf9XpHiMmoN7yDD//irpyaUd 0OvTeNn7jDoDtfMS99qANpS9/gxiQ9Yt7Q0XFeY4xdCzFmS6+EWIQQstV4zemeDl Fbgvn1ncjdXYxKtEEXIaU/7lFAhOuV10fbqSoyUG+W8xpD4Pm+7cZPIFmMnxsd6v 9keTDtWirESA2yMzjJSGNEH821hWaxt3wO0P7RL6bjAqjgK0jpMVS4LYU1mqaVi+ 5UuN8W82ywYaeswAbgQWv/h0NM+XThBROHs+BhTQZeKnaZcSjr0ABVj8Ot2aAoZl dLe9fPLb51g1uxKK/B9NR9tArGfFD1igtOB0sylFDoUWew/UZzAib0KXuXEQh36H 2CLzidgeUVVwq8nPWw75tA0iXDbuUnABYUfb8eorJ2/YY7DpqTDVkwnhBdFmFg9h gyyoWxft4y2eQexQLnwdm9Dnx17+J2fwo5B9K+9umjaPyqmCWezgao6flCjwCYHQ cmPp2bR9rgb9YKtw+3oEt2YuYqFZZwvKwcKR7DVvXNx88Rp/mZdq1o0mwm9K/0by 8RcUZDS+0RXD227V9F+s =GAD6 -----END PGP SIGNATURE-----