Ticket #901 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: henrik Owned by: bellmich
Priority: high Milestone:
Component: Plugin: syncml Version: 0.38
Severity: blocker Keywords:
Cc: henrik@…, dgollub

Description

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

Attachments

osync_trace.zip (91.9 KB) - added by henrik 5 years ago.
osync_trace_file_syncml.zip (76.7 KB) - added by henrik 5 years ago.

Change History

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by dgollub

  • Component changed from Engine to Plugin: syncml
  • Summary changed from osync_objtype_sink_set_slowsync does not work to [NEEDINFO] osync_objtype_sink_set_slowsync does not work

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?

comment:3 Changed 5 years ago by henrik

  • Summary changed from [NEEDINFO] osync_objtype_sink_set_slowsync does not work to [INFO-PROVIDED] osync_objtype_sink_set_slowsync does not work

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

comment:4 follow-up: ↓ 8 Changed 5 years ago by 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

Changed 5 years ago by henrik

comment:5 Changed 5 years ago by 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

Changed 5 years ago by henrik

comment:6 Changed 5 years ago by henrik

  • Cc henrik@… added

comment:7 Changed 5 years ago by dgollub

  • Priority changed from normal to highest
  • Component changed from Plugin: syncml to Engine
  • Severity changed from normal to blocker
  • Summary changed from [INFO-PROVIDED] osync_objtype_sink_set_slowsync does not work to osync_objtype_sink_set_slowsync does not work

comment:8 in reply to: ↑ 4 Changed 5 years ago by 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?

  1. Synchronize using osynctool
  2. This results in V2 containing duplicates of every card

[...]

comment:9 Changed 5 years ago by dgollub

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

comment:10 Changed 5 years ago by dgollub

Confirmed issue.

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

comment:11 Changed 5 years ago by dgollub

  • Priority changed from highest to high
  • Status changed from new to assigned
  • Summary changed from osync_objtype_sink_set_slowsync does not work to [NEEDINFO] osync_objtype_sink_set_slowsync does not work

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

comment:12 Changed 5 years ago by 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!

comment:13 Changed 5 years ago by henrik

  • Summary changed from [NEEDINFO] osync_objtype_sink_set_slowsync does not work to osync_objtype_sink_set_slowsync does not work

comment:14 Changed 5 years ago by dgollub

  • Cc dgollub added
  • Owner changed from dgollub to bellmich
  • Status changed from assigned to new
  • Component changed from Engine to Plugin: syncml
  • Summary changed from osync_objtype_sink_set_slowsync does not work to SyncML-plugin: support "late" Slow-Sync request within the get_changes()-function

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

comment:15 Changed 5 years ago by henrik

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

comment:16 Changed 5 years ago by dgollub

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

comment:17 Changed 5 years ago by henrik

See also ticket 997

comment:18 Changed 5 years ago by dgollub

  • Status changed from new to closed
  • Resolution set to fixed

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

comment:19 Changed 5 years ago by dgollub

  • Milestone OpenSync 0.39 deleted

comment:20 Changed 4 years ago by 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

Note: See TracTickets for help on using tickets.