Uploaded image for project: 'Crowd'
  1. Crowd
  2. CWD-2494

LDAP Synchronisation can fail unexpectedly due to mistiming in the "LDAP response read time out"



    • Bug
    • Resolution: Tracked Elsewhere
    • Medium
    • None
    • None
    • None
    • None


      In attached log you can see a synchronisation start at 2011-06-01 15:42:59,076 and "time-out" for 120 second timeout at 2011-06-01 15:43:15,739

      Bug description

      In this bug, a read timeout exception is thrown before the timeout has passed. In the log snippet below, read timeout exception was thrown only around 300 milliseconds after last successful LDAP operation:

      2011-06-01 15:43:15,400 QuartzWorker-1 INFO ServiceRunner     [directory.ldap.cache.AbstractCacheRefresher] found [ 210 ] remote user-group memberships in [ 317ms ]
      2011-06-01 15:43:15,715 QuartzWorker-1 INFO ServiceRunner     [atlassian.crowd.directory.DbCachingRemoteDirectory] synchronisation complete in [ 16639ms ]
      2011-06-01 15:43:15,739 QuartzWorker-1 ERROR ServiceRunner     [atlassian.crowd.directory.DbCachingDirectoryPoller] Error occurred while refreshing the cache for directory [ 10000 ].
      com.atlassian.crowd.exception.OperationFailedException: org.springframework.ldap.UncategorizedLdapException: Uncategorized exception occured during LDAP processing; nested exception is javax.naming.NamingException: LDAP response read timed out, timeout used:120000ms.; remaining name 'cn=c-user-1593,ou=childou-c-2000users,ou=loadtesting10k,o=sgi,c=us'


      This bug is triggered randomly in some environments, when the Read Timeout field in LDAP directory properties has been set to non-zero value.

      This bug is caused by a known bug (#6968459) affecting Java SE.


      Normally these exceptions can be safely ignored as the synchronisation is self-correcting. That is, problems encountered in one synchronisation round will get fixed in the following synchronisation round.

      If the synchronisation fails to complete successfully repeatedly, a known workaround is to disable read timeout by setting the Read Timeout field in LDAP directory properties to 0. A side-effect of this change is that Crowd will not be able to recover automatically from LDAP requests that take too long to run, which might cause Crowd to stop communicating with LDAP directories until it is restarted.


        Issue Links



              Unassigned Unassigned
              mlassau Mark Lassau (Inactive)
              10 Vote for this issue
              18 Start watching this issue