Weblogic doesn't cache LDAP

Question

I have a web application set up using JSF 2.1 and JEE 6 running on a WebLogic 12.1.2 server with an openLDAP for authentication. I've been noticing that loading any page in the app causes multiple BIND requests to LDAP – every single time!

I've read through much of the material and have configured the LDAP provider in Weblogic such that just about any cache I could find is activated. In particular I've set

• [x] Cache Enabled
• Cache Size: 10240
• Cache TTL: 300
• GUID Attribute: entryUUID

I've also double-checked that the entryUUID attribute exists. I'm not too knowledgable on either WebLogic or LDAP, but I've read just about any page on configuring the cache, but there's still just as many requests to the LDAP (yes, I've restarted the servers after changes.)

I'd appreciate any help, insights or wild guesses as to what may be the cause or how I can debug this issue further. I'm not too sure which config files to attach, but if there's anything needed I'm happy to provide it.

The LDAP requests all look like this:

# journalctl -u slapd
# … many of these …
Sep 16 23:06:03 server.org slapd[15038]: daemon: read active on 13
Sep 16 23:06:03 server.org slapd[15038]: daemon: epoll: listen=7 active_threads=0 tvp=zero
Sep 16 23:06:03 server.org slapd[15038]: daemon: epoll: listen=8 active_threads=0 tvp=zero
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND anonymous mech=implicit ssf=0
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND dn="tpid=NQ00000013,ou=people,dc=de,dc=foobiz,dc=com" method=128
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND dn="tpid=NQ00000013,ou=people,dc=de,dc=foobiz,dc=com" mech=SIMPLE ssf=0
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 RESULT tag=97 err=0 text=
Sep 16 23:06:03 server.org slapd[15038]: daemon: activity on 1 descriptor
Sep 16 23:06:03 server.org slapd[15038]: daemon: activity on:

Answer 1

I have figured out the issue and WebLogic isn't at fault whatsoever. Our application seems to be using a rather broken concept of calling remote EJBs where it creates its own proxy, stores the JNDI information and executes a JNDI lookup on every method invocation.

Therefore, even caching the bean wouldn't help. Of course this bypasses any caching mechanisms and thus results in multiple LDAP binds with every request.