зеркало из https://github.com/mozilla/gecko-dev.git
62 строки
2.7 KiB
Plaintext
62 строки
2.7 KiB
Plaintext
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.
|
|
|