[SyncEvolution] Help needed

[Patrick Ohly]

On Mon, 2016-02-29 at 20:51 +0100, deloptes wrote:
> Thank you once again,
> 
> Patrick Ohly wrote:
> > Watch out for a method-call to "StoreSyncReport". It should appear
> > twice: once when getting send by the child, once when received by the
> > parent. For that message, a corresponding method-return message should
> > be sent by parent to child, again being logged twice.
> 
> This is there once (but better have a look yourself, please). I attach gz.
> There is also 'method-return' and there it stops

So based on the glib-dbus dumps, the messages pass back and forth fine.
What remains unclear is why the child process does not seem to process
the response message once it got received.

It is also strange that there seems to be debug output missing from the
child process. There's no "child sending sync report" output at all. I
thought there should be, but I'll have to check that in more detail.

> >     /**
> >      * optional: write all changes, throw error if that fails
> >      *
> >      * This is called while the sync is still active whereas
> >      * close() is called afterwards. Reporting problems
> >      * as early as possible may be useful at some point,
> >      * but currently doesn't make a relevant difference.
> >      */
> >     virtual void flush() {}
> >     
> >     /**
> >      * closes the data source so that it can be reopened
> >      *
> >      * Just as open() it should not affect the state of
> >      * the database unless some previous action requires
> >      * it.
> >      */
> >     virtual void close() = 0;
> > 
> 
> I have seen the flush function, however the tde/kde3 logic is such that it
> would cleanup the pointers when ticket gets saved and in my opinion the
> best is to do it in close() as opposed to open(). If all works fine it
> would be sufficient, but thank you for the advise anyway.
> 
> I also added some from the html log at the end of the file with
> corresponding source.
> Both sides say:
> "Never received status for command 'SyncHdr', (outgoing MsgID=4, CmdID=0)"
> "Never received status for command 'SyncHdr', (outgoing MsgID=3, CmdID=0)"
> 
> Is this OK? It leads to  TSyncSession::InternalResetSessionEx
> 
> // reset session to inital state (new)
> ......

In some cases it is, but I am not sure without further analysis.

-- 
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.