6:27 a.m.
Hi,
I recently get an error when trying to sync the calendar with a remote
syncevolution (1.2.1, now 1.2.2).
This is the error on the command line:
[INFO] calendar: received 129/129
[INFO] SoupTransport Failure:
https://<host>:9000/syncevolution?sessionid=17629852271328728162
via libsoup: lost connection to SyncEvolution
...
First ERROR encountered: error code from Synthesis engine bad usage
(local, status 20015)
Data modified locally during synchronization:
*** calendar ***
no changes
The HTML log contains a lot of there errors:
RemoteID=1142 [--][++] [->end] [->enclosing]
[2012-02-08 20:10:18.702] add item operation received
[2012-02-08 20:10:18.702] startDataWrite called, status=0
[2012-02-08 20:10:18.702] TStdLogicDS::logicProcessRemoteItem
starting, SyncOp=add, RemoteID='1142', LocalID=''
[2012-02-08 20:10:18.702] Executing Script 'beforewritescript'
[2012-02-08 20:10:18.702] adding "XXX"
[2012-02-08 20:10:18.710] InsertItemAsKey res=409
[2012-02-08 20:10:18.710] cannot create record in database
(sta=409)
[2012-02-08 20:10:18.710] Database Error --> SyncML status 409
[2012-02-08 20:10:18.710] - Operation add failed with SyncML
status=409
–[2012-02-08 20:10:18.710] End of 'Process_Item' [->top] [->enclosing]
This is the content of the remote calendar entry, copied from the
syncevolution file storage (and sensible data removed):
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.24//EN
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:19671029T020000
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870322T030000
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=4SU
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20110426T192234Z
DTSTAMP:20110426T195834Z
CREATED:20110426T192234Z
UID:20110426T192222Z-2698-1001-1-266@mac
SEQUENCE:2
CLASS:PUBLIC
TRANSP:OPAQUE
SUMMARY:XXX
DESCRIPTION:XXX
DTSTART;TZID=Europe/Berlin:20110510T070000
DTEND;TZID=Europe/Berlin:20110510T080000
END:VEVENT
END:VCALENDAR
Any hints what is wrong here?
Regards,
Tino
6:51 a.m.
New subject: [SyncEvolution] SoupTransport Failure during calendar sync with remote syncevolution - 409 status
On Wed, 2012-02-08 at 20:27 +0100, Tino Keitel wrote:
Hi,
I recently get an error when trying to sync the calendar with a remote
syncevolution (1.2.1, now 1.2.2).
This is the error on the command line:
[...]
The HTML log contains a lot of there errors:
RemoteID=1142 [--][++] [->end] [->enclosing]
[2012-02-08 20:10:18.702] add item operation received
[2012-02-08 20:10:18.702] startDataWrite called, status=0
[2012-02-08 20:10:18.702] TStdLogicDS::logicProcessRemoteItem
starting, SyncOp=add, RemoteID='1142', LocalID=''
[2012-02-08 20:10:18.702] Executing Script 'beforewritescript'
[2012-02-08 20:10:18.702] adding "XXX"
[2012-02-08 20:10:18.710] InsertItemAsKey res=409
[2012-02-08 20:10:18.710] cannot create record in database
(sta=409)
[2012-02-08 20:10:18.710] Database Error --> SyncML status 409
[2012-02-08 20:10:18.710] - Operation add failed with SyncML
status=409
–[2012-02-08 20:10:18.710] End of 'Process_Item' [->top] [->enclosing]
Is that from the local side? You are using Evolution there, right? Is
the server side using the file backend?
In such a combination it is possible that the server ends up storing two
independent items with the same UID, because the file backend is
oblivious of the iCalendar 2.0 UID/RECURRENCE-ID semantic. When that
happens, the server asks the client to store an item that the client
already has, which the client can detect based on the UID/RECURRENCE-ID.
The client then refuses to add that item again with the 409 status to
the engine.
One the server side the engine in SyncEvolution 1.2.2 was able to handle
that, but not on the client side. Support for that was added later, and
I have suggested further refinements to it - see the '409 "item merged"
in client + multiple sync cycles in a single session' mail thread.
I haven't investigated what exactly happens in 1.2.2 when such a problem
occurs. The only workaround that I can recommend in that release is to
avoid the file backend as storage on the server side. That's also better
with later release (less traffic, lower risk of sending duplicates to
clients which do not themselves detect them).
I know that the file backend is attractive for the server side because
of its simplicity, but in this case it is simply a bit too simple.
Patches to teach the file backend enough of iCalendar 2.0 to avoid the
issue would be welcome.
--
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:52 p.m.
New subject: [SyncEvolution] SoupTransport Failure during calendar sync with remote syncevolution - 409 status
On Wed, Feb 08, 2012 at 20:51:41 +0100, Patrick Ohly wrote:
On Wed, 2012-02-08 at 20:27 +0100, Tino Keitel wrote:
> Hi,
>
> I recently get an error when trying to sync the calendar with a remote
> syncevolution (1.2.1, now 1.2.2).
>
> This is the error on the command line:
[...]
> The HTML log contains a lot of there errors:
>
> RemoteID=1142 [--][++] [->end] [->enclosing]
>
> [2012-02-08 20:10:18.702] add item operation received
> [2012-02-08 20:10:18.702] startDataWrite called, status=0
> [2012-02-08 20:10:18.702] TStdLogicDS::logicProcessRemoteItem
> starting, SyncOp=add, RemoteID='1142', LocalID=''
> [2012-02-08 20:10:18.702] Executing Script 'beforewritescript'
> [2012-02-08 20:10:18.702] adding "XXX"
> [2012-02-08 20:10:18.710] InsertItemAsKey res=409
> [2012-02-08 20:10:18.710] cannot create record in database
> (sta=409)
> [2012-02-08 20:10:18.710] Database Error --> SyncML status 409
> [2012-02-08 20:10:18.710] - Operation add failed with SyncML
> status=409
>
> –[2012-02-08 20:10:18.710] End of 'Process_Item' [->top]
[->enclosing]
Is that from the local side? You are using Evolution there, right? Is
the server side using the file backend?
Yes to all three questions.
In such a combination it is possible that the server ends up storing
two
independent items with the same UID, because the file backend is
oblivious of the iCalendar 2.0 UID/RECURRENCE-ID semantic. When that
happens, the server asks the client to store an item that the client
already has, which the client can detect based on the UID/RECURRENCE-ID.
The client then refuses to add that item again with the 409 status to
the engine.
So I can fix this by removing duplicates manually on the server side
file storage, right?
Regards,
Tino
6:36 p.m.
New subject: [SyncEvolution] SoupTransport Failure during calendar sync with remote syncevolution - 409 status
On Thu, 2012-02-09 at 07:52 +0100, tino.keitel+syncevolution(a)tikei.de
wrote:
On Wed, Feb 08, 2012 at 20:51:41 +0100, Patrick Ohly wrote:
> In such a combination it is possible that the server ends up storing two
> independent items with the same UID, because the file backend is
> oblivious of the iCalendar 2.0 UID/RECURRENCE-ID semantic. When that
> happens, the server asks the client to store an item that the client
> already has, which the client can detect based on the UID/RECURRENCE-ID.
> The client then refuses to add that item again with the 409 status to
> the engine.
So I can fix this by removing duplicates manually on the server side
file storage, right?
That, or doing a "refresh-from-client". The data on the client side
should be okay.
--
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.
3874
days inactive
3875
days old
syncevolution@synevolution.org
3 comments
3 participants
participants (3)
-
Patrick Ohly -
Tino Keitel -
tino.keitel+syncevolution＠tikei.de