Hi, this also seems to happen when dumpdata / printchanges is active and the server is too slow to dump all the data that is already there & process the first chunk of data that was sent by the phone in time.
Switching off dumpdata and printchanges is a workaround for now but this also limits the capabilities of finding data-issues in the sync process. I guess this is what I get for running owncloud (apache, php, mysql) and syncevolution on the same slow arm machine. But maybe there is a way of keeping the session open in this stage? Christof Am Donnerstag, 7. Februar 2013, 14:14:25 schrieb Patrick Ohly: > On Thu, 2013-02-07 at 13:46 +0100, Christof Schulze wrote: > > I started with a one-way-sync from phone to syncevo-http-server. > > This caused syncevolution to remove all data from owncloud, which is > > perfectly fine. However doing so takes about one second for each entry > > causing the phone to report a timeout after a while. > > What is your take on that? Shouldn't syncevo-http-server try to keep the > > session to the phone open? > The session is kept open; it's the phone decides that it is waiting too > long for a reply and therefore aborts. I know that the Synthesis SyncML > engine can send empty messages to inform the client that it is still > alive, but I am not familiar with how that works in detail. > Lukas, can you say more about this feature? When does it kick in? > > Maybe a better approach would be to clean all > > files at once on the webdav server to circumvent the timeout in the > > first place? > Did you do a "refresh" sync? > There are ways to let a backend wipe out data more efficiently. The > WebDAV backend doesn't support that at the moment, leading to a lot of > DELETE requests. As you said, this should be added. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
