OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (OSLCCORE-168) In the TRS spec, describe ways to ensure clients can read base+change log after pruning/rebase


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

Andrii Berezovskyi commented on OSLCCORE-168:
---------------------------------------------

Here is the summary of my point from the yesterday telco:

When the change log CL@t1 is paged by a TRS Client TC at time t1, the client starts from the first page CLP1@t1. The client requests page 2 CLP2@t2 at time at time t2. Here is a problem: if the change log CL@t1 != CL@t2 AND the paging is "OFFSET-based" (as mentioned yesterday), then CLP2@t2 will have a different boundary from CLP1@t1 (because CLP1@t2 is no longer equal to CLP1@t1 itlself)

Here are a few things:
 * if the change log page is sufficiently small (say, 10 change events) AND the change event rate is high, then a slow client might constantly get confused. In fact, paging such a changelog where there are is a dozen updates happening every second, might make the update process problematic and crash the clients that do not handle such corner cases correctly. I know almost for sure that the open-source TRS Client from Lyo might brake if we create a situation complex enough.
 * The TRS spec does not specify that change log paging URIs MUST/SHOULD allow consistent traversal even in the presence of concurrent updates to the Change Log yet alone a TRS Base. Regarding the TRS base, I was wrong when I assumed that the Change Log was paged chronologically, when in fact it is the exact opposite. There was a proposal for the implementations to anchor Change Log page URIs to the trs:order property of the newest event on the previous page, but I don't think there is a mention of that in the spec. I know that Lyo's TRS Server does naïve paging of a given Change Log with a hard-coded constant for the change log pag size (changeable by the OSLC Server developer) and the page id, which simply becomes an offset when multiplied with the aforementioned constant. If we are to propose some guidance here, I want to make sure it will work nicely (from the engineering POV) with the approach of keeping a Change Log in a triplestore graph AND caching the results for "hot" requests (such as base) in Redis.

Am I missing something?

> In the TRS spec, describe ways to ensure clients can read base+change log after pruning/rebase
> ----------------------------------------------------------------------------------------------
>
>                 Key: OSLCCORE-168
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-168
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>          Components: TRS
>            Reporter: Nick Crossley
>            Assignee: Nick Crossley
>            Priority: Major
>
> Suppose a server has a very large number of tracked resources, and it takes a long time (weeks) to read the base, plus the change log, plus GET each of the tracked resources. Suppose a client is in the middle of that long activity when the server updates or replaces the base, and truncates the change log. The specification should have at least non-normative text describing how the server might provide sufficient information for the client to work in this case.



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]