Den 21. aug. 2012 14:55, skrev Patrick Ohly:
> This should never time out. With libdbus, the method is sent in
> src/gdbus/gdbus-cxx-bridge.h:
>
> void send(DBusMessagePtr &msg, const Callback_t &callback)
> {
> DBusPendingCall *call;
> if (!dbus_connection_send_with_reply(m_conn.get(), msg.get(), &call,
> -1)) {
>
> ^^
>
> Infinite timeout?!
>
> Ooops! -1 selects the default timeout. SyncEvolution must pass
> DBUS_TIMEOUT_INFINITE here. Will fix that for 1.3.
I've looked at this function before, since things appeared to error out
here when I first tried to build syncevolution 1.2.99 with DAV support.
It turned out that the problem I had was that the other side had just
crashed because the backend couldn't load a required library, which I
eventually fixed. So it was not really a timeout, but a lost connection.
But I guess something like that is unlikely to be the problem in this
case, since at least some contacts seem to sync.
While debugging that problem, I did, however, find that
DBUS_TIMEOUT_INFINITE is not actually defined in the libdbus version
used on Harmattan. It's using version 1.4.6. And Fremantle is using
version 1.2.14. So it'd be nice if any fixes to this will still compile
with older versions of dbus.
Anyway, after I fixed the crash, I did not encounter further problems
with this timeout even with calendars that took a long time to sync. (I
did not try out contacts, since that code hadn't been touched anyway. I
suppose I could give it a go at some point.)
Oh, that reminds me, I've forgotten to mention that it seems error
propagation in SyncEvolution isn't as good as it used to be. For
example, in a CalDAV synchronization, throwing an exception in the kcal
backend's endSync() will still result in SyncEvolution reporting
"Synchronization successful" in both processes.
> I'm surprised that I am not seeing that timeout in tests for
> syncevolution.org binaries, which also use libdbus. Perhaps Harmattan
> uses a shorter default timeout.
We should probably also not forget the possibilities that
1) you've not been testing the QtContacts backend, and
2) the Tracker storage might also be much slower than a typical
workstation system with plenty of disk cache. It's slow enough that I
doubt the Harmattan developers would want to shorten the timeout.
The default timeout is 25 seconds. Did that much time actually pass
since this dbus request?
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
