On Thu, 2013-02-07 at 20:58 +0100, Christof Schulze wrote:
> This time I was able to capure some logging data. It seems that
> actually the phone does not decide that a timeout is reached but
> syncevolution does so - see log below.
This is the output of syncevo-http-server, right? Have you tried running
with --debug to see more output?
I'm particularly interested in the following output, which occurs when
the client disconnects:
def done(self, error):
'''lost connection to HTTP client, either normally or in error'''
logger.debug("done with request in session %s, error %s",
self.sessionid, error)
# keep connection to syncevo-dbus-server, client might still
# retry the request
self.request = None
I read the (less detailed) output that you quoted a bit differently:
"[ERROR] sync: /org/syncevolution/Session/11608689871360261428:
transport problem: send() on connection which is not ready" implies that
syncevo-dbus-server was not able to send back its reply via
syncevo-http-server, probably because the TCP connection of the POST had
been closed while the server was preparing the reply data.
In this case, it happened while receiving calendar data, so a more
efficient database zapping method would not have helped. What might help
is limiting the message size, because then less work needs to be done
per message and (hopefully fixed) message timeout.
You can do that by setting maxMsgSize in the phone's sync config to
something smaller than the default 150000 bytes. The --debug output will
include entries for the messages including their size, so you can check
whether the phone honors the server-side size limit (sent to it during
the initial SyncML handshake as part of the server's DevInf).
BTW, would it be able to use direct syncing via OBEX/Bluetooth instead
of going via HTTP? In that case, both sides can reliably detect a dead
peer because the link layer signals a loss of connection and thus there
should be no need for timeouts.
You seem to go for a solution where a micro server can serve clients
anywhere, so this might not be an option for you. I just thought I
mention it anyway...
--
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
