« Return to Thread: [RFC] Remove pendingLimit from OSyncQueue
Re: [RFC] Remove pendingLimit from OSyncQueue
by Michael Bell
::
Rate this Message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel Gollub wrote:
> On Thursday 09 April 2009 10:28:05 am Michael Bell wrote:
>>
>> So the decision is simply to add a new mechanism for mapping IDs or to
>> remove the pendingLimit which creates a dead lock between two originally
>> independent queues.
>
> I don't see the need of a new mapping ID mechanism. We Just need to adapt when
> the UID could get updated by the plugin. Right now this can only happen in the
> "commit (change) context" - which i thought would be perfectly fine.
>
> If you write in SyncML an entry - when do you get the peers mapping id of the
> just changed entry?
Potentially after all changes are available.
> I wonder if it's really impossible to update the change UID before reply the
> "commit (change) context". (Independent of the pendingLimit issue!)
>
> Maybe it would help to introduce a new osync_context_ interface instead.
>
> We change the definition of osync_context_report_success() within the commit
> context. Instead of (additionally) "updating" the UID of a change within the
> this commit context - this functions just ACKs that the commit got
> handled/scheduled within the plugin. Internally this would just frees the
> pendingQeue - no commit report to the Engine - no signalling to the OpenSync
> frontend to a write event.
This would work but it is a hack.
> An additional osync_context_ interface could later report the changed UID
> after write. For that the plugin would need to increase the ref of the
> OSyncContext* and unref it once the change or error got reported with an
> osync_context_ interface. We actually could reuse here
> osync_context_update_change() which is used also in get_changes().
If only the pendingLimit is influenced by the former call then we don't
need additional interfaces because the change was not written. This
means we can still use osync_change_set_uid.
> A plugin which is using commit sink funciton in async way must register a
> committed_all() sink function - to signal when all changes got finally
> committed.
No problem, this is what the SyncML plugin does.
> Would this solve the pendingLimit issue?
I think so. I'm just not sure about introducing an API function to hack
the IPC stuff. Perhaps we should use a function name like
osync_context_set_async. The problem is that the IPC stuff is already
asynchronous and we just make it really async. Are there any other
really asynchronous plugins?
I don't think that a dependency between two pipes is a good idea but I
understand that IPC has limits. I also used IBM MQ series in the past
which has nothing to do with IPC. So is our message queue implementation
a real IPC implementation which requires limits?
Best regards
Michael
- --
___________________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice
Fax: +49 (0)30-2093 2704 Unter den Linden 6
michael.bell@... D-10099 Berlin
___________________________________________________________________
PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ5IC52L0ZGCAwWqsRAiB9AKCrD9WkHLA6ckFxbBi01JEWOxsgAACgo8Ib
nvRJ5J2Rqw/EJeJADuvXdVs=
=qWzv
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
Hash: SHA1
Daniel Gollub wrote:
> On Thursday 09 April 2009 10:28:05 am Michael Bell wrote:
>>
>> So the decision is simply to add a new mechanism for mapping IDs or to
>> remove the pendingLimit which creates a dead lock between two originally
>> independent queues.
>
> I don't see the need of a new mapping ID mechanism. We Just need to adapt when
> the UID could get updated by the plugin. Right now this can only happen in the
> "commit (change) context" - which i thought would be perfectly fine.
>
> If you write in SyncML an entry - when do you get the peers mapping id of the
> just changed entry?
Potentially after all changes are available.
> I wonder if it's really impossible to update the change UID before reply the
> "commit (change) context". (Independent of the pendingLimit issue!)
>
> Maybe it would help to introduce a new osync_context_ interface instead.
>
> We change the definition of osync_context_report_success() within the commit
> context. Instead of (additionally) "updating" the UID of a change within the
> this commit context - this functions just ACKs that the commit got
> handled/scheduled within the plugin. Internally this would just frees the
> pendingQeue - no commit report to the Engine - no signalling to the OpenSync
> frontend to a write event.
This would work but it is a hack.
> An additional osync_context_ interface could later report the changed UID
> after write. For that the plugin would need to increase the ref of the
> OSyncContext* and unref it once the change or error got reported with an
> osync_context_ interface. We actually could reuse here
> osync_context_update_change() which is used also in get_changes().
If only the pendingLimit is influenced by the former call then we don't
need additional interfaces because the change was not written. This
means we can still use osync_change_set_uid.
> A plugin which is using commit sink funciton in async way must register a
> committed_all() sink function - to signal when all changes got finally
> committed.
No problem, this is what the SyncML plugin does.
> Would this solve the pendingLimit issue?
I think so. I'm just not sure about introducing an API function to hack
the IPC stuff. Perhaps we should use a function name like
osync_context_set_async. The problem is that the IPC stuff is already
asynchronous and we just make it really async. Are there any other
really asynchronous plugins?
I don't think that a dependency between two pipes is a good idea but I
understand that IPC has limits. I also used IBM MQ series in the past
which has nothing to do with IPC. So is our message queue implementation
a real IPC implementation which requires limits?
Best regards
Michael
- --
___________________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice
Fax: +49 (0)30-2093 2704 Unter den Linden 6
michael.bell@... D-10099 Berlin
___________________________________________________________________
PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ5IC52L0ZGCAwWqsRAiB9AKCrD9WkHLA6ckFxbBi01JEWOxsgAACgo8Ib
nvRJ5J2Rqw/EJeJADuvXdVs=
=qWzv
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
« Return to Thread: [RFC] Remove pendingLimit from OSyncQueue
| Free embeddable forum powered by Nabble | Forum Help |
