« Return to Thread: [RFC] Remove pendingLimit from OSyncQueue
Re: [RFC] Remove pendingLimit from OSyncQueue
by Daniel Gollub-3
::
Rate this Message:
On Tuesday 14 April 2009 02:25:29 pm Michael Bell wrote:
> 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.
Ok - this "hack" already exists in get_changes() context with
osync_context_report_change(). (But also for other reasons - like: mixed
objtype syncing).
>
> > 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.
No - since the plugin process space and the engine process space are different
and still need to handle modificatoin on OSyncChange within some context
interface. The reason is that the OSyncChange pointer you have in the plugin
is not the same pointer you have in the engine.
So if you don't change or add a context interface - then after the
osync_context_report_success() call there would be no way to change the UID.
For that reason we need one context call to ACK the message - to get the
message from the pending reply list. And one context interface which reports
the (uid) change after the entry got written.
>
> > 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.
It's not a hack - we do the similar thing inside get_change() context. The
different is that get_changes() get only called once.
> 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?
Don't know any - maybe the qtopia-sync one. But we should introduce some
example async plugin.
>
> 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?
No Idea - maybe Graham kann answer this.
With the new osync_context_ interface there would be no dependency - afaik.
The commit function would just get async.
Best Regards,
Daniel
--
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner
FOSS Developer Unternehmenssitz: Vohburg
B1 Systems GmbH Amtsgericht: Ingolstadt
Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail: gollub@... http://www.b1-systems.de
Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D
------------------------------------------------------------------------------
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
> 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.
Ok - this "hack" already exists in get_changes() context with
osync_context_report_change(). (But also for other reasons - like: mixed
objtype syncing).
>
> > 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.
No - since the plugin process space and the engine process space are different
and still need to handle modificatoin on OSyncChange within some context
interface. The reason is that the OSyncChange pointer you have in the plugin
is not the same pointer you have in the engine.
So if you don't change or add a context interface - then after the
osync_context_report_success() call there would be no way to change the UID.
For that reason we need one context call to ACK the message - to get the
message from the pending reply list. And one context interface which reports
the (uid) change after the entry got written.
>
> > 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.
It's not a hack - we do the similar thing inside get_change() context. The
different is that get_changes() get only called once.
> 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?
Don't know any - maybe the qtopia-sync one. But we should introduce some
example async plugin.
>
> 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?
No Idea - maybe Graham kann answer this.
With the new osync_context_ interface there would be no dependency - afaik.
The commit function would just get async.
Best Regards,
Daniel
--
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner
FOSS Developer Unternehmenssitz: Vohburg
B1 Systems GmbH Amtsgericht: Ingolstadt
Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail: gollub@... http://www.b1-systems.de
Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D
------------------------------------------------------------------------------
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 |
