Comment # 12 on bug 75672 from
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
slow sources:

* 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: