[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=70104#comment-70104 ] 

Andrii Berezovskyi commented on OSLCCORE-93:
--------------------------------------------

Nick, trs:seqence is a great idea! Actually, I think if we define trs:seqence (or trs:order_strict) as a subproperty of trs:order, we may avoid introducing any breaking behaviour.

David, I think there may be some corner cases which would make such a simple approach problematic:

# events may arrive out of order, 995 may arrive just before 994 and we need to know whether to keep it in a queue for 5 seconds and wait if the 994 arrives or to apply it
# TRS events may be published before the newly created resource is 200 available and for a short period of time it may be 404 not found.

These things should not happen, but in a highly concurrent system with a lot of eventual consistency instead of strict transactional behaviour these cases must be considered. Having a strictly sequential properties helps a lot.

Ian, a new MAY-level property could be a compromise indeed but I am not sure what would be the long-term implications of this. Would we ever be able to bump it to SHOULD or MUST in OSLC 4, for example? Or would trs:seqence be always a MAY for the reasons of backwards-compatibility?

> 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
>          Components: TRS
>            Reporter: Andrii Berezovskyi
>            Priority: Major
>              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
(v7.7.2#77003)