[OASIS Issue Tracker] (OSLCCORE-93) Enforce consecutive order of the trs:order numbers

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67641#comment-67641 ] 

David Honey commented on OSLCCORE-93:
-------------------------------------

This is one of the issues using MQTT to publish notifications of changes to trackled resources. MQTT can guarantee delivery, but does not guarantee order of delivery. So published MQTT messages should avoid containing resource state information as one cannot assume that the latest received message is the current state of a resource.

One approach might be to publish a trs change, and for the receiver to track the last trs:order. If you have processed a trs:order 1000, then you might ignore a later received message with trs:order 990. On receiving a message, perform a GET. If 404 is returned, you know the tracked resource was deleted without having to rely on the message saying it was a trs:Deletion. If 200 is returned, you can index the current data, regardless of whether a new resource was created, or an existing resource was updated. A gap in this approach is the handling for trs patch which requires that the patch changes are applied completely and in the right order.

> Enforce consecutive order of the trs:order numbers
> --------------------------------------------------
>
>                 Key: OSLCCORE-93
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-93
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: Andrii Berezovskyi
>              Labels: TRS
>
> If TRS events are to be distributed via messaging systems without strict ordering guarantees (eg partitioned Kafka topics), a Resequencer EIP pattern might need to be applied. The pattern requires the message order ids to be sequential in order to unambiguously define whether there are any out-of-order messages still missing from the internal resequencing buffer.
> I think a single atomic counter is not too much to ask from the TRS server implementers.
> http://www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)