Uploaded image for project: 'Identity Provider'
  1. Identity Provider
  2. IDP-1020

Spurious error messages in Secondary service index



    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Duplicate
    • Affects Version/s: 3.2.1
    • Fix Version/s: 3.3.0
    • Component/s: Session
    • Labels:
    • Environment:

      IdP 3.2.1
      CentOS 7
      OpenJdk 1.8.0
      Tomcat 7.0.55

    • Operating System:
    • Java Version:
      Other OpenJDK 8
    • Servlet Container:
      Apache Tomcat 8


      I have configured my IdP with:

      idp.session.trackSPSessions = true
      idp.session.secondaryServiceIndex = true
      idp.logout.elaboration = true

      and I noticed the following error messages in my idp-process.log:

      2016-08-01 16:27:31,589 - ERROR [net.shibboleth.idp.session.impl.StorageBackedSessionManager:636] - Exceeded retry attempts while adding to secondary index
      2016-08-01 16:27:31,595 - ERROR [net.shibboleth.idp.session.impl.UpdateSessionWithSPSession:163] - Profile Action UpdateSessionWithSPSession: Error updating session 71be17936c9700f8593e10640494a4ab9d8dda9f3fb92ea2021cc49f40638bf5
      net.shibboleth.idp.session.SessionException: Exceeded retry attempts while adding to secondary index
      	at net.shibboleth.idp.session.impl.StorageBackedSessionManager.indexBySPSession(StorageBackedSessionManager.java:638)

      This was puzzling me for a while. After some debugging and staring into the code, I have managed to track this down to the logic in net.shibboleth.idp.session.impl.StorageBackedSessionManager in the indexBySPSession method.

      The conditions on lines 671 and 680 say:

      • If we have a sessionList that does not contain the SP entityId yet, update the record
      • If this fails, switch to creating the record as it must have been just deleted.
      • Else, try creating the record - and if it fails, switch to updating, as it must have been just created.

      This logic breaks if the sessionList already exists and it already contains the SP entityId. In this case, the first condition never holds, so the else branch gets used, trying to create the record instead - and after 10 retries, the method gives up.

      This flow can be triggered when the SP makes multiple subsequent SSO requests. I triggered it when testing, but I can also imagine real life use cases that trigger that too.

      In this case, failing to add the SP entityId to the Secondary Index is completely harmless, as the SP entityId is already included in the Secondary Index for that IdP session. However, it generates rather disturbing (but spurious) error messages.

      The fix should be trivial - to also consider the case when sessionList exists and already contains the SP entityId.


          Issue Links



              cantor.2@osu.edu Scott Cantor
              tuakiriadmin-vmencl@virtualhome.tuakiri.ac.nz Vladimir Mencl
              2 Start watching this issue