SyncML-plugin: support "late" Slow-Sync request within the get_changes()-function

[henrik]

opensync 0.38 libsyncml 0.5.0

Calling osync_objtype_sink_set_slowsync(sink, TRUE) then osync_engine_synchronize_and_block for libopensync-plugin-syncm does *NOT* trigger a slow sync

/Henrik

[henrik]

Also, if a sync fails, and the sync engine detects this and emits an OSYNC_ENGINE_EVENT_PREV_UNCLEAN in engine_status_callback the behaviour is the same: libsyncml does *NOT* initiate a slow sync.

[dgollub]

This issue is only in regard to the SyncML plugin right? What about other plugins? Do they trigger a real slow-sync? Or do you thing this is an Engine issue?

[henrik]

Hi, bellmich kindly provided some pathces to libsyncml ​http://libsyncml.opensync.org/ticket/202 According to this, bellmich find that this is an OpenSync? issue rather than a libsyncml issue. (This could of course be either a genuine OpenSync? issue, or just stupid me using the API in the wrong way)

I have now tried again with the latest trunks out of SVN (OpenSync? 4250, libsyncml 803). Now the error I get is:

Synchronization error:
Main sink of member 2 of type syncml-obex-client had an error:
ROOT CAUSE:
Command failed.
The recipient encountered an unexpected condition which prevented it from fulfilling the request.
The remote peer requested a SLOW-SYNC but the local OpenSync instance enforces a normal synchronization.

Basically what I do is this (mozilla-sync vs. syncml plugins):

1. Initially the phone is *not* synchronized.
2. I sync Thunderbid with phone. Both agree that this must be a slow sync, which works just fine.
3. Then I sync a different Thunderbird addressbook with phone. So now the phone thinks we are in sync (it obviously cannot know better), but Thunderbird thinks (correctly) that we are not, and signals this to OpenSync?. This is where I get the above error.

In the mozilla-sync plugin in mozilla_sync_connect i simply do osync_objtype_sink_set_slowsync(db->pOSyncObjTypeSink, TRUE); where db->pOSyncObjTypeSink is the sink I got in mozilla_sync_initialize from osync_plugin_info_find_objtype.

Since this worked quite some time ago (SVN somewhere around 0.35 or 0.36) and I did not change the mozilla-sync code in the meantime, I believe this is probably either a genuine OpenSync? problem, or some API update that I was too slow to catch...

I will try to continue to look into this, but as you guys are developing and bug-fixing faster than the speed of light, slow me is having a hard time keeping up!

/Henrik

[henrik]

It seems that this issue manifests itself also with file-sync to file-sync

I have reproduced the problem as follows:

1. Create two directories V1 and V2, and put some VCARDs in V1
2. With osynctool create a new OpenSync? group with two file-sync members and configure the members for V1 and V2
3. Discover and synchronize using osynctool
4. This correctly results in a slowsync, and all VCARDs are copied from V1 to V2
5. Delete anchor.db and hashtable.db in first group
6. Synchronize using osynctool
7. This results in V2 containing duplicates of every card

As far as I can see, the sync in (6) is something strange which is neither slow, nor fast.

Looking in the traces for V1 we find:

	osync_objtype_sink_set_slowsync: Setting slow-sync of object type "data" to 1

But then immediatly

Dispatching 0x8167cf8:1(OSYNC_MESSAGE_CONNECT)
>>>>>>>  _osync_client_message_handler(0x8167cf8, 0x80f7dd8)
	plugin received command 1 (OSYNC_MESSAGE_CONNECT)
		Searching sink for data
		osync_objtype_sink_set_slowsync: Setting slow-sync of object type "data" to 0

For V2 we find:

Dispatching 0x816d6b0:3(OSYNC_MESSAGE_GET_CHANGES)
	plugin received command 3 (OSYNC_MESSAGE_GET_CHANGES)
	>>>>>>>  _osync_client_handle_get_changes(0x8153620, 0x816d6b0, 0xb2fa3258)
		Searching sink for data (slowsync: 0)
		>>>>>>>  osync_plugin_info_find_objtype(0x815c348, data)
		osync_objtype_sink_set_slowsync: Setting slow-sync of object type "data" to 0

