-
Suggestion
-
Resolution: Not a bug
-
None
-
None
-
None
-
AD 2003
After our 2.0 release, the javax.naming.ServiceUnavailableException has become more common.
As a workaround we've been suggesting the following configuration in the Crowd JAVA_OPTS (apache-tomcat/bin/setenv.sh).
-Dcom.sun.jndi.ldap.connect.pool.timeout=3
The fact that it has been working, points that the problem may be in the connection pool (or connections individually).
Another workaround that solved the problem was to start 'TCPMon' on AD-Server and listens on port 390 and pass the data to port 389 (use x.x.x.x:390 as URL in the Crowd-Directory Setup).
Unfortunately, I couldn't reproduce the problem locally.
[CWD-1942] Investigate AD Connectivity issues
Is this issue resolved in a later version of Crowd? The release notes don't indicate that it is, so I'm guessing it was somehow fixed indirectly? Is this still a problem for the latest version 2.0.7?
The intent of the 3ms is to force the connection renewal as soon we notice an abnormal delay in the pool. If "3" is not being effective for your instance, you can increase it to "10" or "1 second". However, the bigger the number, the closer we will get to the timeout in AD, loosing the opportunity to renew the LDAP connection when necessary.
David Yu
added a comment - It should be noted that com.sun.jndi.ldap.connect.pool.timeout expects the values in milliseconds. "3" may be a bit too aggressive. 
David Yu
added a comment - It should be noted that com.sun.jndi.ldap.connect.pool.timeout expects the values in milliseconds. "3" may be a bit too aggressive.
Hi Adam,
After handling some support issues reporting the exact same symptom (javax.naming.ServiceUnavailableException), we concluded that the issue is happening because the searches are timing-out in AD. Version 2.0.7 still need to have the timeout set at the JAVA_OPTS variable (workaround described above).
Crowd 2.1 and newer versions will have a timeout option in the Active Directory Connector UI to allow administrators to adapt Crowd to their AD needs.
From our observations, we concluded that the timeout may happen if:
1. The DC to which Crowd is connecting to is too big (huge number of users/groups), causing the LDAP query to be very expensive for AD.
2. Crowd is connecting to distributed DCs located in different physical locations, causing a search to depend on the communication latency between DCs.
3. The AD server query timeout is set to be very small.
Cheers,
Renan