On Tue, 2012-08-21 at 16:43 +0200, Ove Kåven wrote:
> 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.
I could pass a very long timeout (INT_MAX = 2147483647 millisecond =
2147483 seconds) as fallback. That should be long enough.
> 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 not aware of changes in that area. I'll have to test that.
> > 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?
In this case, yes. The log shows that initiating the sync on the target
side is busy for 25 seconds while downloading data from the CardDAV
server. Then the D-Bus timeout occurs and syncing shuts down, instead of
waiting until the download is complete.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