Full traces attached.

/Henrik

[henrik]

Reproduced on file-sync with syncml-obex-client

The above has been reproduced on file-sync with syncml-obex-client Full traces attached.

The traces are for SVN -r4252; but the same behavior is experienced with -r4270

[dgollub]

Replying to henrik: [...]

I have reproduced the problem as follows:

1. Create two directories V1 and V2, and put some VCARDs in V1
2. With osynctool create a new OpenSync? group with two file-sync members and configure the members for V1 and V2
3. Discover and synchronize using osynctool
4. This correctly results in a slowsync, and all VCARDs are copied from V1 to V2
5. Delete anchor.db and hashtable.db in first group

Wow, thats maybe a bit too much and a different bug worth. IIRC, file-sync plugin is designed to cause a slow-sync when the <Path> configuration changes. (Which get stored in the anchor.db). But deleting the hashtable.db is maybe a bit too much ... which might hint a different bug, and a complete different (and maybe untested) error condition.

Could you create a separated ticket to test the error-scenario when hashtable.db gets malformed/deleted?

6. Synchronize using osynctool
7. This results in V2 containing duplicates of every card

[...]

[dgollub]

Created a ticket for deleting hashtable-scenario with ticket #960.

[dgollub]

Confirmed issue.

Slow-Sync per ObjEngine? does NOT get triggered on anchor-mismatch on file-sync plugin (e.g. path got changed).

[dgollub]

The issue is that setting a Slow-Sync inside the plugin init() function get not honored. There are various reason to not support this anyway.

Unfortunately the file-sync plugin is setting slow-sync on anchor mismatch in the init() function, which is a file-sync bug.

All traces in this bug are "invalid" due to the file-sync bug. Not quite sure about the issue combined with mozilla-sync and syncml-obex-client plugin. mozilla-sync is setting slow-sync only inside the connect() function -> valid. syncml-obex-client plugin never sets slow-sync mode (which should be done at least when the phone get replaced - or the configuration changes).

Not quite sure if the initial bug, which is about mozilla-sync and syncml-obex-client still exists.

To avoid confusion, could you try to reproduce the issue _without_ the file-sync plugin involved. (Or at least with a fixed version of file-sync, as soon this is available).

[henrik]

To avoid confusion, could you try to reproduce the issue _without_ the file-sync plugin involved. (Or at least with a fixed version of file-sync, as soon this is available).

The initial bug report was not regarding file-sync. The only reason for including file-sync was to kind-of-make-sure that this was not a mozilla-sync-only issue.

This is not just a file-sync issue; since mozilla-sync vs syncml-obex-client has problems as well,

I would suggest that you make whatever changes are necesary to engine and file-sync, and then I shall be more than happy to test all the cases again!

[dgollub]

This is just a syncml-obex-client issue. (file-sync plugin got fixed in meanwhile)

All plugins have to support that the Slow-Sync got requested for the first-time with the get_changes().

This is not supported by the SyncML plugin yet.

The current implementation of the SyncML plugin can only request a Slow-Sync in the connect()-phase. Once the connect() phase is done, the current implementation of SyncML plugin keeps going with the "FastSync?" even if the engine requested with the get_changes()-phase to switch to a Slow-Sync.

Since some protocols/plugins can determine Slow-Sync connection only during the connect()-phase, the last chance for the Engine is to request a Slow-Sync with the get_changes()-call.

See also ​http://libsyncml.opensync.org/ticket/202

[henrik]

Just for the record: With OpenSync? -r4391 and libsyncml -r821 the problem is still there...

[dgollub]

connect_done()-sink function got implemented in OpenSync with r4422

[henrik]

See also ticket 997

[dgollub]

SyncML plugin support of "late"-Slow-Sync got implemented with r4438.

[sim]

​decoration Changed 1 year ago by admin

​bathtub Changed 1 year ago by admin

​solar system Changed 1 year ago by admin

​stair parts Changed 1 year ago by admin

​solar supply Changed 1 year ago by admin