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

Rational ClearQuest Fix Pack 2 (9.0.2.2) for 9.0.2
Rational ClearQuest Fix Pack 12 (9.0.1.12) for 9.0.1
Rational ClearQuest Fix Pack 4 (9.0.2.4) for 9.0.2
Rational ClearQuest Fix Pack 10 (9.0.1.10) for 9.0.1
Rational ClearQuest Fix Pack 11 (9.0.1.11) for 9.0.1
Rational ClearQuest Fix Pack 3 (9.0.2.3) for 9.0.2
Rational ClearQuest Fix Pack 5 (9.0.2.5) for 9.0.2
Rational ClearQuest Fix Pack 13 (9.0.1.13) for 9.0.1

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 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

• R901 PSY

     UP