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

Occasional failure to find server from ID in Webtop/Naming


    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 11.0.3, 12.0.3, 13.0.0, 13.5.0
    • Fix Version/s: 12.0.5, 13.5.1, 14.0.0
    • Component/s: sms
    • Labels:
    • Sprint:
      AM Sustaining Sprint 28
    • Support Ticket IDs:


      On a very rare occasion, Naming/Webtop request fails throwing exception.
      This is similar to OPENAM-5632, but the fix be in ServerConfiguration class as well since this class extends ConfigurationBase.

      When the datastore notification is enabled with the following, listeners such as NamingService, AuthConfigMonitor, LogConfigReader, ServiceConfigImpl etc will be registered to ServiceConfigSchemaManagerImpl either during server startup or when services are first accessed.

      com.sun.identity.sm.enableDataStoreNotification = true
      com.sun.am.event.connection.disable.list = aci, um (removed sm)

      If EventService(monitor which checks availability and modification of datastore) receives ldap error 80, 81 or 90, then it will trigger RetryTask to notify SMSNotificationManager to clear cache.

      The stacktrace when SMSNotificationManager is trying to clear cache looks like this :

      Thread [SystemTimer] (Suspended (breakpoint at line 634 in ServiceConfigImpl))  
          owns: ServiceManager  (id=7403) 
          ServiceConfigImpl.clearCache() line: 634    
          ServiceManager.clearCache() line: 916   
          SMSNotificationManager.allObjectsChanged() line: 320    
          LDAPEventManager.allEntriesChanged() line: 170  
          EventService$RetryTask.run() line: 1222 
          TimerPool$WorkerThread.run() line: 434  

      On a very rare occasion when NamingService request was received while service schema cache is being cleared, OpenAM will get “null” list. And this leads to naming table to have no server information.

      Daemon Thread [http-18080-1] (Suspended (breakpoint at line 253 in ConfigurationBase))  
          ConfigurationBase.getRootServerConfig(SSOToken) line: 253   
          ServerConfiguration.getServerInfo(SSOToken) line: 109   
          NamingService.getServers(Map, Set) line: 689    
          NamingService.updateNamingTable(boolean) line: 232  
          NamingService.getNamingTable(boolean) line: 182 
          NamingService.processRequest(Request) line: 406 
          NamingService.process(List<Request>, HttpServletRequest, HttpServletResponse, ServletContext) line: 383 
          PLLRequestServlet.handleRequest(RequestSet, HttpServletRequest, HttpServletResponse) line: 182  
          PLLRequestServlet.doPost(HttpServletRequest, HttpServletResponse) line: 135 
          PLLRequestServlet(HttpServlet).service(HttpServletRequest, HttpServletResponse) line: 637   
          PLLRequestServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 717   

      The attached XML shows that namingservice table is missing server information below which usually exists in healthy namingtable :

      <Attribute name="03" value="http://lb.example.com:48080"></Attribute>
      <Attribute name="02" value="http://openam.example.com:28080"></Attribute>
      <Attribute name="01" value="http://openam.example.com:18080"></Attribute>

      And since WebtopNaming service cannot retrieve server information based on ID, it will throw error such as below :

      ERROR: WebtopNaming.getServerFromID() can not find server name for server ID : XX
      com.iplanet.services.naming.ServerEntryNotFoundException: Cannot find server.
              at com.iplanet.services.naming.WebtopNaming.getServerFromID(WebtopNaming.java:794)
              at com.iplanet.dpro.session.SessionID.setServerID(SessionID.java:417)
              at com.iplanet.dpro.session.service.SessionService$ExtendedSessionID.<init>(SessionService.java:3624)
              at com.iplanet.dpro.session.service.SessionService.generateSessionId(SessionService.java:727)
              at com.iplanet.dpro.session.service.SessionService.newInternalSession(SessionService.java:647)
              at com.iplanet.dpro.session.service.SessionService.newInternalSession(SessionService.java:618)
              at com.sun.identity.authentication.service.AuthD.newSession(AuthD.java:582)
              at com.sun.identity.authentication.service.LoginState.createSession(LoginState.java:1895)

      OpenAM will recover from this error eventually by itself when naming table is updated and retrieved correct information.


          Issue Links



              • Assignee:
                sachiko Sachiko Wallace
                sachiko Sachiko Wallace
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: