README for september 28 On September 28, a new source drop was assembled. The LDAPConnection version is now 3.05. Compared to the original 3.0 source drop, this addresses the following problems: On disconnect (or on finalizing an LDAPConnection object, which implicitly calls the finalizer), a reference to the underlying socket was kept, so that the socket was not closed. As a consequence, an application which repeatedly did connect and disconnect would experience a resource leak. On UNIX systems, the java VM might eventually crash because of insufficient file descriptors. On Windows, it might eventually crash because of memory exhaustion. Referrals were not correctly followed on add operations. Support has now been added for referrals on authentication. There is a new overloaded authenticate method in LDAPConnection which takes an LDAPSearchConstraints as a parameter. There was no check for an empty or null host String on connect. Now, LDAPConnection.connect() throws an LDAPException for these two cases. Automatic reconnect when the server was restarted did not work. This is now handled transparently on the next operation. Also, LDAPConnection.isConnected() did not always return a correct response. A bad referral (one that points to a non-existent or inaccessible server or entry) would cause any following valid results from a search to be discarded. For asynchronous searches (batchSize == 1), it was possible that search results would arrive from the server and be buffered by the SDK faster than they could be processed by the application (using LDAPSearchResults.next() or LDAPSearchResults.nextElement()). The buffered results might use up more memory than was available in the java VM, causing it to crash. Now, there is a limit of 100 on the number of buffered entries per asynchronous search. The number can be changed with LDAPSearchConstraints.setMaxBacklog(int backlog). If there are no synchronous searches on a physical connection, and any asynchronous searches have full backlog buffers, the listener thread sleeps until search results are processed by the client. Persistent search response controls could be overwritten before a client could process them. Now they are queued and served up one at a time to the client. LDAPSearchResults().getCount() always returned the number of results processed by the client, rather than the number of results available to be processed by the client. LDAPSearchResults.sort() would throw a ClassCastException if the LDAPSearchResults object contained exceptions (LDAPException and LDAPReferralException) in addition to any LDAPEntry objects. ---- There is also a new directory "tools" containing source for the command-line tools LDAPSearch, LDAPModify, and LDAPDelete.