Niclas Tillman

I'm checking out a connection to use for asynchronous operations, so I'll need to handle healthchecking it myself. Thanks for the elaborate answer. It is appreciated. Br Niclas

In this thread "LDAP SDK detects that the connection has been closed" is mentioned. Would this detection detect a disconnect if e.g a network switch goes down, leaving both server and client still running?

Ok, no more followup-questions :) Thanks for all the help! Br Niclas

Alright, I will check that with OpenDJ. Thanks for all the answers to my questions Neil. You've been a tremendous help! Br Niclas

The thing is that we can have multiple subscribers per DN in the database. Having 1 listener means that the listener would need to have logic that notifies the correct subscribers while having multiple listeners would avoid the need for that. So right now I'm more favorable towards multiple listeners as I don't think it will have a huge impact on memory allocation. Regarding releasing the asynchronous connection back to the pool is there any limit or negative impact on keeping a connection checked...

Further, if your main concern is that the server might not be writable because of some bad replication state, then maybe there’s a read-only way to check whether the server might be in that type of state. Perhaps you could first look at the server’s monitor information to see if everything looks healthy, and only attempt a modify if something looks suspicious. This definitely sounds interesting. To implement that would one use the MonitorManager and the getReplicationServerMonitorEntry method? Do...

Hi, We have callback support in our product and we make use of AsyncSearchResultListener for that. Now this is legacy/old code that I'm trying to clean up. In this particular code we reuse the same AsyncSearchResultListener over and over. Is there any practical benefit to doing that or could we createa a new one with each subscribe request? Br Niclas

We do use a FailoverServerSet that is configured with all the servers. In the documentation it states This server set implementation can hold information about multiple servers or server sets, and will always attempt to obtain a connection from a server or server set in the order they were provided (i.e., always try to get a connection to server A first, but if it is unavailable then try server "B", then server "C", etc.) So when the connection is created/retrieved by the ServerSet in the LDAPConnectionPool...