4:46 a.m.
Hi,
Since syncevo-http-server is now running I was going to synchronize my
calender (4200 entries) with owncloud that already contained most of the
data.
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? Maybe a better approach would be to clean all
files at once on the webdav server to circumvent the timeout in the
first place?
Regards
Christof
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
5:14 a.m.
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.
--
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.
11:58 a.m.
Hi,
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.
I triggered the sync from the phone which does not give me the option to
specify the sync-type.
Can I sync only 1000 entries at a time?
[INFO] sync: /org/syncevolution/Session/11608689871360261428: calendar:
received 3513/4201
[INFO] sync: /org/syncevolution/Session/11608689871360261428: calendar: added
3513, updated 0, removed 0
[ERROR] dbus.connection: Exception in handler for D-Bus signal:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, in
maybe_handle_message
self._handler(*args, **kwargs)
File "/usr/local/bin/syncevo-http-server", line 154, in abort
self.destruct(http.INTERNAL_SERVER_ERROR, "lost connection to
SyncEvolution")
File "/usr/local/bin/syncevo-http-server", line 133, in destruct
File "/usr/local/bin/syncevo-http-server", line 133, in destruct
self.connection.Close(False, message)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in
__call__
**keywords)
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
DBusException: org.syncevolution.InvalidCall: cannot detach from resource that
client is not attached to
[ERROR] syncevo-dbus-server: /org/syncevolution/Server: cannot detach from
resource that client is not attached to
[ERROR] sync: /org/syncevolution/Session/11608689871360261428: transport
problem: send() on connection which is not ready
[INFO] sync: /org/syncevolution/Session/11608689871360261428: addressbook:
normal sync done unsuccessfully
[ERROR] sync: /org/syncevolution/Session/11608689871360261428: aborted on
behalf of user (local, status 20017)
[INFO] sync: /org/syncevolution/Session/11608689871360261428: calendar: first
time sync done unsuccessfully
[ERROR] sync: /org/syncevolution/Session/11608689871360261428: aborted on
behalf of user (local, status 20017)
[INFO] sync: /org/syncevolution/Session/11608689871360261428: creating
complete data backup after sync (enabled with dumpData and needed for
printChanges)
[ERROR] twisted: Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1349, in
dataReceived
finishCallback(data[contentLength:])
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1563, in
_finishRequestBody
self.allContentReceived()
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1618, in
allContentReceived
req.requestReceived(command, path, version)
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 773, in
requestReceived
self.process()
--- <exception caught here> ---
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 132, in
process
self.render(resrc)
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 167, in
render
body = resrc.render(self)
File "/usr/lib/python2.7/dist-packages/twisted/web/resource.py", line 216,
in render
return m(request)
File "/usr/local/bin/syncevo-http-server", line 325, in render_POST
session.process(request, data)
File "/usr/local/bin/syncevo-http-server", line 264, in process
self.connection.Process(data, type)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in
__call__
**keywords)
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: No
such interface `org.syncevolution.Connection' on object at path
/org/syncevolution/Connection/11608689871360261428
Regards
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
2:08 a.m.
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.
12:47 p.m.
On 07.02.2013, at 14:14, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
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?
This only works during loading the sync set, and only if libsynthesis is configured to
allow threads (<multithread> set). Then, the initial loading operation
(performStartSync()) is run in a separate thread while the main thread issues a (empty)
response every <requestmaxtime>.
However, the deletes that seem to cause the timeout are probably happening during
implStartDataWrite()/apiZapSyncSet(), which does not have the option to get executed in a
separate thread.
> 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.
Yes, a more efficient delete-all operation usually can solve this problem. The
libsynthesis plugin API has the option to implement a delete-all operation in
DeleteSyncSet(), only if it is not implemented, the engine will issue a row of single item
deletes.
Lukas
Lukas Zeller, plan44.ch
luz(a)plan44.ch - www.plan44.ch
2:38 a.m.
On Thu, 2013-02-07 at 21:47 +0100, Lukas Zeller wrote:
On 07.02.2013, at 14:14, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
> 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?
This only works during loading the sync set, and only if libsynthesis
is configured to allow threads (<multithread> set). Then, the initial
loading operation (performStartSync()) is run in a separate thread
while the main thread issues a (empty) response every
<requestmaxtime>.
I'm looking into enabling that for SyncEvolution. Some questions, if I
may...
With <subthreadmode>none</subthreadmode> for logging, is the shared
logger instance really thread-safe, or should this mode rather be
avoided? I don't see any mutex locking.
My understanding is that logging will not look nice when different
threads open and close blocks in the wrong order in the same .html file,
which does indeed happen when 'ReadSyncSet' block continues while the
main thread sends an intermediate reply. So that alone may be a reason
to avoid the single-file approach, although multiple files will make
debugging harder.
Which defines do I need to change where to enable thread support? There
is a comment in "define.h" which says that the __MAKE_THREADSAFE option
was moved to "target_options.h", but I don't see that option there.
__MAKE_THREADSAFE seems to be for the SyncML Toolkit. For the Synthesis
engine, I am setting MULTI_THREAD_SUPPORT and MULTI_THREAD_DATASTORE in
"target_options.h". Does that sound right? Patch attached.
--
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.
8:12 a.m.
On 17.04.2013, at 11:38, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
>> [...]
>> Lukas, can you say more about this feature? When does it kick in?
>
> This only works during loading the sync set, and only if libsynthesis
> is configured to allow threads (<multithread> set). Then, the initial
> loading operation (performStartSync()) is run in a separate thread
> while the main thread issues a (empty) response every
> <requestmaxtime>.
I'm looking into enabling that for SyncEvolution. Some questions, if I
may...
Of course :-)
With <subthreadmode>none</subthreadmode> for logging, is
the shared
logger instance really thread-safe, or should this mode rather be
avoided? I don't see any mutex locking.
It is not thread safe by itself, but relies on file io to serialize the output (kind of).
But as you say:
My understanding is that logging will not look nice when different
threads open and close blocks in the wrong order in the same .html file,
which does indeed happen when 'ReadSyncSet' block continues while the
main thread sends an intermediate reply. So that alone may be a reason
to avoid the single-file approach,
Exactly. To make that work, quite elaborate block hierarchy aware inserting of
subthread's output would be needed (like temporarily closing all left-open blocks of
the subthread logger after inserting a subthread's output and re-opening them at the
beginning of the next subthread output chunk).
I never bothered to implement this (although the structure of the logging system would
allow it) just because...
although multiple files will make debugging harder.
...the split logfiles were easy to work with. The task done in a subthread is precisely
defined - loading the syncset for a datastore. Only if there's was something related
to loading the sync set to debug, the thread logs had to be examined. In all other cases,
the main log contained everything, including clickable links to the subthread logs :-) The
main log also gets less monstrous in size...
Which defines do I need to change where to enable thread support?
There
is a comment in "define.h" which says that the __MAKE_THREADSAFE option
was moved to "target_options.h", but I don't see that option there.
__MAKE_THREADSAFE seems to be for the SyncML Toolkit.
Yes. Related history is as follows: Initially, the SyncML toolkit as coded by IBM (...)
had lots of globals. When the subject of a multi-threaded server came up first, I had no
clue about the toolkit's internals and tried to insert mutexes to protect the globals
as a first attempt. That's where that __MAKE_THREADSAFE comes from. This approach
failed, and when I understood the code better I found that all of the globals were related
to the totally unnecessary (in libsynthesis context) "work space manager", so
the solution was to rip WSM out (#define NOWSM). This made the SML instance free of
globals and thus safe to use in a multithreaded server (one thread per session).
For the Synthesis engine, I am setting MULTI_THREAD_SUPPORT and
MULTI_THREAD_DATASTORE in
"target_options.h". Does that sound right?
Yes :-)
However, I would not recommend to set __MAKE_THREADSAFE. Best case was that it would do
nothing, but that route was abandoned 12 years ago and never tested again, so it might
also make the SmlTk fall apart...
Best Regards,
Lukas Zeller
9:17 a.m.
On Wed, 2013-04-17 at 17:12 +0200, Lukas Zeller wrote:
> For the Synthesis engine, I am setting MULTI_THREAD_SUPPORT and
MULTI_THREAD_DATASTORE in
> "target_options.h". Does that sound right?
Yes :-)
However, I would not recommend to set __MAKE_THREADSAFE. Best case was
that it would do nothing, but that route was abandoned 12 years ago
and never tested again, so it might also make the SmlTk fall apart...
It seems to work, but I'll remove it again anyway.
One more question, to you and/or Christof: in your experience, how
quickly do phones give up? In other words, what is the recommended value
of <requestmaxtime>?
I'm currently considering to make one minute the default for all HTTP
clients.
--
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.
1:30 p.m.
Hello Patrick,
On 23.04.2013, at 18:17, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Wed, 2013-04-17 at 17:12 +0200, Lukas Zeller wrote:
One more question, to you and/or Christof: in your experience, how
quickly do phones give up? In other words, what is the recommended value
of <requestmaxtime>?
I'm currently considering to make one minute the default for all HTTP
clients.
Years ago, the device that caused me implementing this was the Ericsson T68i which had no
more than 30 seconds "patience".
Looking at the default config of the server, it seems that we settled on 120 seconds for
the global <requestmaxtime>. However it is possible to set a per-device
<requestmaxtime> in the remote rule. Curiously, the T68i in the sample config does
not set 30 seconds, though. Maybe later revisions had a more generous timeout, or nobody
used that device ever again...
Best Regards,
Lukas
8:42 a.m.
Hello,
Am Montag, 13. Mai 2013, 22:30:58 schrieb Lukas Zeller:
Hello Patrick,
On 23.04.2013, at 18:17, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
> On Wed, 2013-04-17 at 17:12 +0200, Lukas Zeller wrote:
> One more question, to you and/or Christof: in your experience, how
> quickly do phones give up? In other words, what is the recommended value
> of <requestmaxtime>?
> I'm currently considering to make one minute the default for
all HTTP
> clients.
Years ago, the device that caused me implementing this was the
Ericsson T68i
which had no more than 30 seconds "patience".
Looking at the default config of the server, it seems that we settled
on 120
seconds for the global <requestmaxtime>. However it is possible to set a
per-device <requestmaxtime> in the remote rule. Curiously, the T68i in the
sample config does not set 30 seconds, though. Maybe later revisions had a
more generous timeout, or nobody used that device ever again...
Does that mean I
can already set a larger timeout for my nokia e51?
Say... 2 hours?
Christof
Best Regards,
Lukas
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
12:14 p.m.
On Mon, 2013-05-20 at 17:42 +0200, Christof Schulze wrote:
Hello,
Am Montag, 13. Mai 2013, 22:30:58 schrieb Lukas Zeller:
> Hello Patrick,
> On 23.04.2013, at 18:17, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > On Wed, 2013-04-17 at 17:12 +0200, Lukas Zeller wrote:
> > One more question, to you and/or Christof: in your experience, how
> > quickly do phones give up? In other words, what is the recommended value
> > of <requestmaxtime>?
> > I'm currently considering to make one minute the default for all HTTP
> > clients.
> Years ago, the device that caused me implementing this was the Ericsson T68i
> which had no more than 30 seconds "patience".
> Looking at the default config of the server, it seems that we settled on 120
> seconds for the global <requestmaxtime>. However it is possible to set a
> per-device <requestmaxtime> in the remote rule. Curiously, the T68i in the
> sample config does not set 30 seconds, though. Maybe later revisions had a
> more generous timeout, or nobody used that device ever again...
Does that mean I can already set a larger timeout for my nokia e51?
Say... 2 hours?
Not in the normal SyncEvolution, because it didn't use the feature that
Lukas described.
But in the meantime I have implemented the necessary changes
(thread-safety, config option) in SyncEvolution, so when compiling from
source it is possible. Hmm, I thought I had sent you an email about
that, but I can't find it.
If you want a tar ball, try this:
http://downloads.syncevolution.org/tmp/syncevolution-1.3.99.3%2b20130514%...
It should use the feature by default. The full documentation is this:
'--sync-property SyncMLVersion=?'
On a client, the latest commonly supported SyncML version
is used when contacting a server. One of '1.0/1.1/1.2' can
be used to pick a specific version explicitly.
On a server, this option controls what kind of Server Alerted
Notification is sent to the client to start a synchronization.
By default, first the format from 1.2 is tried, then in case
of failure, the older one from 1.1. 1.2/1.1 can be set
explicitly, which disables the automatism.
Instead or in adddition to the version, several keywords can
be set in this property (separated by spaces or commas):
- NOCTCAP - avoid sending CtCap meta information
- NORESTART - disable the sync mode extension that SyncEvolution
client and server use to negotiate whether both sides support
running multiple sync iterations in the same session
- REQUESTMAXTIME=<time> - override the rate at which the
SyncML server sends preliminary replies while preparing
local storages in the background. This helps to avoid timeouts
in the SyncML client. Depends on multithreading.
This SyncEvolution binary is thread-safe and thus this feature
is enabled by default for HTTP servers, with a delay of 2 minutes
between messages. Other servers (Bluetooth, local sync) should not
need preliminary replies and the feature is disabled, although
it can be enabled by setting the time explicitly.
<time> can be specified like other durations in the config,
for example as REQUESTMAXTIME=2m.
Setting these flags should only be necessary as workaround for
broken peers.
--
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.
2:22 p.m.
Hello,
If you want a tar ball, try this:
http://downloads.syncevolution.org/tmp/syncevolution-1.3.99.3%2b20130514%2bS
E%2bde24470%2bunclean%2bSYSYNC%2b3366831.tar.gz
It should use the feature by default. The full documentation is this:
I finally managed to use some spare cpu cycles to compile this version.
When Running it however the debug log shows upon connect:
[DEBUG] syncevo-http: processing incoming message of type
application/vnd.syncml+wbxml and length 404, binary data
[DEBUG] syncevo-http: requesting new session
[ERROR] twisted: Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1349, in
dataReceived
finishCallback(data[contentLength:])
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1563, in
_finishRequestBody
self.allContentReceived()
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1618, in
allContentReceived
req.requestReceived(command, path, version)
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 773, in
requestReceived
self.process()
--- <exception caught here> ---
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 132, in
process
self.render(resrc)
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 167, in
render
body = resrc.render(self)
File "/usr/lib/python2.7/dist-packages/twisted/web/resource.py", line 216,
in render
return m(request)
File "/usr/local/bin/syncevo-http-server", line 299, in render_POST
urlparse.urljoin(self.url.geturl(), request.path))
File "/usr/local/bin/syncevo-http-server", line 205, in start
self.object = Context.getDBusServer()
File "/usr/local/bin/syncevo-http-server", line 89, in getDBusServer
'/org/syncevolution/Server'),
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in
__init__
self._named_service = conn.activate_name_owner(bus_name)
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in
activate_name_owner
self.start_service_by_name(bus_name)
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in
start_service_by_name
'su', (bus_name, flags)))
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited:
Process /usr/local/libexec/syncevo-dbus-server exited with status 127
[DEBUG] twisted: 213.211.221.128 - - [29/Jun/2013:21:19:09 +0000] "POST /sync
HTTP/1.1" 500 11880 "-" "Nokia SyncML HTTP Client"
Needless to say - there is no sync working. How can I get a more useful
error message than "unhandled Error"?
Regards
Christof
Am Montag, 20. Mai 2013, 21:14:35 schrieb Patrick Ohly:
> Am Montag, 13. Mai 2013, 22:30:58 schrieb Lukas Zeller:
> > Hello Patrick,
> > On 23.04.2013, at 18:17, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> > > On Wed, 2013-04-17 at 17:12 +0200, Lukas Zeller wrote:
One
> > > more question, to you and/or Christof: in your experience, how
> > > quickly do phones give up? In other words, what is the
> > > recommended value of <requestmaxtime>?
> > > I'm currently considering to make one minute the
default for
> > > all Http clients.
> > Years ago, the device that caused me implementing this was
the
> > Ericsson T68i which had no more than 30 seconds "patience".
> > Looking at the default config of the server, it seems that
we
> > settled on 120 seconds for the global <requestmaxtime>. However
> > it is possible to set a per-device <requestmaxtime> in the
> > remote rule. Curiously, the T68i in the sample config does not
> > set 30 seconds, though. Maybe later revisions had a more
> > generous timeout, or nobody used that device ever again...
> Does that mean I can already set a larger timeout for my nokia
> e51? Say... 2 hours?
Not in the normal Syncevolution, because it didn't use the
feature
that Lukas described.
But in the meantime I have implemented the necessary changes
(thread-safety, config option) in Syncevolution, so when compiling
from source it is possible. Hmm, I thought I had sent you an email
about that, but I can't find it.
'--sync-property SyncMLVersion=?'
On a client, the latest commonly supported SyncML version
is used when contacting a server. One of '1.0/1.1/1.2' can
be used to pick a specific version explicitly.
On a server, this option controls what kind of Server Alerted
Notification is sent to the client to start a synchronization.
By default, first the format from 1.2 is tried, then in case
of failure, the older one from 1.1. 1.2/1.1 can be set
explicitly, which disables the automatism.
Instead or in adddition to the version, several keywords can
be set in this property (separated by spaces or commas):
- NOCTCAP - avoid sending CtCap meta information
- NORESTART - disable the sync mode extension that SyncEvolution
client and server use to negotiate whether both sides support
running multiple sync iterations in the same session
- REQUESTMAXTIME=<time> - override the rate at which the
SyncML server sends preliminary replies while preparing
local storages in the background. This helps to avoid timeouts
in the SyncML client. Depends on multithreading.
This SyncEvolution binary is thread-safe and thus this feature
is enabled by default for HTTP servers, with a delay of 2minutes
between messages. Other servers (Bluetooth, local sync) should not
need preliminary replies and the feature is disabled, although
it can be enabled by setting the time explicitly.
<time> can be specified like other durations in the config,
for example as REQUESTMAXTIME=2m.
Setting these flags should only be necessary as workaround
for
broken peers.
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
10:25 a.m.
On Sat, 2013-06-29 at 23:22 +0200, Christof Schulze wrote:
Hello,
> If you want a tar ball, try this:
http://downloads.syncevolution.org/tmp/syncevolution-1.3.99.3%2b20130514%2bS
> E%2bde24470%2bunclean%2bSYSYNC%2b3366831.tar.gz
> It should use the feature by default. The full documentation is this:
I finally managed to use some spare cpu cycles to compile this version.
When Running it however the debug log shows upon connect:
[DEBUG] syncevo-http: processing incoming message of type
application/vnd.syncml+wbxml and length 404, binary data
[DEBUG] syncevo-http: requesting new session
[ERROR] twisted: Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1349, in
dataReceived
finishCallback(data[contentLength:])
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1563, in
_finishRequestBody
self.allContentReceived()
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1618, in
allContentReceived
req.requestReceived(command, path, version)
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 773, in
requestReceived
self.process()
--- <exception caught here> ---
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 132, in
process
self.render(resrc)
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 167, in
render
body = resrc.render(self)
File "/usr/lib/python2.7/dist-packages/twisted/web/resource.py", line 216,
in render
return m(request)
File "/usr/local/bin/syncevo-http-server", line 299, in render_POST
urlparse.urljoin(self.url.geturl(), request.path))
File "/usr/local/bin/syncevo-http-server", line 205, in start
self.object = Context.getDBusServer()
File "/usr/local/bin/syncevo-http-server", line 89, in getDBusServer
'/org/syncevolution/Server'),
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in
__init__
self._named_service = conn.activate_name_owner(bus_name)
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in
activate_name_owner
self.start_service_by_name(bus_name)
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in
start_service_by_name
'su', (bus_name, flags)))
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited:
Process /usr/local/libexec/syncevo-dbus-server exited with status 127
[DEBUG] twisted: 213.211.221.128 - - [29/Jun/2013:21:19:09 +0000] "POST /sync
HTTP/1.1" 500 11880 "-" "Nokia SyncML HTTP Client"
Needless to say - there is no sync working. How can I get a more useful
error message than "unhandled Error"?
As a first step, run "syncevo-http-server" with "--debug" as
argument.
But the failure seems to be in syncevo-dbus-server, so it may be easier
to start it manually in a separate shell. Make sure that both
syncevo-http-server and syncevo-dbus-server have the same
DBUS_SESSION_BUS_ADDRESS env variable.
--
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.
5:14 a.m.
Hello,
After a while of fiddling, I found out that running ldconfig solved the
syncevo.dbus-server problem.
Now, one step further, and having a requestmaxtime of 30 minutes set I
am seeing this:
[DEBUG] syncevo-http: reply session 13220194751373803087 connection
/org/syncevolution/Connection/13220194751373803087 (active
/org/syncevolution/Connection/13220194751373803087) final 0 data len 7426
dbus.Dictionary({dbus.UTF8String('URL'): dbus.UTF8String('')},
signature=dbus.Signature('ss'))
[DEBUG] syncevo-http: processing outgoing message of type
application/vnd.syncml+wbxml and length 7426, binary data
[DEBUG] twisted: 213.211.221.128 - - [14/Jul/2013:11:58:20 +0000] "POST /sync
HTTP/1.1" 200 7426 "-" "Nokia SyncML HTTP Client"
[DEBUG] syncevo-http: done with request in session None, error None
[DEBUG] syncevo-http: POST from 213.211.221.128 config type
application/vnd.syncml+wbxml session 13220194751373803087 args {'sessionid':
['13220194751373803087']} length 65530
[DEBUG] syncevo-http: processing incoming message of type
application/vnd.syncml+wbxml and length 65530, binary data
[INFO] sync: /org/syncevolution/Session/13220194751373803087: addressbook:
starting normal sync from client (peer is client)
[INFO] sync: /org/syncevolution/Session/13220194751373803087: calendar:
starting slow sync from client (peer is client)
[INFO] sync: /org/syncevolution/Session/13220194751373803087: addressbook:
started
[ERROR] sync: /org/syncevolution/Session/13220194751373803087: transport
problem: updateAllSubItems REPORT 'list items': Neon error code 6, no HTTP
status: Could not read status line: connection timed out
[INFO] sync: /org/syncevolution/Session/13220194751373803087: calendar: slow
sync done unsuccessfully
[ERROR] sync: /org/syncevolution/Session/13220194751373803087: external
transport failure (local, status 20043)
[DEBUG] syncevo-http: reply session 13220194751373803087 connection
/org/syncevolution/Connection/13220194751373803087 (active
/org/syncevolution/Connection/13220194751373803087) final 0 data len 2080
dbus.Dictionary({dbus.UTF8String('URL'): dbus.UTF8String('')},
signature=dbus.Signature('ss'))
[DEBUG] syncevo-http: processing outgoing message of type
application/vnd.syncml+wbxml and length 2080, binary data
[DEBUG] twisted: 213.211.221.128 - - [14/Jul/2013:12:04:28 +0000] "POST
/sync?sessionid=13220194751373803087 HTTP/1.1" 200 2080 "-" "Nokia
SyncML HTTP
Client"
[DEBUG] syncevo-http: done with request in session 13220194751373803087, error
None
[DEBUG] syncevo-http: POST from 213.211.221.128 config type
application/vnd.syncml+wbxml session 13220194751373803087 args {'sessionid':
['13220194751373803087']} length 299
[DEBUG] syncevo-http: processing incoming message of type
application/vnd.syncml+wbxml and length 299, binary data
[INFO] sync: /org/syncevolution/Session/13220194751373803087: addressbook:
normal sync done successfully
[INFO] sync: /org/syncevolution/Session/13220194751373803087: calendar: slow
sync done unsuccessfully
[ERROR] sync: /org/syncevolution/Session/13220194751373803087: external
transport failure (local, status 20043)
[DEBUG] syncevo-http: reply session 13220194751373803087 connection
/org/syncevolution/Connection/13220194751373803087 (active
/org/syncevolution/Connection/13220194751373803087) final 0 data len 311
dbus.Dictionary({dbus.UTF8String('URL'): dbus.UTF8String('')},
signature=dbus.Signature('ss'))
[DEBUG] syncevo-http: processing outgoing message of type
application/vnd.syncml+wbxml and length 311, binary data
[DEBUG] twisted: 213.211.221.128 - - [14/Jul/2013:12:05:19 +0000] "POST
/sync?sessionid=13220194751373803087 HTTP/1.1" 200 311 "-" "Nokia
SyncML HTTP
Client"
[DEBUG] syncevo-http: done with request in session 13220194751373803087, error
None
[INFO] sync: /org/syncevolution/Session/13220194751373803087:
Synchronization failed, see
/home/christof/.cache/syncevolution/christofphon-2013-07-14-11-58/syncevolution-
log.html for details.
[INFO] sync: /org/syncevolution/Session/13220194751373803087:
Changes applied during synchronization:
[INFO] sync: /org/syncevolution/Session/13220194751373803087:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| one-way-from-remote, 0 KB sent by client, 0 KB received |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 58 KB received |
| external transport failure (local, status 20043) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| todo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Jul 14 11:58:08 2013, duration 7:12min |
| incomplete sync session (local, status 20023) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: transport problem: updateAllSubItems REPORT 'list
items': Neon error code 6, no HTTP status: Could not read status line:
connection timed out
[ERROR] sync: /org/syncevolution/Session/13220194751373803087: error code from
SyncEvolution incomplete sync session (local, status 20023): sync failed
[DEBUG] syncevo-http: connection
/org/syncevolution/Connection/13220194751373803087 went down, active
connection /org/syncevolution/Connection/13220194751373803087
[DEBUG] syncevo-http: destructing connection
/org/syncevolution/Connection/13220194751373803087 with code 500 message lost
connection to SyncEvolution
[DEBUG] syncevo-http: self.connection.Close() failed, connection probably
already gone: org.freedesktop.DBus.Error.UnknownMethod: No such interface
`org.syncevolution.Connection' on object at path
/org/syncevolution/Connection/13220194751373803087
[DEBUG] syncevo-http: removed SyncML session <__main__.SyncMLSession instance
at 0x902fa8>
[ERROR] sync: /org/syncevolution/Session/13220194751373803087: sess:
Destroying session.
I am guessing that this is due to a connection timeout to the webdav
server. If so, how can I increase that?
Christof
Am Sonntag, 30. Juni 2013, 19:25:20 schrieben Sie:
On Sat, 2013-06-29 at 23:22 +0200, Christof Schulze wrote:
> Hello,
> > If you want a tar ball, try this:
> http://downloads.syncevolution.org/tmp/syncevolution-1.3.99.3%2b20130514%2
> bS>
> > E%2bde24470%2bunclean%2bSYSYNC%2b3366831.tar.gz
> > It should use the feature by default. The full
documentation is this:
> I finally managed to use some spare cpu cycles to compile this version.
> When Running it however the debug log shows upon connect:
> [DEBUG] syncevo-http: processing incoming message of type
> application/vnd.syncml+wbxml and length 404, binary data
> [DEBUG] syncevo-http: requesting new session
> [ERROR] twisted: Unhandled Error
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1349,
> in
> dataReceived
> finishCallback(data[contentLength:])
> File
"/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1563,
> in
> _finishRequestBody
> self.allContentReceived()
> File
"/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1618,
> in
> allContentReceived
> req.requestReceived(command, path, version)
> File
"/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 773,
> in
> requestReceived
> self.process()
> --- <exception caught here> ---
> File
"/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 132,
> in
> process
> self.render(resrc)
> File
"/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 167,
> in
> render
> body = resrc.render(self)
> File
"/usr/lib/python2.7/dist-packages/twisted/web/resource.py", line
> 216,
> in render
> return m(request)
> File "/usr/local/bin/syncevo-http-server", line 299,
in render_POST
> urlparse.urljoin(self.url.geturl(), request.path))
> File "/usr/local/bin/syncevo-http-server", line 205,
in start
> self.object = Context.getDBusServer()
> File "/usr/local/bin/syncevo-http-server", line 89,
in getDBusServer
> '/org/syncevolution/Server'),
> File "/usr/lib/python2.7/dist-packages/dbus/bus.py",
line 241, in
> get_object>
> follow_name_owner_changes=follow_name_owner_changes)
> File
"/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in
> __init__
> self._named_service = conn.activate_name_owner(bus_name)
> File "/usr/lib/python2.7/dist-packages/dbus/bus.py",
line 180, in
> activate_name_owner
> self.start_service_by_name(bus_name)
> File "/usr/lib/python2.7/dist-packages/dbus/bus.py",
line 278, in
> start_service_by_name
> 'su', (bus_name, flags)))
> File
"/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException:
> org.freedesktop.DBus.Error.Spawn.ChildExited: Process
> /usr/local/libexec/syncevo-dbus-server exited with status 127
> [DEBUG] twisted: 213.211.221.128 - - [29/Jun/2013:21:19:09
+0000] "POST
> /sync HTTP/1.1" 500 11880 "-" "Nokia SyncML HTTP Client"
> Needless to say - there is no sync working. How can I get a more
useful
> error message than "unhandled Error"?
As a first step, run "syncevo-http-server" with
"--debug" as argument.
But the failure seems to be in syncevo-dbus-server, so it may be
easier
to start it manually in a separate shell. Make sure that both
syncevo-http-server and syncevo-dbus-server have the same
DBUS_SESSION_BUS_ADDRESS env variable.
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
12:15 p.m.
On Sun, 2013-07-14 at 14:14 +0200, Christof Schulze wrote:
[INFO] sync: /org/syncevolution/Session/13220194751373803087:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| one-way-from-remote, 0 KB sent by client, 0 KB received |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 58 KB received |
| external transport failure (local, status 20043) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| todo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Jul 14 11:58:08 2013, duration 7:12min |
| incomplete sync session (local, status 20023) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: transport problem: updateAllSubItems REPORT 'list
items': Neon error code 6, no HTTP status: Could not read status line:
connection timed out
[...]
I am guessing that this is due to a connection timeout to the webdav
server.
Yes, looks like it. "connection timed out" is a low-level Unix error
code for a failure to establish (or use) a TCP connection.
If so, how can I increase that?
Tweaking the TCP timeout values is possible in theory, but not
implemented by SyncEvolution. Instead it resends HTTP requests which are
idempotent (= can be tried again because if they were already executed,
making the server execute them again will have the same end result). In
this case, a query for information could be sent again, and NeonCXX.cpp
Session::checkError() has a case for error code 6 = NE_TIMEOUT:
case NE_LOOKUP:
case NE_TIMEOUT:
case NE_CONNECT:
retry = true;
break;
Also, CalDAVSource::updateAllSubItems() has a while loop over the
execution of the report.
Can you check in the server's log for that session whether it really
tried the "updateAllSubItems REPORT" multiple times? You probably need
to run with a higher log level to see the HTTP traffic for the REPORT.
The "updateAllSubItems REPORT 'list items'" line might only be printed
once.
--
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.
5:16 p.m.
Am Sonntag, 14. Juli 2013, 21:15:08 schrieb Patrick Ohly:
> I am guessing that this is due to a connection timeout to the
webdav
> server.
Yes, looks like it. "connection timed out" is a low-level Unix error
code for a failure to establish (or use) a TCP connection.
> If so, how can I increase that?
Tweaking the TCP timeout values is possible in theory, but not
implemented by SyncEvolution. Instead it resends HTTP requests which
are idempotent (= can be tried again because if they were already
executed, making the server execute them again will have the same end
result). In this case, a query for information could be sent again,
and NeonCXX.cpp Session::checkError() has a case for error code 6 =
NE_TIMEOUT:
case NE_LOOKUP:
case NE_TIMEOUT:
case NE_CONNECT:
retry = true;
break;
Also, CalDAVSource::updateAllSubItems() has a while loop over the
execution of the report.
Can you check in the server's log for that session whether it
really
tried the "updateAllSubItems REPORT" multiple times? You probably need
to run with a higher log level to see the HTTP traffic for the REPORT.
The "updateAllSubItems REPORT 'list items'" line might only be printed
once.
this is the full server log with the server having the debug flag set:
[DEBUG] syncevo-http: POST from 192.168.142.85 config type
application/vnd.syncml+wbxml session None args {} length 299
[INFO] syncevo-http: new SyncML session for 192.168.142.85
[DEBUG] syncevo-http: processing incoming message of type
application/vnd.syncml+wbxml and length 299, binary data
[DEBUG] syncevo-http: requesting new session
[DEBUG] syncevo-http: started new connection
/org/syncevolution/Connection/5130385871373932780
[DEBUG] syncevo-http: added new SyncML session <__main__.SyncMLSession
instance at 0x9b8030>
[INFO] syncevo-dbus-server: /org/syncevolution/Server: ready to run
[INFO] syncevo-dbus-server: /org/syncevolution/Server: matched deviceID
IMEI:XXXXXXXXXXXXXXXXXXXX against config christofphon
(/home/christof/.config/syncevolution/default/peers/christofphon)
[DEBUG] syncevo-http: reply session 5130385871373932780 connection
/org/syncevolution/Connection/5130385871373932780 (active
/org/syncevolution/Connection/5130385871373932780) final 0 data len 3253
dbus.Dictionary({dbus.UTF8String('URL'): dbus.UTF8String('')},
signature=dbus.Signature('ss'))
[DEBUG] syncevo-http: processing outgoing message of type
application/vnd.syncml+wbxml and length 3253, binary data
[DEBUG] twisted: 192.168.142.85 - - [15/Jul/2013:23:59:48 +0000] "POST /sync
HTTP/1.1" 200 3253 "-" "Nokia SyncML HTTP Client"
[DEBUG] syncevo-http: done with request in session None, error None
[DEBUG] syncevo-http: POST from 192.168.142.85 config type
application/vnd.syncml+wbxml session 5130385871373932780 args {'sessionid':
['5130385871373932780']} length 65276
[DEBUG] syncevo-http: processing incoming message of type
application/vnd.syncml+wbxml and length 65276, binary data
[INFO] sync: /org/syncevolution/Session/5130385871373932780: calendar:
starting slow sync from client (peer is client)
[ERROR] sync: /org/syncevolution/Session/5130385871373932780: transport
problem: updateAllSubItems REPORT 'list items': Neon error code 6, no HTTP
status: Could not read status line: connection timed out
[INFO] sync: /org/syncevolution/Session/5130385871373932780: calendar: slow
sync done unsuccessfully
[ERROR] sync: /org/syncevolution/Session/5130385871373932780: external
transport failure (local, status 20043)
[DEBUG] syncevo-http: reply session 5130385871373932780 connection
/org/syncevolution/Connection/5130385871373932780 (active
/org/syncevolution/Connection/5130385871373932780) final 0 data len 2006
dbus.Dictionary({dbus.UTF8String('URL'): dbus.UTF8String('')},
signature=dbus.Signature('ss'))
[DEBUG] syncevo-http: processing outgoing message of type
application/vnd.syncml+wbxml and length 2006, binary data
[DEBUG] twisted: 192.168.142.85 - - [16/Jul/2013:00:05:18 +0000] "POST
/sync?sessionid=5130385871373932780 HTTP/1.1" 200 2006 "-" "Nokia
SyncML HTTP
Client"
[DEBUG] syncevo-http: done with request in session 5130385871373932780, error
None
syncevolution-log.html does show this:
17722 processing time=318813 msec, incoming bytes=65276, outgoing bytes=2006
17723 [2013-07-16 00:05:19.090] D-Bus transport: outgoing message 2006
bytes,
17724 application/vnd.syncml+wbxml,
17725 [2013-07-16 00:05:19.178] D-Bus transport: wait - old state: WAITING,
17726 [2013-07-16 00:10:19.557] D-Bus transport: got error 'timed out after
300s',
17727 current error is '', state WAITING
17728 [2013-07-16 00:10:19.589] D-Bus transport: wait - new state: FAILED,
timed out
17729 after 300s
17730 [2013-07-16 00:10:19.645] TransportException thrown at
src/dbus/server/dbus-
17731 transport-agent.cpp:169
17732 [2013-07-16 00:10:19.657] transport problem: send() on connection
which is not
17733 ready
17734 [2013-07-16 00:10:19.677] aborting after catching fatal error
17735 +
17736 –
what timeout is this that kicks in after 300s?
Christof
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
11:53 p.m.
On Tue, 2013-07-16 at 02:16 +0200, Christof Schulze wrote:
Am Sonntag, 14. Juli 2013, 21:15:08 schrieb Patrick Ohly:
this is the full server log with the server having the debug flag set:
[DEBUG] syncevo-http: POST from 192.168.142.85 config type
application/vnd.syncml+wbxml session None args {} length 299
[...]
[INFO] syncevo-dbus-server: /org/syncevolution/Server: matched
deviceID
IMEI:XXXXXXXXXXXXXXXXXXXX against config christofphon
(/home/christof/.config/syncevolution/default/peers/christofphon)
[...]
The syncevo-http-server only passes through messages, you also need to
increase the loglevel in
the /home/christof/.config/syncevolution/default/peers/christofphon/config.ini
syncevolution-log.html does show this:
17722 processing time=318813 msec, incoming bytes=65276, outgoing bytes=2006
17723 [2013-07-16 00:05:19.090] D-Bus transport: outgoing message 2006
bytes,
17724 application/vnd.syncml+wbxml,
17725 [2013-07-16 00:05:19.178] D-Bus transport: wait - old state: WAITING,
17726 [2013-07-16 00:10:19.557] D-Bus transport: got error 'timed out after
300s',
17727 current error is '', state WAITING
With a higher loglevel, there should be a trace of the HTTP requests
during that time period.
what timeout is this that kicks in after 300s?
It's the RetryDuration of the christofphon/config.ini above.
But I am not sure whether increasing that will help. Does it really take
more than 5 minutes to execute the REPORT that you showed in your
previous email?
--
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.
1:14 p.m.
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
2745
days inactive
2904
days old
syncevolution@synevolution.org
17 comments
3 participants
participants (3)
-
Christof Schulze -
Lukas Zeller -
Patrick Ohly