We have just released version 7.0.1 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. You can find the release notes for this release (and all previous versions) at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a summary of the changes: We added a new MaximumIdleDurationLDAPConnectionPoolHealthCheck class that can be used to replace connections that have remained idle for longer than...
The LDAP SDK itself never throws this exception. The JVM will throw it if you've set the SO_TIMEOUT socket option (which says that a read operation should not be allowed to block for more than the specified length of time), and if an attempt to read data from the associated socket doesn't yield any results within the allotted time period. This is a completely normal condition that the JVM happens to use an exception to convey. The LDAP SDK does look for this exception being thrown, and if it encounters...
The persistent issue of the health check thread continuously throwing socket timeout errors raises concerns regarding system reliability and data integrity, especially within healthcare environments where timely access to critical information is paramount. Addressing this challenge requires a thorough investigation into network configurations, application performance optimizations, and potential infrastructure upgrades. Additionally, ensuring compliance with HIPAA checklist guidelines is imperative...
We have just released version 7.0.0 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. You can find the release notes for this release (and all previous versions) at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a summary of the changes: The LDAP SDK now requires Java 8 or later. Java 7 is no longer supported. We improved the behavior of LDAP connection pools when they are configured...
The UnboundID LDAP SDK for Java is a client API that is meant for communicating with an existing LDAP server. While it does include an in-memory directory server, that is primarily meant for testing (e.g., as a convenient server for use in running unit tests for your applications) and is not intended for production use. It doesn't actually store the data anywhere except in memory, and it's not really meant for dealing with huge amounts of data.
How many transactions per sec is supported by this ldap server please?
We have just released version 6.0.11 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. Note that this is the last release of the LDAP SDK that will offer support for Java 7. As of the next release (which is expected to have a version of 7.0.0), the LDAP SDK will only support Java 8 and later. You can find the release notes for the 6.0.11 release (and all previous versions) at https://docs.ldap.com/ldap-sdk/docs/release-notes.html,...
Unless there is substantial pushback with really good reasoning behind it, I intend to update the LDAP SDK to drop support for Java 7 after the next release, which should be version 6.0.11 and will likely be released sometime in December. The next release after that should be version 7.0.0 (which I suppose is an unfortunate coincidence), and it will support Java versions 8 and higher. Java 7 reached its end of support life (EOSL) last year, and it’s getting harder to support newer Java versions while...
We have just released version 6.0.10 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. You can find the release notes for the 6.0.10 release (and all previous versions) at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a summary of the changes: We added a new ReusableReferralConnector interface that makes it possible to create referral connectors that can be reused for following multiple...
It sounds like you're at least able to get past the slowest, single-threaded first phase where it's getting the DNs of the entries. If a large number of threads is working faster for you, then that's the way to go. If it seems like the tool is getting stuck in that phase for a period of time, then jstack is still probably the best tool to use to figure out what it's trying to do. You could also look at the server logs to see if operations are taking a long time there in case it's a server-side i...
We did a run a day or so after our last successful run (at 150 threads) which took approx 30 hours this time at 32 threads as recommended above and it's approx 24 hours in and 4% into the first pass after the read in so seems significantly slower
Does this mean that you were able to get past the initial phase of retrieving the DNs of all of the entries in each of the servers, or is it still in that phase? If it's still in that phase, then it should definitely not be consuming a lot of CPU time on either the client or the server because it's just doing a single search against each directory to retrieve the DNs (the entries without any attributes) of all entries in the server. It's unlikely that the process of comparing a single entry between...
The server is sitting in compare at a single entry for hours but it's at 70% cpu. could our groups just be that big?
It seems like it must be something environmental and not sure why. We have another server that ran at 450 threads and made it past the same error point the new server fails at with 450 threads. Not sure how we determine why we have networking teamlooking. The major difference he saw was that one server sent 5-10gb of data during various packet capture periods and the other never went over 1
I doubt that changing the garbage collector would make any substantial difference if you've got that much memory available to the process. It shouldn't need anywhere near that much. And I don't think that adding any extra debugging would help, either. The ultimate problem is that the server is closing the connection to the client. As I suggested, the best thing to do would be to look at the server logs to see if it provides any indication as to why the connection is being closed. You could also try...
or if there's some extra debug we could do possibly?
we have the java memory set at 40/40 right now not sure if we need some specific gc settings
I don't believe that this specific error has anything to do with exceeding the maximum message size on the client (although that may also have come into play before you set the maximum message size, so that may still be needed), which should give you a more specific error message. It does sound like the connection between the client and the server is being closed unexpectedly in the middle of processing. That looks like it's happened both times (the "server down" result code 81 received on the first...
I don't believe that this has anything to do with exceeding the maximum message size on the client, which should give you a more specific error message. It does sound like the connection between the client and the server is being closed unexpectedly in the middle of processing. That looks like it's happened both times (the "server down" result code 81 received on the first attempt suggests that a previously valid connection now appears to be closed, and the "decoding error" result in the second case...
Yup - Failed third time... thoughts on cause?
Entries identified so far: 73514000. An error occurred while attempting to identify the set of entries to examine in the source server: The attempt to search for applicable entries failed with result SearchResult(resultCode=84 (decoding error), diagnosticMessage='Invalid protocol op type 84 encountered in an LDAP message.', entriesReturned=0, referencesReturned=0). PS E:\unboundid-ldapsdk-6.0.6\unboundid-ldapsdk-6.0.6\tools>
We are currently working to sync a directory with very large groups (+_ 2M members). The system was working well with the addition of a property - com.unboundid.ldap.sdk.LDAPConnectionOptions.defaultMaxMessageSizeBytes and setting it to 400 mb. We have tried to improve performance and moved the work to a bigger host with significant more processor / Memory, and the system is hanging at 73 million compares (consistently) then failing with the following errors - Entries identified so far: 73328000....
We have just released version 6.0.9 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. As announced in the previous release, the LDAP SDK source code is now maintained only at GitHub. The SourceForge repository is still available for its discussion forum, mailing lists, and release downloads, but the source code is no longer available there. You can find the release notes for the 6.0.9 release (and all...
Thanks a lot Neil for the commit.
I just committed a change that adds a getStandardName() method, which retrieves the name used to reference the result code in the relevant specification (which isn't always an RFC). Most of the names use the camelCase formatting, although some of the client-side result codes (such as those defined in draft-ietf-ldapext-ldap-java-api-19) are in ALL_CAPS_SEPARATED_BY_UNDERSCORES because that is the representation used in that specification.
Hi there, First of all thanks for the great library!!!! I was NOT able to find in the SDK constants with String representation of result codes as defined in LDAP RFC. LDAP RFC defines result codes as LDAPResult ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), ... noSuchObject (32), noSuchObject (32), SDK does NOT provide literal constants matching RFC. For instance for result code 32: RFC refers to 'noSuchObject' while name attribute value is "no such object"...
I think that the default behavior is a good one. I do agree that if the connection pool is only set up to use a single server, and if that server is overloaded and returning BUSY in response to every request, then there’s not much benefit to dropping and re-establishing the connection. However, if you’ve got a pool that can use multiple servers, and if you have a health check that operates on newly-established connections and won’t try to use a server that’s returning BUSY results, then it’s definitely...
Hi We are experiencing some problem using UnboundIDLDAP SDK. Problem We are using the unboundid library for our client in a deployment where we have several ldap server deployed in a kubernetes environment. In general our server are always in a similar state relative to the amount of traffic they receive. In summary, when one of them is overloaded is because every ldap server is overloaded. We are experiencing a problem in our clients because of the way the unbounded (version 6.0.4) is handling the...
We have just released version 6.0.8 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. Note that this is the last release for which the LDAP SDK source code will be maintained in both the GitHub and SourceForge repositories. The LDAP SDK was originally hosted in a subversion repository at SourceForge, but we switched to GitHub as the primary repository a few years ago. We have been relying on GitHub’s...
Remove everything but an updated README
Created a tag for the 6.0.8 release
Update documentation for filter creation
Remove subversion repository info
Add shorter method names for constructing filters
Add RFC 9371 and link to IANA PEN registry
Update the OID registry JSON file
Add an ObjectTrio class
Passphrase-encrypted output stream improvements
This forum is for questions regarding the UnboundID LDAP SDK for Java, but your question is regarding the Server SDK. That's really something that should be handled through the official support channel, as it's not relevant here. At any rate, the Server SDK documentation has a set of examples, including an ExampleProxyTransformation.java source file.
Hi, We might have to create a 3rd party proxy transformation. Is there any example code out there by any chance to have a look at to get a bit of an understanding where to start? Cheers, Ed
Update LDAP drafts
Add getServerSet methods to connection pools
Updated cert data RCKSC to handle encrypted DER
Update cert data RCKSC to read PK PW from file
Add DN.getDNRelativeToBaseDN
Update copyrights to include the year 2023
Add support for encrypted PKCS #8 private keys
Post-6.0.7 release updates
Create a tag for the 6.0.7 release
We have just released version 6.0.7 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. You can find the release notes at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a summary of the changes included in this version: We fixed a bug in the SearchResultEntry.equals method that could prevent a SearchResultEntry from matching other types of Entry objects. We fixed a bug in the Entry.applyModifications...
Fix an issue with mutually dependent arguments
Add draft-schmaus-kitten-sasl-ht-09
Fix a bug in SearchResultEntry.equals
Allow getting JSON fields case insensitively
Fix an issue with Entry.applyModifications
Add draft-schmaus-kitten-sasl-ht-08
Post-6.0.6 release updates
Create a tag for the 6.0.6 release
We have just released version 6.0.6 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. You can find the release notes at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a summary of the changes included in this version: General Updates We fixed an issue that could cause request failures when closing a connection operating in asynchronous mode with outstanding operations. We fixed an...
Update the LDAP SDK release notes
Include resource-config.json in the jar manifest
More updates to summarize-access-log
Update the release notes for the previous change
Improve support for GraalVM native images
Secure connection improvements
Update identify-references-to-missing-entries
Fix a summarize-access-log failure count issue
Add more checks to summarize-access-log
Fix ReplicationSummaryReplicationServerTestCase
Fix an issue with FIPS-compliant mode on Java 17
Fix issues with hostname validation
Fix an issue in the IA5 arg value validator
Add retention support to audit data security task
Better handle Java Errors in CLI tools
Add a utility method for non-FIPS BC access
Allow setting join & admin op control criticality
Fix reconnect issues with async operations
Fix JNDI compatibility for controls and extops
Improved a Javadoc comment, eliminating a typo
Rename the replace-existing-certificate argument
Add SearchRequest constructors that take a DN
Post-6.0.5 release updates
Create a tag for the 6.0.5 release
We have just released version 6.0.5 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. You can find the release notes at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a summary of the changes included in this version: General Updates: We fixed an issue that could occasionally cause the LDAP SDK to hide the actual cause of a StartTLS failure by using information from a second, less...
Fix more VPN-related test issues on Windows
Improve OIDRegistryTestCase cross-platform compat
Ensure the LDAPCompare output file is closed
Fix a properties file escaping issue
Fix ToolInvocationLoggerTestCase on Windows
Work around a Ping VPN test issue on Windows