Unboundid InMemory LDAP SDK - server won't shutdown

632 views Asked by At

I'm using the Unboundid In-Memory Directory Server in my application, and so far it works great (like it so much more than Apache DS). But, when my application is done, and I want to shutdown the server, it seems to "hang", i.e. the shutDown() command gets executed, but the thread won't stop.

InMemoryDirectoryServerConfig configuration = new InMemoryDirectoryServerConfig(baseDNs);
configuration.setListenerConfigs(InMemoryListenerConfig.createLDAPConfig("default", port));
configuration.setSchema(null);
server = new InMemoryDirectoryServer(configuration);
server.startListening();

LDAPConnection ldapConnection = new LDAPConnection("localhost", PORT);

// lots of processing the LDAP data

ldapConnection.close();
server.shutDown("default", true);

It executes without throwing an exeption or something, but still it won't shutDown.

The funny thing is, if I execute the above code w/o the processing, it works.

EDIT

The processing coding basically calls ldapConnection.search() and ldapConnection.getEntry() several times to obtain some user and group information. It then creates objects using this information and then inserts them into a DB.

EDIT 2

It makes no difference if shutDown("default",true) or shutDown(true) is called. I'm going to test the other things you mentioned later.

1

There are 1 answers

0
Neil Wilson On

I've never heard anyone else report a problem with the in-memory directory server not shutting down. What exactly do you mean by won't shutDown? Do you mean that there are still one or more threads still running? Is it still accepting connections from LDAP clients? Are existing connections still established? Does the problem occur consistently, or just sporadically? Do you see any difference in behavior if you call shutDown(true) to shut down all listeners rather than shutDown("default",true) to try to shut down just the "default" listener?

If it seems that one or more threads are still running, could you provide a stack trace of all active threads? You should be able to get that using the jstack command, or by sending a "kill -3" to the JVM process. It would also be helpful if you could enable LDAP SDK debugging by setting the com.unboundid.ldap.sdk.debug.enabled property to true when starting the JVM, or by calling "com.unboundid.util.Debug.setEnabled(true)". If an exception is somehow being caught while trying to perform the shutdown, then enabling debugging should make that visible so that we can better understand what's happening.

Neil