akonadi and it's impact on kde

[Volker Krause]

On Wednesday 25 February 2009 12:07:24 Kevin Krammer wrote:
> Adding cross-posting to KDE PIM development list.
>
> On Tuesday 24 February 2009, Michael Jansen wrote:
> > Because of commit
> > http://websvn.kde.org/trunk/kdesupport/akonadi/server/src/akonadi.cpp?r1=
> >92 2019&r2=931063 my akonadi failed to start. That's generally spoken no
> > problem. We all sometimes commit something that doesn't work.
> >
> > In this case the missing akonadi both killed kontact and krunner
> > completely for me. krunner refused to work. It got stuck in
> >
> > #0  0x00007f5fcece8d59 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > /lib64/libpthread.so.0
> > #1  0x00007f5fcef58849 in QWaitCondition::wait (this=0x88e850,
> > mutex=0x88e848, time=18446744073709551615) at
> > thread/qwaitcondition_unix.cpp:8
> > #2  0x00007f5fcef46ce8 in QFutureInterfaceBase::waitForResult
> > (this=0x7fffd97f0930, resultIndex=0) at
> > concurrent/qfutureinterface.cpp:295 #3  0x00007f5fb2c980bb in
> > QFuture<bool>::result (this=0x82ae5c) at
> > /usr/include/QtCore/qfuture.h:169
> > #4  0x00007f5fb2c93196 in KABC::ResourceAkonadi::asyncLoad
> > (this=0x836bf0) at
> > /home/mjansen/kde4svn/src/kdepim/kresources/akonadi/kabc/resour #5 
> > 0x00007f5fb3f8093b in KABC::AddressBook::asyncLoad (this=0x899aa0) at
> > /home/mjansen/kde4svn/src/kdepimlibs/kabc/addressbook.cpp:369
> > #6  0x00007f5fb3fa510c in KABC::StdAddressBook::Private::init
> > (this=0x8c18e0, asynchronous=true) at
> > /home/mjansen/kde4svn/src/kdepimlibs/kabc
> > #7  0x00007f5fb3fa57e8 in KABC::StdAddressBook::self (asynchronous=<value
> > optimized out>) at /home/mjansen/kde4svn/src/kdepimlibs/kabc/stdadd
> > #8  0x00007f5fb41e8192 in ContactsRunner (this=0x8c9370, parent=<value
> > optimized out>, args=<value optimized out>)
> >     at /home/mjansen/kde4svn/src/kdeplasma-
> > addons/runners/contacts/contactsrunner.cpp:42
> >
> > Kontact didn't show up at all. It run in the background but the gui
> > didn't come up.
> >
> > There was no way to find out that a missing akonadi was the problem.
>
> One of the problems is that those usages of Akonadi are not visible to the
> application since it is "hidden" in the compatibility layer.
>
> I should probably delay the "start Akonadi if it isn't running" to the
> plugin's open() method since it can indicate failure.
>
> Volker: any idea why the collection fetch job run by the worker thread does
> not exit with an error?
> (assuming that this is the reason the main thread is still waiting on the
> QFuture instance)

Akonadi::Session assumes that the connection loss to the server is temporary 
and keeps trying. AFAIK there is no timeout for this. See my other mail for 
possible solutions.

> > We should make sure that a missing helper application doesn't make the
> > kde desktop unusable. I can't even begin to imagine the bug reports if
> > such behavior happens to an end user.
>
> We do have better support for this for applications using Akonadi directly,
> e.g. lib functionality to disable Akonadi dependent widgets and have them
> show an error overlay.
>
> > Back to the wrong commit: line 236 It goes to the else section too if
> > there is no need to update the conf file.
> >
> > @rdieter: I would have fixed it, but i can guarantee i would have not
> > adhered to the coding style so please do it yourself.
>
> We (KDEPIM) started using reviewboard.kde.org for patches outside a
> developer's own code base (and for stuf they want to be reviewed anyway).
>
> The mistake might still have slipped through, but it minimizes the chances.

The patch was actually reviewed by me on IRC.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090225/55bea8da/attachment.sig>