-
Bug
-
Resolution: Tracked Elsewhere
-
Medium
-
None
-
3.5, 4.1.2, 4.3.7, 5.4.4, 5.5
-
None
This is a clone of CWD-2494.
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'
Cause
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.
Workaround
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.
- is caused by
-
-
- Closed
-
-
-
- Closed
-
- is cloned from
-
-
- Closed
-
- mentioned in
-
![[Atlassian Documentation] Page](/images/icons/generic_link_16.png "[Atlassian Documentation] Page")
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Page Loading...
-
-
-
-
-
-
[CONFSERVER-24460] LDAP Synchronisation can fail unexpectedly due to mistiming in the "LDAP response read time out"
Consu
added a comment - in some of your experience is this affecting also the speed of the login for the internal directory users?
I have users that are not on the LDAP and that are complaining that the login time is endless...
Consu
added a comment - in some of your experience is this affecting also the speed of the login for the internal directory users?
I have users that are not on the LDAP and that are complaining that the login time is endless... Consu
added a comment - Thanks Sorin, I would like to have a patch as well, if not the solution; this issue is really driving us mad...
Consu
added a comment - Thanks Sorin, I would like to have a patch as well, if not the solution; this issue is really driving us mad... I remember getting a special build of Jar from Atlassian for testing a change that was supposed to address this issue but I am not able to identify the original support case as the SAC interface became almost useless since the introduction of Service Desk.
The patched seemed to be working in my case, but obviously I lost the change on upgrade to 5.7.1, I hope they will include the new version soon. If I remember well the patch was supposed to be compatible only with Java 8, that's why they didn't include it with the normal release.
Personally, I would not mind if Atlassian would just suddenly require only Java 8.
Sorin Sbarnea (Citrix)
added a comment - - edited I remember getting a special build of Jar from Atlassian for testing a change that was supposed to address this issue but I am not able to identify the original support case as the SAC interface became almost useless since the introduction of Service Desk.
The patched seemed to be working in my case, but obviously I lost the change on upgrade to 5.7.1, I hope they will include the new version soon. If I remember well the patch was supposed to be compatible only with Java 8, that's why they didn't include it with the normal release.
Personally, I would not mind if Atlassian would just suddenly require only Java 8. Consu
added a comment - I have the same issue and most of my users are affected and unable to login. This cannot be considered a minor issue. I have people locked out the platform all time!
Consu
added a comment - I have the same issue and most of my users are affected and unable to login. This cannot be considered a minor issue. I have people locked out the platform all time! I also see this Problem on Stash 2.12.4. on oracle java 1.7.0_65.
Which Java Version do you guys have installed?
Hi,
we are also running into this bug with Confluence 5.4.4.
Setting the timeout to 0 didn't help.
Dan
Hello,
We are also affected by this bug. We use Confluence 4.3.7 and synchronizing a huge directory. This is pretty annoying.
Is there a fix for this version of Confluence.
We will set the timeout to 0, but this is so far not a good solution if real problems occurs during synchro.
Thanks for your help.
Michael
This issue was caused by JDK bug 6968459 which was marked as a duplicate of JDK bug 7011441. 7011441 was resolved in JDK 1.6.0_22. As such, we are marking this issue as resolved.
If you are experiencing this exact issue on a JDK version higher than 1.6.0_22, please contact Support. If there is a regression or the problem is not resolved, we can revisit this issue.