New bytes in Mustang release of JNDI/LDAP Service Provider

LDAP response timeout:

When an LDAP request is made by a client to a server and the server
does not respond for some reason, the client waits forever for the
server response till the TCP timeouts.
On the client-side what the user experiences is esentially a process
hang. In order to control the LDAP request in a timely manner, a read
timeout can be configured for the Sun JNDI/LDAP Service Provider
since Java SE 6, i.e mustang.

The property com.sun.jndi.ldap.read.timeout is used to specify the read
timeout.The value of this property is the string representation of an integer
representing the read timeout in milliseconds for LDAP operations.
If the LDAP provider cannot get a LDAP response within that period,
it aborts the read attempt. The integer should be greater than zero.
An integer less than or equal to zero means no read timeout is specified
which is equivalent to waiting for the response infinitely until it is received.

If this property is not specified, the default is to wait for the response until
it is received.

For example,

env.put("com.sun.jndi.ldap.read.timeout", "5000");

causes the LDAP service provider to abort the read attempt if the server
does not respond with a reply within 5 seconds.

---

Pooling Custom socket factory:

The JNDI/LDAP Service Provider allows connections from custom socket
factories to be pooled since Java SE 6 (Mustang).

Pooling of connections from a custom socket factory is allowed when
java.naming.ldap.factory.socket  environment property is set
and the custom socket factory to be pooled implements the Comparator
interface. The LDAP Service Provider calls Comparator.compare()
method for equality comparison of the socket factories whose connections
are being checked for equality by the pooling mechanism.The socket factory
comparison should ensure that the socket factory parameters that influence
the connection equality are being compared. This comparison is made
in addition to the connection identity comparison described in
How Connections are Pooled. A custom socket factory class should have
the following structure if its connections were to be pooled:

    public class CustomSocketFactory extends SocketFactory
                implements Comparator<SocketFactory> { 
       :
       :
       public int compare(SocketFactory sf1, SocketFactory sf2) {
	   :
	   :
	   // do whatever comparison that's required
       }
    }

If the socket factory class does not implement Comparator interface,
the connections from that socket factory class do not get pooled.
This requirement for implementing the Comparator interface is to ensure
that the LDAP Service Provider does the necessary checks when
comparing connections from different socket factories whose
implementation is not known to the provider.

Download mustang beta from here

Posted at 07:39AM Feb 15, 2006 by jaya_hangal in Java  |  Comments[1]