[Kde-pim] Review Request 112062: wait until the akonadiserver is ready

[Dan Vrátil]

> On Aug. 21, 2013, 6:40 p.m., Dan Vrátil wrote:
> > Thanks. However I'm still opposed to using sleep() and a loop. What about trying the connect to the AgentManager and if it fails then create a QDBusServiceWatcher that would watch for the AgentManager service to appear on DBus (the watcher will emit ownerChanged() signal) and try to connect to the AgentManager again from a slot connected to the ownerChanged() signal?
> 
> Guy Maurel wrote:
>     Well...
>     There is a point I don't anderstand how it could work. Let me explain what I think:
>     1. "trying the connect to the AgentManager"        ---> OK
>     2. "if it fails then create a QDBusServiceWatcher" ---> why not, OK
>     3. BUT here, what is to do with this call?
>        a) return
>        b) go on
>     What about the mManager which is not valid?
>     4. try to connect to the AgentManager              ---> at which time? from where?
>     
>     Some other parts of KDE are using sleep. Why should we don't use it?
>     akonadi/qsqlite/src/sqlite_blocking.cpp
>     akonadi/server/akonadictl/main.cpp
>     
>     automoc/kde4automoc.cpp
>     
>     kactivities/src/service/Resources.cpp
>     kactivities/src/service/plugins/sqlite/ResourceScoreMaintainer.cpp
>     
>     kde-baseapps/konqueror/client/kfmclient.cpp
>     kde-baseapps/nsplugins/nspluginloader.cpp
>     
>     kde-runtime/kioslave/fish/fish.cpp
>     
>     kde-workspace/ksmserver/screenlocker/ksldapp.cpp
>     
>     kdelibs/kdeui/util/kcrash.cpp
>     kdelibs/kdesu/process.cpp
>     
>     kdepim/kleopatra/libkleopatraclient/core/command.cpp
>     
>     kdevplatform/language/duchain/duchainlock.cpp
>     
>

Sorry for taking so long with this.

> 1. "trying the connect to the AgentManager"        ---> OK
> 2. "if it fails then create a QDBusServiceWatcher" ---> why not, OK
> 3. BUT here, what is to do with this call?
>   a) return

  Yes, return. The rest of the code in the method expects mManager to be valid, so there's no point calling methods on an invalid mManager.

>   b) go on
> What about the mManager which is not valid?

Nothing, keep it :)

> 4. try to connect to the AgentManager              ---> at which time? from where?

From a new slot connected to serviceOwnerChanged signal of the QDBusServiceWatcher.


- Dan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112062/#review38286
-----------------------------------------------------------


On Aug. 14, 2013, 6:29 p.m., Guy Maurel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112062/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2013, 6:29 p.m.)
> 
> 
> Review request for KDEPIM-Libraries, Dan Vrátil, Kevin Krammer, and Volker Krause.
> 
> 
> Description
> -------
> 
> "Bug 321186 - kmail doesn't filter the message, once a month".
> It is NOT a filter bug. 
> It is a synchronisation bug.
> 
> The first akonadi_agent which is started, lauches the akonadiserver.
> It takes a little time until the akonadiserver is "ready".
> If the client is too quick, the call to get a new 
>    org::freedesktop::Akonadi::AgentManager( ServerManager::serviceName( ServerManager::Control ),
> 
> doesn't give a valid manager.
> And the agent is going on...
> 
> In the case of akonadi_mailfilter_agent, the connection to get data for a filter rule <any header>
> doesn't work. The filter doesn't work. 
> 
> My proposal:
> A test-loop with a sleep( 1 ) until the manager is valid.
> At the most times, it takes about 2 - 3 seconds to become a valid manager.
> Using a DSL-Router at home, it could take much more, until the router is on. 
> I modify kdebug.cpp to get the time.
> 
> Here, starting kmail manualy:
> 18:37:31.245 kmail2(2400) KMKernel::KMKernel: Starting up...
> 18:37:31.459 kmail2(2400)/libakonadi Akonadi::SessionPrivate::init: "KMail Kernel ETM"
> 18:37:31.491 kmail2(2400)/libakonadi Akonadi::ServerManager::start: executing akonadi_control
> 18:37:31.586 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 0
> 18:37:32.588 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 1
> 18:37:33.588 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 2
> 18:37:34.590 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 3
> 18:37:35.590 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 4
> 18:37:36.591 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 5
> 18:37:37.592 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 6
> 18:37:38.593 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 7
> 18:37:39.593 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 8
> 18:37:40.594 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 9
> 18:37:41.595 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: waiting of akonadiserver ... 10
> 18:37:42.596 kmail2(2400)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: mManager is valid
> 
> 
> This addresses bug 321186.
>     http://bugs.kde.org/show_bug.cgi?id=321186
> 
> 
> Diffs
> -----
> 
>   akonadi/agentmanager.cpp 457a87d 
> 
> Diff: http://git.reviewboard.kde.org/r/112062/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Guy Maurel
> 
>

_______________________________________________
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/