akonadi and it's impact on kde

[Volker Krause]

On Tuesday 24 February 2009 23:34:07 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.

Fixed in revision 931461, also backported to the Akonadi 1.1 branch.

> 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.

Kevin, isn't there a Akonadi::Control::start() call in the compat bridges that 
should have brought up the self-test dialog in case the server is not 
available?

> 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.

Obviously, this is not intended. Therefore, it's actually good that this 
happend now and we can fix it long before any user will ever see this.

The background here is that the affected applications are still using the old 
KResource-based synchronous API to retrieve the addressbook, which can cause 
problems like the one here. Which is one of the reasons for starting the 
development of Akonadi in the first place.

Kevin, I see two options to deal with a server connection loss in the 
synchronous job execution code: Add an option to Akonadi::Session to abort in 
this case instead of retrying or monitor the server status manually. The 
first seems easier and more robust. Still, we shouldn't get that far anyway, 
if Akonadi::Control::start() fails.

> 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.

As far as I am concerned, a quick fix is more important in such cases as 
following the coding style...

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/8b3a56d7/attachment.sig>