Improvment of converter path detection

[Christopher Stender-2]

Hi everyone,

I synchronized a vcard21 from irmc-sync to file-sync and noticed some
unnecessary conversions to vcard30 (both plugins use contact/vard21). I
found out that the algorithm which calculate the shortest path is not
very optimized. I added a additional break condition which reduced
these unnecessary searches because it stops as soon as the target
format is reached.

Statistics for one vcard file which was synchronized from irmc-sync
(contact/vcard21) to file-sync (contact/vcard21):

Without patch:
44 searches to find the conversion path (_get_next_vertice_neighbour)
2 conversions from xmlformat-contact to vcard (one time to vcard21 and
one time to vcard30)

With patch:
31 searches to find the conversion path (_get_next_vertice_neighbour)
1 conversion from xmlformat-contact to vcard (this is the best case!)

It would be nice if someone could review the attached patch.

Best regards
Christopher
--
Christopher Stender, R&D Team Mobile Devices
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

[libopensync1_improved_path_search.diff]

---

Index: opensync/format/opensync_format_env.c
===================================================================
--- opensync/format/opensync_format_env.c (Revision 3196)
+++ opensync/format/opensync_format_env.c (Arbeitskopie)
@@ -454,13 +454,25 @@
  while ((neighbour = _get_next_vertice_neighbour(env, tree, current, error))) {
  /* We found a neighbour and insert it sorted in our search queue */
  osync_trace(TRACE_INTERNAL, "%s's neighbour : %s", osync_objformat_get_name(current->format), osync_objformat_get_name(neighbour->format));
- tree->search = g_list_insert_sorted(tree->search, neighbour, _compare_vertice_distance);
+
+ /* Optimization: check if we got a target format and skip further searches */
+ if (target_fn(fndata, neighbour->format)) {
+ osync_trace(TRACE_INTERNAL, "Target format found: %s", osync_objformat_get_name(neighbour->format));
+ result = neighbour;
+ break;
+ } else {
+ tree->search = g_list_insert_sorted(tree->search, neighbour, _compare_vertice_distance);
+ }
  }
  if (osync_error_is_set(error))
  goto error_free_tree;
 
  /* Done, drop the reference to the vertice */
  _free_vertice(current);
+
+ /* If result != NULL we reached a target format */
+ if (result)
+ break;
  }
 
  if (!result) {

---

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Christopher Stender-2]

On Thursday 28 February 2008 22:31, Christopher Stender wrote:

> Hi everyone,
>
> I synchronized a vcard21 from irmc-sync to file-sync and noticed some
> unnecessary conversions to vcard30 (both plugins use contact/vard21).
> I found out that the algorithm which calculate the shortest path is
> not very optimized. I added a additional break condition which
> reduced these unnecessary searches because it stops as soon as the
> target format is reached.
>
> Statistics for one vcard file which was synchronized from irmc-sync
> (contact/vcard21) to file-sync (contact/vcard21):
>
> Without patch:
> 44 searches to find the conversion path (_get_next_vertice_neighbour)
> 2 conversions from xmlformat-contact to vcard (one time to vcard21
> and one time to vcard30)
>
> With patch:
> 31 searches to find the conversion path (_get_next_vertice_neighbour)
> 1 conversion from xmlformat-contact to vcard (this is the best case!)
>
> It would be nice if someone could review the attached patch.

The optimization patch might be wrong since there could be a better path
which we should take to convert a change.

Example:
The next neighbour is our target format but has losses. With the last
patch we would take this way without checking if there are other pathes
without losses. I'm not sure how often this will happen (or if this
will ever happen).

Maybe somebody has a better idea how we can improve the path search and
stop unnecessary conversions.

Best regards,
Christopher
--
Christopher Stender, R&D Team Mobile Devices
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Christopher Stender-2]

On Friday 29 February 2008 11:55, Christopher Stender wrote:

> The optimization patch might be wrong since there could be a better
> path which we should take to convert a change.
>
> Example:
> The next neighbour is our target format but has losses. With the last
> patch we would take this way without checking if there are other
> pathes without losses. I'm not sure how often this will happen (or if
> this will ever happen).
>
> Maybe somebody has a better idea how we can improve the path search
> and stop unnecessary conversions.

Attached you can find a new patch which doesn't influence the path
search. All neighbours will be found (breadth first search).

To prevent unnecessary conversions we save a possible target and check
if it's equal to the current one regarding losses, objtype_changes and
conversions. If it's worse, we search for a better one. If not, we can
stop further searches.


Best regards
Christopher
--
Christopher Stender, R&D Team Mobile Devices
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

[libopensync1_improved_path_search2.diff]

---

