5:49 a.m.
Hello!
I'm looking at issue 7755, "[ERROR] calendar: calendar: extracting
event / sync successful?!".
I turned out that when local operations fail, this was counted by the
Synthesis engine, but not per ADD/UPDATE/REMOVE. Therefore the
"rejected" column in the following output was always zero:
+---------------|-------ON CLIENT-------|-------ON SERVER-------|-CON-+
| | rejected / total | rejected / total | FLI |
| Source | NEW | MOD | DEL | NEW | MOD | DEL | CTS |
+---------------+-------+-------+-------+-------+-------+-------+-----+
| vcard30 | 1/17 | 0/0 | 0/16 | 0/0 | 0/0 | 0/0 | 0 |
| refresh-from-server, 0 KB sent by client, 14 KB received |
| item(s) in database backup: 16 before sync, 16 after it |
+---------------+-------+-------+-------+-------+-------+-------+-----+
| start Thu Jan 14 19:35:54 2010, duration 0:04min |
| synchronization completed successfully |
+---------------+-------+-------+-------+-------+-------+-------+-----+
In this particular example I already enhanced libsynthesis so that the
failed ADD is recorded separately. For remote items I'm less sure
whether counting per operation is possible. Those cases that I have
found in the code which increment the global fRemoteItemsError counter
don't seem to have good access to the failed operation. I'm not even
sure whether the counter is accurate.
Now, my question is this: should we keep printing "synchronization
completed successfully" in such a case? It means the overall status for
the session was okay, because it completed.
That doesn't sounds right to me. I suggest that when we detect
problematic items, we record for the affected source and for the whole
session a new "STATUS_PARTIAL_SUCCESS = 22001" status, similar to
"STATUS_UNEXPECTED_SLOW_SYNC = 22000".
The return code from syncevolution should indicate a failure. If we have
automatic sync enabled, it should stop to let the user deal with the
problem before it gets worse.
How does that sound?
--
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.
7:31 a.m.
May be consider changing "Synchronization Completed Successfully" to "Sync
session completed successfully" to indicate that we are talking about session not the
content.
And if we know for sure that the local changes have problems, return error codes so that,
"Synchronization partially successful" then users will look at the rejected
items and deal with the problematic items.
-Raji
-----Original Message-----
From: syncevolution-bounces(a)syncevolution.org
[mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
Sent: Thursday, January 14, 2010 10:49 AM
To: SyncEvolution
Subject: [SyncEvolution] partially successful syncs (MB #7755)
Hello!
I'm looking at issue 7755, "[ERROR] calendar: calendar: extracting
event / sync successful?!".
I turned out that when local operations fail, this was counted by the
Synthesis engine, but not per ADD/UPDATE/REMOVE. Therefore the
"rejected" column in the following output was always zero:
+---------------|-------ON CLIENT-------|-------ON SERVER-------|-CON-+
| | rejected / total | rejected / total | FLI |
| Source | NEW | MOD | DEL | NEW | MOD | DEL | CTS |
+---------------+-------+-------+-------+-------+-------+-------+-----+
| vcard30 | 1/17 | 0/0 | 0/16 | 0/0 | 0/0 | 0/0 | 0 |
| refresh-from-server, 0 KB sent by client, 14 KB received |
| item(s) in database backup: 16 before sync, 16 after it |
+---------------+-------+-------+-------+-------+-------+-------+-----+
| start Thu Jan 14 19:35:54 2010, duration 0:04min |
| synchronization completed successfully |
+---------------+-------+-------+-------+-------+-------+-------+-----+
In this particular example I already enhanced libsynthesis so that the
failed ADD is recorded separately. For remote items I'm less sure
whether counting per operation is possible. Those cases that I have
found in the code which increment the global fRemoteItemsError counter
don't seem to have good access to the failed operation. I'm not even
sure whether the counter is accurate.
Now, my question is this: should we keep printing "synchronization
completed successfully" in such a case? It means the overall status for
the session was okay, because it completed.
That doesn't sounds right to me. I suggest that when we detect
problematic items, we record for the affected source and for the whole
session a new "STATUS_PARTIAL_SUCCESS = 22001" status, similar to
"STATUS_UNEXPECTED_SLOW_SYNC = 22000".
The return code from syncevolution should indicate a failure. If we have
automatic sync enabled, it should stop to let the user deal with the
problem before it gets worse.
How does that sound?
--
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
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
2:05 a.m.
Hello Frederik,
beware, potential Genesis incompatibility in SyncEvolution 1.0... keep
reading.
On Thu, 2010-01-14 at 20:31 +0000, Bommaraju, Rajyalakshmi wrote:
May be consider changing "Synchronization Completed
Successfully" to
"Sync session completed successfully" to indicate that we are talking
about session not the content.
To me, a session which does not synchronize all content wasn't
successful.
And if we know for sure that the local changes have problems, return
error codes so that, "Synchronization partially successful" then users
will look at the rejected items and deal with the problematic items.
This is what I have implemented. In contrast to what I said earlier, I
didn't update libsynthesis to provide more detailed statistics. It would
be possible for local errors, but for remote errors it looked a bit more
difficult to attribute the error to an add/update/delete.
In addition, when I tested it, I found that a source error on the SyncML
server for one item showed up as a failed overall sync anyway.
So what I have done instead is to correctly display the information that
we get from the engine. The "rejected/total" ratio is gone (because we
don't have the "rejected" part) and a "ERR" column was added. I
struggled a bit to make it more obvious that a failed "add" will
contribute to both the "ADD" column and the "ERR" column, but
haven't
found a good solution.
Furthermore, once the ERR is non-zero for a source which otherwise is
okay, a 22001 "partial failure" status will be recorded.
Here's what this looks like in the command line output:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 32 | 0 | 32 | 2 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-server, 0 KB sent by client, 33 KB received |
| item(s) in database backup: 32 before sync, 30 after it |
| some changes could not be transferred (local, status 22001) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 13 | 0 | 13 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-server, 0 KB sent by client, 7 KB received |
| item(s) in database backup: 13 before sync, 13 after it |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Fri Jan 15 15:54:18 2010, duration 0:09min |
| some changes could not be transferred (local, status 22001) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
This is a change in the output of the command line tool, so Genesis
might have to be updated - or rewritten to use the D-Bus API ;-}
--
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.
3:58 a.m.
Am Freitag, den 15.01.2010, 16:05 +0100 schrieb Patrick Ohly:
Hello Frederik,
beware, potential Genesis incompatibility in SyncEvolution 1.0... keep
reading.
[…]
This is a change in the output of the command line tool, so Genesis
might have to be updated - or rewritten to use the D-Bus API ;-}
Thanks for pointing this out.
I’m not sure D-Bus support will make it in Genesis 0.5, but I hope to
implement it for 0.6.
Cheers,
Frederik
4629
days inactive
4630
days old
syncevolution@synevolution.org
3 comments
3 participants
participants (3)
-
Bommaraju, Rajyalakshmi -
Frederik Elwert -
Patrick Ohly