[ https://issues.oasis-open.org/browse/OSLCCORE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67482#comment-67482 ]
Nick Crossley commented on OSLCCORE-93:
---------------------------------------
Wouldn't adding such a requirement impose a significant compatibility issue for current implementations?
I think the only way to do this would be to recommend a different predicate - trs:sequence or something. The spec would require that a TRS provider MUST provide the trs:order with its current properties, and MAY or SHOULD provide a consecutive monotonically increasing trs:seqence. If a TRS client (or filter) found a change log with trs:sequence properties, it could rely on these to be consecutive; if it found only trs:order, it would have to provide a sorting filter with a 'big enough' buffer to make the probability of a missing change event message unlikely.
> 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)