Index: opensync/format/opensync_format_env.c
===================================================================
--- opensync/format/opensync_format_env.c (Revision 3196)
+++ opensync/format/opensync_format_env.c (Arbeitskopie)
@@ -429,11 +429,25 @@
  osync_trace(TRACE_INTERNAL, "Next vertice : %s.", osync_objformat_get_name(current->format));
  /* Check if we have reached a target format */
  if (target_fn(fndata, current->format)) {
+ osync_trace(TRACE_INTERNAL, "Target %s found", osync_objformat_get_name(current->format));
  /* Done. return the result */
  result = current;
  break;
  }
 
+ /* Optimitazion:
+ * Check if saved result is equal to current regarding losses, objtype_changes
+ * and conversions. If yes, we can skip further searches and break here */
+ if (result) {
+ if (result->losses <= current->losses && result->objtype_changes <= current->objtype_changes && result->conversions <= current->conversions) {
+ osync_trace(TRACE_INTERNAL, "Target %s found in queue", osync_objformat_get_name(result->format));
+ tree->search = g_list_remove(tree->search, result);
+ break;
+ } else {
+ result = NULL;
+ }
+ }
+
  /* If we dont have reached a target, we look at our neighbours */
  osync_trace(TRACE_INTERNAL, "Looking at %s's neighbours.", osync_objformat_get_name(current->format));
         current->data = osync_data_clone(sourcedata, error);
@@ -455,6 +469,12 @@
  /* We found a neighbour and insert it sorted in our search queue */
  osync_trace(TRACE_INTERNAL, "%s's neighbour : %s", osync_objformat_get_name(current->format), osync_objformat_get_name(neighbour->format));
  tree->search = g_list_insert_sorted(tree->search, neighbour, _compare_vertice_distance);
+
+ /* Optimization:
+ * We found a possible target. Save it. */
+ if (target_fn(fndata, neighbour->format)) {
+ result = neighbour;
+ }
  }
  if (osync_error_is_set(error))
  goto error_free_tree;

---

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Friday 29 February 2008 13:41:24 Christopher Stender wrote:

> > Example:
> > The next neighbour is our target format but has losses. With the last
> > patch we would take this way without checking if there are other
> > pathes without losses. I'm not sure how often this will happen (or if
> > this will ever happen).
> >
> > Maybe somebody has a better idea how we can improve the path search
> > and stop unnecessary conversions.
>
> Attached you can find a new patch which doesn't influence the path
> search. All neighbours will be found (breadth first search).
>
> To prevent unnecessary conversions we save a possible target and check
> if it's equal to the current one regarding losses, objtype_changes and
> conversions. If it's worse, we search for a better one. If not, we can
> stop further searches.

Tried your patch - It didn't break any of our tests. Could you write for this
a regression check/test and commit your patch?

Unittest "conv" already does some conversion path validation. This would be
the right place to add such test:
tests/format-tests/check_conv.c

Let me know if you need help in writting such test. I hope the other tests
from "conv" unittest give some good reference to start writting such test.
Just invent some new mockformat which reflect the same issue as
vcard21-vcard30 does. To make this test independent of the vformat plugin.

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Christopher Stender-2]

On Sunday 02 March 2008 21:28, Daniel Gollub wrote:
> Tried your patch - It didn't break any of our tests. Could you write
> for this a regression check/test and commit your patch?
>
> Unittest "conv" already does some conversion path validation. This
> would be the right place to add such test:
> tests/format-tests/check_conv.c

All these checks cover the code of my patch.

> Let me know if you need help in writting such test. I hope the other
> tests from "conv" unittest give some good reference to start writting
> such test. Just invent some new mockformat which reflect the same
> issue as vcard21-vcard30 does. To make this test independent of the
> vformat plugin.

Patch submitted. Thanks. :)

Best regards
Christopher
--
Christopher Stender, R&D Team Mobile Devices
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

Hi,

I am developing a new plugin for OpenSync:
http://kaarposoft.dk/bluezync/

When doing a slow sync, the GUI presents the user with a list of all
conflicts.
For each conflict, the user can select what to do, and the plugin calls
one of:
osync_engine_mapping_solve, osync_engine_mapping_duplicate,
osync_engine_mapping_ignore_conflict, or osync_engine_mapping_use_latest
as appropriate.

However, presented with a large amount of conflicts, the user may also
select "CANCEL ALL".
This means, that the user wants to cancel the synchronization altogether.
How do I communicate this fact to OpenSync ??

I cannot just ignore each conflict in turn, because that would update
the non-conflicting entries, and set the anchor for fast-sync next time.

Thanks in advance for any help!
/Henrik


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Monday 03 March 2008 21:39:55 Henrik /KaarPoSoft wrote:
> However, presented with a large amount of conflicts, the user may also
> select "CANCEL ALL".
> This means, that the user wants to cancel the synchronization altogether.
> How do I communicate this fact to OpenSync ??
>
> I cannot just ignore each conflict in turn, because that would update
> the non-conflicting entries, and set the anchor for fast-sync next time.

