ldap search request no received

[paularijit88]

We actually implements the InMemoryOperationInterceptor class and override the required methods.

I use my system as ldapServe and send a ldapSearchRequest from other system. The overridden method processSearchRequest(InMemoryInterceptedSearchRequest request) sometime receive the request sometime not.

[dirmgr]

I'm not aware of any issues like this with the LDAP SDK's in-memory directory server. Could you please provide more context? For example:

• Can you consistently reproduce the problem, or is it only sporadic? If it is sporadic, do you see a bunch of problems all at once and then none for a while, or do they consistently occur throughout your testing?
• Do you see the same problem if you send the requests from the same system rather than from another system? Or if you can't test with requests on the same system, could you test with the in-memory directory server running on a different system than it is now?
• Do you see the problem without the interceptor in place?
• Could you provide a very simple example that demonstrates the problem, or at least describe in more detail what your interceptor does and what kinds of requests you're sending?

You could also try to collect more information about the problem yourself by configuring logging in the in-memory directory server, and also using the LDAP SDK's debugging framework. See https://github.com/pingidentity/ldapsdk/blob/master/src/com/unboundid/ldap/listener/InMemoryDirectoryServerTool.java#L902 for an example of enabling logging in the in-memory directory server, and see https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/util/Debug.html and https://docs.ldap.com/ldap-sdk/docs/getting-started/debug.html for information about the LDAP SDK's debug framework. Maybe something in there (especially the debug information) will provide a clue as to what might be going on. For example, if some unexpected error is happening within the LDAP SDK code, then the debug framework should capture it.

[paularijit88]

Thanks for your suggestion.

Let me describe the problem in details along with the answer of your questions:

We have developed an automation framework. Where there are continuous requests are coming through ldapclient. If we send only one request then there is no problem. but after receiving 20 or more request the problem occurred.

1. Yes we can reproduce it consistently.

2. Since the data coming from a real component and we actually receive the request, simulate and send response. We didn't test it from the same system.

3. We need to use the interceptor to catch the request and simulate the response.

4. The overridden code is :

@Override
	public void processSearchRequest(InMemoryInterceptedSearchRequest request) throws LDAPException {
		LOGGER.info("Message received in LDAP Server[" + instanceName + "]:SearchRequest, Message " + request);

		LdapCacheKey key = new LdapCacheKey();
		key.setAction(LDAPActionType.SEARCH);
		key.setConnectionAddress(request.getConnectedAddress());
		key.setInterfaceName(instanceName);
		key.setConnectionID(request.getConnectionID());
		key.setMessageID(request.getMessageID());
		key.setDN(request.getRequest().getBaseDN());
		key.setFilterString(request.getRequest().getFilter().toNormalizedString());
.
.
.

We failed to find the message for provided in the LOGGER.info.

Let me attach the pcap and the log that can demonstrate the console log that will help you the identify the problem. Pcap :

Console Log: console.zip

In pcap we can find that there is 3 ldap search request but in log we can find that only the last request is received.

[dirmgr]

I spent some time looking into this. After a lot of testing, the only way that I could find to reproduce something like what you're seeing was to have an in-memory operation interceptor throw a java.lang.Error (that is, a Throwable that is not an Exception). In that case, the thread responsible for handling communication with the client would exit without either returning an error result back to the client or closing the connection. I just committed a change that ensures it will do both.

If that isn't the problem that you're encountering, then it's probably the case that the only way we'll be able to troubleshoot it is if you provide either a simple program that I can use to reproduce the behavior on my own, or if you can provide some LDAP SDK debugging content from a time when the problem occurs. You should be able to enable debugging with the following code:

    com.unboundid.util.Debug.setEnabled(true);

    final Logger logger = Logger.getLogger(
         com.unboundid.util.Debug.LOGGER_NAME);
    logger.setLevel(Level.INFO);
    logger.addHandler(new FileHandler("ldap-sdk-debug"));

After you reproduce the problem, the ldap-sdk-debug file will hopefully have some useful information about the nature of the problem.