NPE in Cache refresh

By: Frank Rosenberger user 27 Jan 2017 at 6:43 a.m. CST

8 Responses
Frank Rosenberger gravatar
I have recently installed **Gluu Community Edition 2.4.4.sp2** on **Ubuntu Server 16.04.1 LTS**. I have been unable to add users using the Admin UI. I already found out that this is a known issue. I then tried to set up _Cache refresh_ to import users from a eDirectory LDAP installation. Looking at the Admin UI nothing seems to happen (no _last run_ information). The log file ```/opt/tomcat/logs/oxtrust_cache_refresh.log``` reports the following **NullPointerException**: ``` 2017-01-27 11:54:14,960 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-3) Exception happened while executing cache refresh synchronization java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:459) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.toLdapProperties(CacheRefreshTimer.java:1196) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.prepareLdapServerConnection(CacheRefreshTimer.java:1050) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.prepareLdapServerConnection(CacheRefreshTimer.java:1040) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.prepareLdapServerConnections(CacheRefreshTimer.java:1030) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processImpl(CacheRefreshTimer.java:247) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.process(CacheRefreshTimer.java:178) at sun.reflect.GeneratedMethodAccessor272.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.async.AsynchronousInterceptor.aroundInvoke(AsynchronousInterceptor.java:52) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer_$$_javassist_seam_32.process(CacheRefreshTimer_$$_javassist_seam_32.java) at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144) at org.jboss.seam.Component.callComponentMethod(Component.java:2313) at org.jboss.seam.core.Events.raiseEvent(Events.java:85) at org.jboss.seam.async.AsynchronousEvent$1.process(AsynchronousEvent.java:33) at org.jboss.seam.async.Asynchronous$ContextualAsynchronousRequest.run(Asynchronous.java:80) at org.jboss.seam.async.AsynchronousEvent.execute(AsynchronousEvent.java:27) at org.jboss.seam.async.ThreadPoolDispatcher$RunnableAsynchronous.run(ThreadPoolDispatcher.java:142) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) ```
OS Version : N/A
closed

Answers

By Aliaksandr Samuseu staff 27 Jan 2017 at 7:36 a.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Frank. Please provide screenshots with all your CR configuration for us to review.

By Frank Rosenberger user 27 Jan 2017 at 7:59 a.m. CST

Copy
Frank Rosenberger gravatar
[Cache Refresh](http://i.imgur.com/XBHCzsz.png) [Customer Backend Key/Attributes](http://i.imgur.com/eTtRooE.png) [Source Backend LDAP Servers](http://i.imgur.com/8JH1RwK.png)

By Aliaksandr Samuseu staff 27 Jan 2017 at 8:54 a.m. CST

Copy
Aliaksandr Samuseu gravatar
Thanks. Do you really have to use the anonymous bind feature? We are not really sure about this one, and usually recommend against using it. At least, can you reconfigure it to authenticate with some real credentials, just for a test? May be this feature is failing in your case. I also see CR is disabled now, did you disable it after the issue first happened? A couple more suggestions: 1. Attributes **ACL** and **groupMembership** are requested, but are not mapped explicitly. This will most likely create another issue with schema after you'll sort out the current one, unless you've already created custom attributes named like this. 2. Please set **"Level"** to some non-zero value, just in case

By Frank Rosenberger user 30 Jan 2017 at 2:37 a.m. CST

Copy
Frank Rosenberger gravatar
Thank you for the suggestions so far. I did remove the unmapped attributes and set the level. I also switched to non-anonymous bind. I picked my user in the LDAP I'm trying to cache. I used the fully qualified name and set the password using the _Change Bind Password_ UI. I verified the connection data using JXplorer. Yet, the ```/opt/tomcat/logs/oxtrust_cache_refresh.log``` file tells me ``` 2017-01-30 08:30:00,000 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-9) Failed to connect to LDAP server using configuration source 2017-01-30 08:30:00,045 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-9) Skipping cache refresh due to invalid server configuration ``` every time it runs. My complete _Cache refresh_ configuration now looks like this: [Cache Refresh](http://i.imgur.com/OKiPIBr.png) | [Customer Backend Key/Attributes](http://i.imgur.com/EvIuwGz.png) | [Source Backend LDAP Servers](http://i.imgur.com/lpTKvCJ.png) What might be the reason that Gluu can't connect to my source LDAP?

By Aliaksandr Samuseu staff 30 Jan 2017 at 8:15 a.m. CST

Copy
Aliaksandr Samuseu gravatar
> Failed to connect to LDAP server using configuration source Most of the time it's literally this: it can't connect for some reason. Please try next (inside container): 1. `# echo 'BACKEND_BIND_PASS' > /tmp/.bpw` 2. `# /opt/opendj/bin/ldapsearch -h ldapserver.jena.de -p 389 -s sub -T -D 'YOUR-BIND-DN' -j /tmp/.bpw -b 'YOUR-BASE-DN' -z 5 '(objectclass=*)'` Use values specific to your setup instead of place-holders.

By Frank Rosenberger user 30 Jan 2017 at 9:40 a.m. CST

Copy
Frank Rosenberger gravatar
I tried the same combination of _Bind DN_ (`cn=RosenbeF,ou=IT,o=Jena`) and _Base DN_ (`o=Jena`) which allows me to connect using JXplorer and added the `-v` parameter to your command line: ``` # /opt/opendj/bin/ldapsearch -v -h ldapserver.jena.de -p 389 -s sub -T -D 'cn=RosenbeF,ou=IT,o=Jena' -j /tmp/.bpw -b 'o=Jena' -z 5 '(objectclass=*)' [30/01/2017:15:20:32 +0000] category=TOOLS seq=0 severity=FINEST msg=Connect Error exception=LDAPConnectionException: Connect Error (LDAPConnection.java:514 LDAPConnection.java:611 LDAPConnection.java:239 LDAPSearch.java:1520 LDAPSearch.java:549) Connect Error Result Code: 91 (Connect Error) ``` I also tried all other bind/base DN combinations I could imagine - all with the same result: - `-D 'cn=RosenbeF,ou=IT,o=Jena' -b 'o=Jena'` - `-D 'cn=RosenbeF,ou=IT' -b 'o=Jena'` - `-D 'cn=RosenbeF' -b 'o=Jena'` - `-D 'cn=RosenbeF' -b 'ou=IT,o=Jena'` What else could I do?

By Aliaksandr Samuseu staff 30 Jan 2017 at 9:49 a.m. CST

Copy
Aliaksandr Samuseu gravatar
That doesn't seem like issue is related to Gluu any more, unfortunately. Seems like you'll need to troubleshoot connectivity and configuration in your network, which is beyond of Community support. Usual steps, like portscanning, network monitoring (Wireshark, tcpdump) etc. Check whether your DNS name can be resolved from container, etc.

By Frank Rosenberger user 31 Jan 2017 at 3:21 a.m. CST

Copy
Frank Rosenberger gravatar
Indeed it was not directly a Gluu issue, but rather one related to the changeroot environment Gluu runs in. I found out that (in my setup) there is no DNS server visible inside the changeroot environment. Thus Gluu could not find `ladapserver.jena.de`. I resolved this issue by creating a `hosts` file entry mapping the LDAP host name to its IP. _Cache refresh_ now pulls data from my LDAP backend. I still have to deal with some mapping errors, but those are separate issues. Again, thank you for your help. You put me on the right track.

Post an answer