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

Excessive CTS logging when Reaper is disabled (com.sun.am.ldap.connnection.idle.seconds=0)



    • Bug
    • Status: Resolved
    • Minor
    • Resolution: Duplicate
    • None
    • CTS
    • Reproduced OOTB (all embedded data stores)
      Reporting Customer: with external stores: CTS (tokens), IDM (users), SM (config)
    • AM Sustaining Sprint 78, AM Sustaining Sprint 79
    • 2
    • Yes
    • No
    • No
    • Yes and I used the same an in the description


      When AM is running in ANY debug=MODE! and the CTS Reaper has been disabled, the CoreSystem log is filling up with excessive WARNING messages (and recording audit events when that's enabled) RE:

      WARNING: Idle timeout is set to 0 - connection pool reaping is disabled


      How to reproduce the issue 

      1. Disable Reaper

      Set com.sun.am.ldap.connnection.idle.seconds=0
      in both bootstrapConfig.properties and Advanced Server defaults. 
      NOT A TYPO: Currently, there are THREE (3) consecutive "n's" for this parameter (_connnection_)

      i.) eg. /opt/am/am6521/WEB-INF/classes/bootstrapConfig.properties
      vi and add parameter to the end of file, clear the logs (cat /dev/null > CoreSystem), save and restart AM for this setting.  Not-Hot-Swappable

      ii.) CONFIGURE > Server Defaults, Advanced
      Add property name and VALUE! (see screenshots for quick ref.), Hot-Swappable

      iii.) CONFIGURE > Server Defaults, General, Debugging TAB!
      Set debug level as desired, you see the isolated output when debug=None, Hot-Swappable

      2. Monitor CoreSystem
      $ tail -f /opt/amdata/am6521/am6521/debug/CoreSystem 
       or every minute or so:
      $ more /opt/amdata/am6521/am6521/debug/CoreSystem |grep WARN 

      Expected behaviour
      WARNING is only displayed on startup when setting up the CTS connection(s) 
      and not written to CoreSystem when debug=None or Error.
      Current behaviour
      Excessive logging is consuming disk space when undesired.

      Work around


      Code analysis

      getIdleTimeout always does a warning when the default idleTimeout is 0 (which is a good default). The code should instead of calling debug.warning just do "debug(...)".



          Issue Links



              chee-weng.chea C-Weng C
              ashley.hale Ashley Hale
              0 Vote for this issue
              4 Start watching this issue