8:48 p.m.
Hi,
I was working on improving the error reporting in the UI, and got some
questions:
It seems that at least some failing syncs do not generate a report: I
tried setting a wrong password and syncing. When I asked for a report
afterwards, I got the one for the last successful sync. Is this what I
should expect?
The GetReports BNF documentation was very good for writing the parser,
but I'm still a bit confused about some of the fields:
* status
Only value I've seen is 200, and git log tells me this is a successful
sync. Does this otherwise correspond to error in StatusChanged?
* source-X-status
This seems to be '0' all the time. I assume this correponds to error
values in sources hash in StatusChanged signal?
* source-X-mode
This was "two-way" even when I set "none" for this source.
* source-X-resume
?
10:23 p.m.
Jussi Kukkonen wrote:
Hi,
I was working on improving the error reporting in the UI, and got some
questions:
Also, I'm having trouble with the timestamps. I thought I could just
compare the "end" value to seconds from gettimeofday() result but it
doesn't seem to work like that.
Example: the report for a sync that just ended includes "end =
1259784239", gettimeofday() returns 1259789242.
It's entirely possible that it's just too late for me, but I can't make
heads or tails of this: the time differences seem to vary (in the
ballpark of a few thousand seconds).
Jussi
6:37 a.m.
On Wed, 2009-12-02 at 22:23 +0000, Jussi Kukkonen wrote:
Jussi Kukkonen wrote:
> Hi,
>
> I was working on improving the error reporting in the UI, and got some
> questions:
Also, I'm having trouble with the timestamps. I thought I could just
compare the "end" value to seconds from gettimeofday() result but it
doesn't seem to work like that.
It should.
Example: the report for a sync that just ended includes "end =
1259784239", gettimeofday() returns 1259789242.
Without having checked this myself yet: are you sure that you look at
the most recent report?
--
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:13 a.m.
Patrick Ohly wrote:
On Wed, 2009-12-02 at 22:23 +0000, Jussi Kukkonen wrote:
> Also, I'm having trouble with the timestamps. I thought I could just
> compare the "end" value to seconds from gettimeofday() result but it
> doesn't seem to work like that.
It should.
> Example: the report for a sync that just ended includes "end =
> 1259784239", gettimeofday() returns 1259789242.
Without having checked this myself yet: are you sure that you look at
the most recent report?
Well, that was simple in light of day: you are right This also explains
the sync mode not being what I expected, so don't spend the day looking
for a bug.
I expected the order of reports to be from youngest to oldest. I'm
pretty sure I wrote that in the docs originally, but it's not there now.
I still think that order would make sense.
Jussi
7:20 a.m.
On Thu, 2009-12-03 at 07:13 +0000, Jussi Kukkonen wrote:
I expected the order of reports to be from youngest to oldest.
I'm
pretty sure I wrote that in the docs originally, but it's not there now.
I still think that order would make sense.
Yes, definitely. If it is neither in the spec nor the documentation,
then we need to add that. Yongsheng is currently working in this aspect,
see MB #8049.
--
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.
9:24 a.m.
> I expected the order of reports to be from youngest to oldest.
I'm
> pretty sure I wrote that in the docs originally, but it's not there now.
> I still think that order would make sense.
Yes, definitely. If it is neither in the spec nor the documentation,
then we need to add that. Yongsheng is currently working in this aspect,
see MB #8049.
Yes, it's a bug. Currently the order is reversed incorrectly.
I'll fix it soon.
Cheers,
Yongsheng
> -----Original Message-----
> From: syncevolution-bounces(a)syncevolution.org
> [mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
> Sent: Thursday, December 03, 2009 3:20 PM
> To: Jussi Kukkonen
> Cc: SyncEvolution
> Subject: Re: [SyncEvolution] questions about sync reports
>
> On Thu, 2009-12-03 at 07:13 +0000, Jussi Kukkonen wrote:
> I expected the order of reports to be from youngest to oldest.
I'm
> pretty sure I wrote that in the docs originally, but it's not there now.
> I still think that order would make sense.
Yes, definitely. If it is neither in the spec nor the documentation,
then we need to add that. Yongsheng is currently working in this aspect,
see MB #8049.
>
>
> --
> 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
6:36 a.m.
On Wed, 2009-12-02 at 20:48 +0000, Jussi Kukkonen wrote:
It seems that at least some failing syncs do not generate a report: I
tried setting a wrong password and syncing. When I asked for a report
afterwards, I got the one for the last successful sync. Is this what I
should expect?
If the sync session fails early enough, then it doesn't get to the point
where a report is generated. Otherwise every single attempt to run a
sync with an invalid configuration would create a report, eventually
causing "useful" reports and their backups to be expired (maxlogdirs,
MB#7708).
So yes, I think this is expected. I'm not entirely sure which D-Bus call
reports such failures and how, but there should be something.
The GetReports BNF documentation was very good for writing the
parser,
but I'm still a bit confused about some of the fields:
Right, we need to add some more semantic information.
* status
Only value I've seen is 200, and git log tells me this is a successful
sync. Does this otherwise correspond to error in StatusChanged?
Yes, it should.
* source-X-status
This seems to be '0' all the time. I assume this correponds to error
values in sources hash in StatusChanged signal?
Yes.
* source-X-mode
This was "two-way" even when I set "none" for this source.
That needs to be fixed.
* source-X-resume
?
The sync done by that source resumed a suspended sync. There's no way to
determine whether a source was suspended during the last sync, because
the Synthesis engine doesn't provide that information. Could be added, I
suppose.
--
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.
9:19 a.m.
Thanks for the info. Just a reminder, any problems I had could be
related to the fact that I was looking at the wrong reports...
Patrick Ohly wrote:
On Wed, 2009-12-02 at 20:48 +0000, Jussi Kukkonen wrote:
> It seems that at least some failing syncs do not generate a report: I
> tried setting a wrong password and syncing. When I asked for a report
> afterwards, I got the one for the last successful sync. Is this what I
> should expect?
If the sync session fails early enough, then it doesn't get to the point
where a report is generated. Otherwise every single attempt to run a
sync with an invalid configuration would create a report, eventually
causing "useful" reports and their backups to be expired (maxlogdirs,
MB#7708).
So yes, I think this is expected. I'm not entirely sure which D-Bus call
reports such failures and how, but there should be something.
Yes, there needs to be something and that something needs to be
available after the fact, so the UI can tell if automated syncs have
failed for some reason. I was really hoping the reports could be the
single source of info I could use but I do see your point...
Doesn't this same problem appear when you automatically sync e.g. 20
times a day, and there are no changes?
Could this work: syncevolution creates a report for every sync, but
before saving, it compares it to the last saved report. If they appear
to be the same (with certain rules), do not save a new report but update
the old one.
This way we could "compress" a group of syncs that fail in the same
exact way into one report. Likewise a group of syncs that have no
changes in either end.
We'd need a "duplicate-count" key and possibly some new time keys (times
for first and last sync in the series?).
- Jussi
10:12 a.m.
On Thu, 2009-12-03 at 09:19 +0000, Jussi Kukkonen wrote:
Patrick Ohly wrote:
> On Wed, 2009-12-02 at 20:48 +0000, Jussi Kukkonen wrote:
>> It seems that at least some failing syncs do not generate a report: I
>> tried setting a wrong password and syncing. When I asked for a report
>> afterwards, I got the one for the last successful sync. Is this what I
>> should expect?
>
> If the sync session fails early enough, then it doesn't get to the point
> where a report is generated. Otherwise every single attempt to run a
> sync with an invalid configuration would create a report, eventually
> causing "useful" reports and their backups to be expired (maxlogdirs,
> MB#7708).
>
> So yes, I think this is expected. I'm not entirely sure which D-Bus call
> reports such failures and how, but there should be something.
Yes, there needs to be something and that something needs to be
available after the fact, so the UI can tell if automated syncs have
failed for some reason. I was really hoping the reports could be the
single source of info I could use but I do see your point...
And I see your's ;-) It is indeed reasonable to expect a report even for
failed attempts to start a sync. It just hasn't been necessary so far.
Doesn't this same problem appear when you automatically sync e.g.
20
times a day, and there are no changes?
Yes. I consider "more intelligent database dumping" a blocking issue for
automatic sync.
Could this work: syncevolution creates a report for every sync, but
before saving, it compares it to the last saved report. If they appear
to be the same (with certain rules), do not save a new report but update
the old one.
That could work. We can limit this kind of compression to syncs which
fail to start and then use the first "ERROR" line as criteria for "same
problem as last time".
We'd need a "duplicate-count" key and possibly some new
time keys (times
for first and last sync in the series?).
Agreed. I'll have a look at implementing this.
--
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.
4342
days inactive
4343
days old
syncevolution@synevolution.org
8 comments
3 participants
participants (3)
-
Jussi Kukkonen -
Patrick Ohly -
Zhu, Yongsheng