LDAP Errors In IM Backend Servers: WARN xmppd [default-iim_server-worker 40] [LDAPPool] not allowed to wait, WARN xmppd [default-iim_server-worker 40] [LDAPPool] desperately waiting for a new ldap context; contexts created so far
Last updated on JUNE 21, 2017
Applies to:Oracle Communications Instant Messaging Server - Version 10.0.0 and later
Information in this document applies to any platform.
IM config (iim.conf.xml) has the following set:
Seeing a large increase in all of the 8 nodes of IM backend servers xmppd logs with the following:
1: Is this a symptom of poor LDAP performance or is the not allowed to wait, waiters:50 an Internal IM thing?
2: Is there any reason not to run 'command: /opt/sun/comms/im/sbin/imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-prop -u iim_ldap.maxconns=100'
3: What requests would the IM server be making to the LDAP server when we get these errors?
4: What would be the user's experience resulting from the errors?
5: Are the IM servers creating an unusual load on the LDAP service or is this a symptom of a more general LDAP service performance problem or something else?
6: When does the IM server decide to try the other LDAP servers in the list and does it never switch back without a restart?
7: Does it create iim_ldap.maxconns immediately or does the fact that it has jumped to 100, after setting it to 100, indicate it is having performance problems and therefore trying to open more to get more parallelism (which may just be making the problem worse for the LDAP service)?
8: If I restart one of the servers, why does that cause all the others servers to have a huge spike in LDAP errors? The spikes on the other servers seems much higher than would be explained by the number of users knocked off of the restarted server.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms