On Tue, 2012-08-21 at 14:14 +0200, Toke Høiland-Jørgensen wrote:
> I believe the relevant output
> is this:
>
> [INFO @owncloud] @owncloud/contacts: starting first time sync, two-way (peer
> is server)
> [ERROR] sending message to child failed: org.freedesktop.DBus.Error.NoReply:
> Did not receive a reply. Possible causes include: the remote application did
> not send a reply, the message bus security policy blocked the reply, the
> reply timeout expired, or the network connection was broken.
> [INFO] Transport giving up after 0 retries and 0:25min
The message in this case is the internal message between local side and
target side. It is sent via a D-Bus method call:
void LocalTransportAgent::send(const char *data, size_t len)
{
if (m_child) {
m_status = ACTIVE;
m_child->m_sendMsg.start(m_contentType, GDBusCXX::makeDBusArray(len,
(uint8_t *)(data)),
boost::bind(&LocalTransportAgent::storeReplyMsg, this, _1, _2, _3));
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'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.
--
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
