IBM Support

PH24473: OSLC QUERY PAGINATION DOES NOT ALWAYS PRODUCE CONSISTENT OR COMPLETE RESULTS

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • OSLC queries fetch data in pages, but the design of the
    pagination is flawed so as to not to always produce a full or
    correct result.
    
    In escalation 139184 we have this logic:
    1. OSLC Get some batch of records - in this case there are 391
    work items - request 100 at a time (oslc.pageSize=100)
    2. The first request gets first 100 records and a URL to get the
    next 100 (starting at 101)
    3. Client calls the "next" URL repetitively until its done
    fetching results (4 requests, 3 sets of 100 records, the last
    has 91 records)
    4. Sometimes the batches have duplicate entries. Sometimes
    records are missing once all the data is fetched.
    
    The OSLC code does this for each of the 4 batch requests above
    1. Get a list of all (391) of the ids of the records - the sql
    of this get is not sorted and the order of ids cant be predicted
    
    2. Fetch the record data for the ids in the range requested -
    example start_row:201 end_row:300 will get records 201-300 from
    the unsorted list of dbids above
    
    Since the list of ids is unsorted and its fetched every time an
    oslc batch request happens, the contents of any one page cant be
    predicted -
    The second or third page may contain items already fetched.
    Fetching all 4 batches may not actually get all of the records.
    The only thing that's certain is that once all of the pages are
    traversed 391 records will be retrieved (again some may be
    missing and some may be duplicated).
    
    The key to making this work is having the dbids ordered before
    calculating the contents of each page. The order may be able to
    be done in the sql itself or in the list of ids thats in memory.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * ClearQuest OSLC                                              *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * When using a ClearQuest OSLC query to fetch data, the result *
    * is not sorted.                                               *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    

Problem conclusion

  • A fix is available in ClearQuest 9.0.1.10 and 9.0.2.2.
    When using a ClearQuest OSLC query to fetch data, the result is
    now sorted by record dbids in an ascending order.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PH24473

  • Reported component name

    CLEARQUEST WIN

  • Reported component ID

    5724G3600

  • Reported release

    901

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2020-04-16

  • Closed date

    2020-08-17

  • Last modified date

    2020-08-17

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    CLEARQUEST WIN

  • Fixed component ID

    5724G3600

Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSSH5A","label":"Rational ClearQuest"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"901","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
18 August 2020