osync_engine_abort() should do the job I guess.
But it didn't get yet implemented - could you create a ticket for that and
assign it to me and the OpenSync component?

Thanks!

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

> On Monday 03 March 2008 21:39:55 Henrik /KaarPoSoft wrote:
>  
>> However, presented with a large amount of conflicts, the user may also
>> select "CANCEL ALL".
>> This means, that the user wants to cancel the synchronization altogether.
>> How do I communicate this fact to OpenSync ??
>>
>> I cannot just ignore each conflict in turn, because that would update
>> the non-conflicting entries, and set the anchor for fast-sync next time.
>>    
>
> osync_engine_abort() should do the job I guess.
> But it didn't get yet implemented - could you create a ticket for that and
> assign it to me and the OpenSync component?
>
> Thanks!
>
> best regards,
> Daniel
>  

Ticket #700 created!
Thanks for your help...
/Henrik

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Monday 03 March 2008 22:32:39 Henrik /KaarPoSoft wrote:

> n it to me and the OpenSync component?
>
> > Thanks!
> >
> > best regards,
> > Daniel
> >  
>
> Ticket #700 created!
> Thanks for your help...

Initial implementation is ready. It's not a perfect abort implementation since
it's NOT able to preempt/abort already running commands on the plugin side.
I marked this as TODO. But this should work within a conflict handling
function. At least my testcase is using the abort function this way.

For more details:
http://opensync.org/changeset/3212

Please, let me know if this works for you.

best regars,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Gustavo De Nardin (spuk)]

* Daniel Gollub <dgollub@...> [2008-03-09 22:20 +0100]:

> On Monday 03 March 2008 22:32:39 Henrik /KaarPoSoft wrote:
> > Ticket #700 created!
> > Thanks for your help...
>
> Initial implementation is ready. It's not a perfect abort implementation since
> it's NOT able to preempt/abort already running commands on the plugin side.
> I marked this as TODO. But this should work within a conflict handling
> function. At least my testcase is using the abort function this way.
>
> For more details:
> http://opensync.org/changeset/3212

Could also use _osync_queue_flush_messages() to flush the queue, no?

But will just flushing the GAsyncQueue be enough? Since _queue_dispatch()
should be pushing the messages to the fifo ASAP...

IIRC the signal way was the easy one. Either that or make another
queue/threads/fifo for "control messages", to send the abort through it,
which looked like too much work, just for abort.

cya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

Hi Daniel,

Thank you very much for your help!

The good news is, that OpenSync tries to abort, so I get:
    The sync failed: Synchronization got aborted by user!
which is exactly what I wanted!

However, just after that I get
    libsyncml/sml_session.c:1613:E:smlSessionEnd: Assertion "session" failed
so the whole thing crashes!!!

Is this something to be corrected in libsyncml, or am I doing something
wrong here?

/Henrik


Daniel Gollub wrote:

> On Monday 03 March 2008 22:32:39 Henrik /KaarPoSoft wrote:
>  
>> n it to me and the OpenSync component?
>>
>>    
>>> Thanks!
>>>
>>> best regards,
>>> Daniel
>>>  
>>>      
>> Ticket #700 created!
>> Thanks for your help...
>>    
>
> Initial implementation is ready. It's not a perfect abort implementation since
> it's NOT able to preempt/abort already running commands on the plugin side.
> I marked this as TODO. But this should work within a conflict handling
> function. At least my testcase is using the abort function this way.
>
> For more details:
> http://opensync.org/changeset/3212
>
> Please, let me know if this works for you.
>
> best regars,
> Daniel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Opensync-devel mailing list
> Opensync-devel@...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
>  

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Monday 10 March 2008 23:16:00 Henrik /KaarPoSoft wrote:
> However, just after that I get
>     libsyncml/sml_session.c:1613:E:smlSessionEnd: Assertion "session"
> failed so the whole thing crashes!!!
>
> Is this something to be corrected in libsyncml, or am I doing something
> wrong here?

