On Fri, 2010-02-26 at 15:05 +0000, Patrick Ohly wrote:
> Hello!
> 
> Another test failure. This time, the SyncEvolution test suite simulates
> the following situation:
>       * Client has one added item.
>       * Two-way sync gets as far as the client sending the <Add> for
>         that item.
>       * Server processes that message, adding the item, and sends back a
>         reply.
>       * Transport "fails" and reply is lost, resending also doesn't
>         work, so client suspends.
>       * So does the server, after a timeout.
>       * Next session resumes.
>       * Client sends that item again (because it cannot know whether the
>         server has it).
>       * Server adds the item *again*, leading to a duplicate.
> 
> Note that the client is no longer using <Replace>, as in older versions.
> Instead it uses <Add>. I think the expectation is that the server
> recognizes that it already has the item based on the client's item ID,
> but that doesn't seem to work.

I also have a test where the <Add> gets interrupted in the middle of
transfering a big item (<MoreData/>). When resuming, the client only
sends the second half and the server fails to parse that:

Add>
<CmdID>5</CmdID>
<Meta>
<Type>text/vcard</Type>
</Meta>
<Item>
<Source>
<LocURI>979</LocURI>
</Source>
<Meta>
<EMI>datapos=19304</EMI>
</Meta>
<Data>
xxxxxxxxx
\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Again, I don't see anything in the server log that indicates that the
server is trying to retrieve the first half first.

Not that this would have worked with SyncEvolution ;-) It doesn't
implement blob support yet, and that would be necessary in this case,
wouldn't it?

The point of the test is to trigger a failure, then implement the
necessary support.

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



_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to