On AIX WebSphere 4.0.x DirContext lookup takes 9 minutes 12 seconds to fail

Question

On AIX WebSphere 4.0.x DirContext lookup() (IBM JRE 1.3.1 with Sun JNDI (com.sun.jndi.ldap.LdapCtxFactory)) takes 9 minutes 12 seconds to fail when LDAP server offline:
Code
private DirContext checkConnection (DirContext connection) throws REMException
connectionIsStale = false;
try
log.debug("MSPMSP - Attempting to do the connection.lookup()");
connection = (DirContext) connection.lookup ("");
log.debug("MSPMSP - Finished the connection.lookup()");
catch (NamingException e)
// Connection to LDAP server was lost.
// Try reconnecting.
connectionIsStale = true;
log.debug("MSPMSP - Encountered NamingException, connectionIsStale = " + connectionIsStale);
Trace info:
2003-11-24 15:37:49,995 [Servlet.Engine.Transports:24] DEBUG com.opennetwork.dsmart.util.OntLDAPConnection - MSPMSP - Attempting to do the connection.lookup()
2003-11-24 15:47:03,223 [Servlet.Engine.Transports:24] DEBUG com.opennetwork.dsmart.util.OntLDAPConnection - MSPMSP - Encountered NamingException, connectionIsStale = true
Netstat output:
bash-2.05b# netstat -a | grep 389;date
tcp4 0 69 psaix.dssupport..41239 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41238 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41145 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41130 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41128 ont1285.caas.com.389 ESTABLISHED
Mon Nov 24 15:47:03 EST 2003
bash-2.05b# netstat -a | grep 389;date
tcp4 0 0 psaix.dssupport..42602 ont1285.caas.com.389 SYN_SENT
tcp4 0 0 psaix.dssupport..41238 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41145 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41130 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41128 ont1285.caas.com.389 ESTABLISHED
Mon Nov 24 15:47:03 EST 2003
bash-2.05b# netstat -a | grep 389;date
tcp4 0 0 psaix.dssupport..42624 ont1158.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41238 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41145 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41130 ont1285.caas.com.389 ESTABLISHED
tcp4 0 0 psaix.dssupport..41128 ont1285.caas.com.389 ESTABLISHED
Mon Nov 24 15:48:23 EST 2003
More details:
Here is some output from the AIX machine primary LDAP ont1285.caas.com, secondary LDAP ont1158.caas.com both using port 389:
It appears that on startup the 4 J2EE Applications initiate a connection to the LDAP ont1285.caas.com to read their configuration data. I then hit a few pages with primary still connected. At that point we have 5 ESTABLISHED connections to ont1158.caas.com.389. Then at 15:37:49 I hit a page with primary LDAP unplugged from network. At 15:47:03 the JNDI Lookup call returns (code snippet below). A new connection goes to SYN_SENT state for about a minute and a half, then a connection to the secondary is ESTABLISHED.
Any suggestions on what can cause this delay or another method to call to timeout quicker?
Thanks,
REM

Answer 1

While there isn't a timeout that can be made known to the JNDI/LDAP service provider, a timer can be
set by the application itself.
It might be useful to do something like below:
In your JNDI application you start the timer before the operation that need to timeout, for example:
class SimpleTimeKeeperTest {
public static void main(String args[]) throws Exception {
TimeKeeper.start(5000);
// operation that needs a timeout
while(true) {
Thread.currentThread().sleep(10000);
class TimeKeeper extends Thread {
long timeout; // in milli seconds
long timerStart;
Thread parent;
TimeKeeper(long timeout) {
parent = Thread.currentThread();
this.timeout = timeout;
this.start();
public static void start(long timeout) {
new TimeKeeper(timeout);
public void run() {
timerStart = System.currentTimeMillis();
long waitTime = timeout;
while (waitTime > 0) {
try {
this.sleep(waitTime);
} catch (InterruptedException ie) {
// ignore and continue
waitTime = timeout - (System.currentTimeMillis() - timerStart);
System.out.println(waitTime);
parent.interrupt();