Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-9798

CTS Query element order should be optimised


    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 14.0.0
    • Fix Version/s: None
    • Component/s: CTS
    • Labels:
    • Support Ticket IDs:


      The queries that are performed with the LDAP SDK must be structured in an optimal way to ensure good performance. This structuring should place filter terms that return fewest results at the front front of the query and elements that return more results at the end.

      In the case of a CTS Query like the CTS Reaper this looks as follows:

      [04/Oct/2016:15:20:25 +0100] SEARCH REQ conn=10 op=3196 msgID=3197 base="ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=forgerock,dc=org" scope=sub filter="(&(objectClass=frCoreToken)(&(coreTokenExpirationDate<=20161004152026.050+0100)(!(coreTokenExpirationDate=20161004152026.050+0100))))" attrs="coreTokenId"
      [04/Oct/2016:15:20:25 +0100] SEARCH RES conn=10 op=3196 msgID=3197 result=0 nentries=0 etime=0

      The elements of the query are:

      • objectClass=frCoreToken
      • (coreTokenExpirationDate<=20161004152026.050+0100)(!(coreTokenExpirationDate=20161004152026.050+0100))

      Currently the CTS is not correctly ordering these queries to be optimal. As a result we run the risk of exceeding two separate limits:

      • size-limit: The maximum number of entries that can be returned in a query
      • lookthrough-limit: The maximum number of entries that can be searched through to build up the results of a query.

      The recommendation is therefore to reverse all CTS queries and better would be to improve the CTS API so that it automatically refactors queries to move known search terms to the end of the query to ensure performant queries.


          Issue Links



              • Assignee:
                rwapshott Robert Wapshott
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: