[Kde-pim] configuring Akonadi server

[Patrick Ohly]

On Mon, 2014-03-17 at 09:36 +0100, Daniel Vrátil wrote:
> $KDEHOME is by default $HOME/.kde or  $HOME/.kde4, depends on distributions, 
> so you got it right :-) But it's dangerous for testing, as it means Akonadi 
> works on top of your data.

Don't worry ;-). This home directory is created from scratch for running
the tests.

> > Now nightly testing with KDE has one last issue: when I run tests in
> > parallel under the same user ID with multiple different D-Bus sessions
> > and different homes (set via env variables), MySQL gets started multiple
> > times (as it should be), but then I get errors about "MySQL server has
> > gone away". I suspect the different instances of MySQL still conflict.
> 
> Sorry, I did not understand from your previous emails that you want to use 
> this for testing. We already have an infrastructure for running tests that 
> require Akonadi server. 
> 
> If you install kdepimlibs, you will automatically get and akonaditest utility 
> and akonadi_knut_resource installed.
> 
> The main advantage of akonaditest is that each test is ran in separated, clean 
> environment set up for each test into /tmp.

I don't want to introduce special cases for running Akonadi based tests.
I'd rather use the generic mechanism (cloning a clean home directory,
setting HOME and XDG env vars). This works except for this stability
issue, after tweaking the mechanism a bit (I noticed that I had to adapt
some hard-coded paths in akonadiserverrc and in the akonadi.db file).

> > I tried with sqlite. Now SyncEvolution randomly hangs, with gdb showing
> > that it is stuck in an Akonadi Job::exec() call:
> > 
> > #0  0x00007f0233f5b95d in poll () at ../sysdeps/unix/syscall-template.S:81
> > #1  0x00007f0234a89194 in g_main_context_poll (priority=2147483647, n_fds=3,
> > fds=0x2188090, timeout=-1, context=0x215dcf0) at
> > /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3995 #2  g_main_context_iterate
> > (context=context at entry=0x215dcf0, block=block at entry=1,
> > dispatch=dispatch at entry=1, self=<optimized out>) at
> > /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3696 #3  0x00007f0234a8929c in
> > g_main_context_iteration (context=0x215dcf0, may_block=1) at
> > /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3762
> > #4  0x00007f02375b5615 in
> > QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
> > () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> > #5  0x00007f0237586f9f in
> > QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
> > /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> > #6  0x00007f0237587295 in
> > QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
> > /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> > #7  0x00007f0237c9e683 in KJob::exec() () from /usr/lib/libkdecore.so.5
> > #8  0x00000000006321ad in SyncEvo::AkonadiSyncSource::getDatabases
> > (this=0x21f7670) at
> > /data/runtests/work/sources/syncevolution/src/backends/akonadi/akonadisyncs
> > ource.cpp:139 #9  0x00000000006e2bdc in SyncEvo::Cmdline::run
> > (this=this at entry=0x7fff4247aa20) at
> > /data/runtests/work/sources/syncevolution/src/syncevo/Cmdline.cpp:1257 #10
> > 0x00000000005d8bd6 in SyncEvo::main (argc=<optimized out>, argv=<optimized
> > out>) at
> > /data/runtests/work/sources/syncevolution/src/syncevolution.cpp:531
> 
> Could you please get full backtrace from akonadiserver process when this 
> happens? Looks like something gets stuck on the server and the Job is just 
> waiting for response endlessly.

I did not happen again in the latest test run. I'll keep an eye open for
it.

Bye, Patrick


_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/