--- Comment #12 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
The problem occurs when syncing executes the source initialization in a
background thread. Akonadi::ServerManager::isRunning() then returns false
despite Akonadi running.
This initialization in a thread was introduced to avoid timeout issues with
* engine: prevent timeouts in HTTP server mode
HTTP SyncML clients give up after a certain timeout (SyncEvolution
after RetryDuration = 5 minutes by default, Nokia e51 after 15
minutes) when the server fails to respond.
This can happen with SyncEvolution as server when it uses a slow
storage with many items, for example via WebDAV. In the case of slow
session startup, multithreading is now used to run the storage
initializing in parallel to sending regular "keep-alive" SyncML
replies to the client.
By default, these replies are sent every 2 minutes. This can be
configured with another extensions of the SyncMLVersion property:
SyncMLVersion = REQUESTMAXTIME=5m
Other modes do not use multithreading by default, but it can be
enabled by setting REQUESTMAXTIME explicitly. It can be disabled
by setting the time to zero.
The new feature depends on a libsynthesis with multithreading enabled
and glib >= 2.32.0, which is necessary to make SyncEvolution itself
thread-safe. With an older glib, multithreading is disabled, but can
be enabled as a stop-gap measure by setting REQUESTMAXTIME explicitly.
I checked, setting SyncMLVersion=REQUESTMAXTIME=0m in the sync config involving
the Akonadi sources works around the problem for me.
I'll check with the KDE devs to find out why
Akonadi::ServerManager::isRunning() fails in this scenario.
You are receiving this mail because:
You are on the CC list for the bug.