Not quite sure. Maybe the SyncML Plugin isn't prepared for the case that right
in the middle of the sync disconnect gets called - which was until now
unexpected. SyncML Plugin got quite complex - I have to try to reproduce
this. Backtrace with line numbers would be very helpful, since reproducing
the issue might take some time until i find some time ;(

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Sunday 09 March 2008 23:38:30 Gustavo De Nardin (spuk) wrote:
> Could also use _osync_queue_flush_messages() to flush the queue, no?

This would require some refactoring, so the command queue of  OSyncEngine is
using OSyncQueue and not plain GAsyncQueue.

> But will just flushing the GAsyncQueue be enough? Since _queue_dispatch()
> should be pushing the messages to the fifo ASAP...
Good point, i have to review that more carefully.

> IIRC the signal way was the easy one. Either that or make another
> queue/threads/fifo for "control messages", to send the abort through it,
> which looked like too much work, just for abort.
I have to review the patches for XMPM more carefully, how the signal handling
is done. It's very important that the plugin not get just "killed" and do
some violation of the implemented protocol. Like a missing disconnect
call ... some protocols/plugins will require a certain abort implementation.

Anyway, i hope the current abort implementation at least is "safe" for
aborting during the conflict resolution.

Are you familiar with the abort implementation of XMPM?

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

Hi,

I wanted to give you some detailed feedback (backtace w/ line numbers)
but now I get different behavious each time.
Will let you know when I find something consistent.

For now just one note:
My GUI sets a flag on abort requested; this gets read by the plugin;
which will then call osync_engine_abort from the callbacks.
However, since OpenSync does not seem to really abort
the first time osync_engine_abort is called, my plugin
still gets called again and again,
and so ends up calling osync_engine_abort several times.
Could this be a problem?

/Henrik



Daniel Gollub wrote:

> On Monday 10 March 2008 23:16:00 Henrik /KaarPoSoft wrote:
>  
>> However, just after that I get
>>     libsyncml/sml_session.c:1613:E:smlSessionEnd: Assertion "session"
>> failed so the whole thing crashes!!!
>>
>> Is this something to be corrected in libsyncml, or am I doing something
>> wrong here?
>>    
>
> Not quite sure. Maybe the SyncML Plugin isn't prepared for the case that right
> in the middle of the sync disconnect gets called - which was until now
> unexpected. SyncML Plugin got quite complex - I have to try to reproduce
> this. Backtrace with line numbers would be very helpful, since reproducing
> the issue might take some time until i find some time ;(
>
> best regards,
> Daniel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Opensync-devel mailing list
> Opensync-devel@...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
>  

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Monday 10 March 2008 23:52:26 Henrik /KaarPoSoft wrote:
> For now just one note:
> My GUI sets a flag on abort requested; this gets read by the plugin;
> which will then call osync_engine_abort from the callbacks.
> However, since OpenSync does not seem to really abort
> the first time osync_engine_abort is called, my plugin
> still gets called again and again,
> and so ends up calling osync_engine_abort several times.
> Could this be a problem?

Could you sent me the OSYNC_TRACE files? Maybe it's the issue Gustavo already
mentioned.

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Gustavo De Nardin (spuk)]

* Daniel Gollub <dgollub@...> [2008-03-10 23:35 +0100]:
> On Sunday 09 March 2008 23:38:30 Gustavo De Nardin (spuk) wrote:
> > Could also use _osync_queue_flush_messages() to flush the queue, no?
>
> This would require some refactoring, so the command queue of  OSyncEngine is
> using OSyncQueue and not plain GAsyncQueue.

Ok.

> > But will just flushing the GAsyncQueue be enough? Since _queue_dispatch()
> > should be pushing the messages to the fifo ASAP...
> Good point, i have to review that more carefully.
>
> > IIRC the signal way was the easy one. Either that or make another
> > queue/threads/fifo for "control messages", to send the abort through it,
> > which looked like too much work, just for abort.
> I have to review the patches for XMPM more carefully, how the signal handling
> is done. It's very important that the plugin not get just "killed" and do
> some violation of the implemented protocol. Like a missing disconnect
> call ... some protocols/plugins will require a certain abort implementation.

Looking at the patch and the old code, setting fl_abort would send
disconnect, and that would still be treated by the client, so I think that
was safe (re plugin termination). The sighandler itself, I believe was safe
too, as it should be the only function writing to the "aborted" flag.


> Anyway, i hope the current abort implementation at least is "safe" for
> aborting during the conflict resolution.
>
> Are you familiar with the abort implementation of XMPM?

Currently no. Not familiar with Opensync now too, so sorry if I'm babbling.
:]

cya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Michael Bell]

Henrik /KaarPoSoft schrieb:

> The good news is, that OpenSync tries to abort, so I get:
>     The sync failed: Synchronization got aborted by user!
> which is exactly what I wanted!
>
> However, just after that I get
>     libsyncml/sml_session.c:1613:E:smlSessionEnd: Assertion "session" failed
> so the whole thing crashes!!!
>
> Is this something to be corrected in libsyncml, or am I doing something
> wrong here?

I found the problem while I searched (and found and fixed) another race
condition. Please see rev 3216. This does not mean that it works now for
you completely.

Best regards

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: [phone]       ZE Computer- und Medienservice
Fax:  [phone]       Unter den Linden 6
michael.bell@...   D-10099 Berlin
_______________________________________________________________

X.509 CA Certificates / Wurzelzertifikate

http://ra.pki.hu-berlin.de


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Vis