User directory synchronization fails with NullPointerException at HibernateConfluenceUserDao.rename
Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
LDAP/JIRA/Crowd/AD synchronization fails with this error in atlassian-confluence.log:
F2015-12-15 11:20:11,258 ERROR [scheduler_Worker-1] [atlassian.event.internal.AsynchronousAbleEventDispatcher] run There was an exception thrown trying to dispatch event [com.atlassian.confluence.event.events.user.DirectoryUserRenamedEvent[source=com.atlassian.confluence.user.crowd.CachedCrowdUserDao@17bd4bbb]] from the invoker [SingleParameterMethodListenerInvoker{method=public void com.atlassian.confluence.user.listeners.UserDirectoryListener.onUserRenamedEvent(com.atlassian.confluence.event.events.user.DirectoryUserRenamedEvent), listener=com.atlassian.confluence.user.listeners.UserDirectoryListener@20a2f4c5}]
java.lang.RuntimeException: java.lang.NullPointerException
...
at com.atlassian.confluence.user.crowd.CachedCrowdUserDao.rename(CachedCrowdUserDao.java:275)
at sun.reflect.GeneratedMethodAccessor1488.invoke(Unknown Source)
...
at com.atlassian.crowd.directory.$Proxy2888.updateUsers(Unknown Source)
at com.atlassian.crowd.directory.DirectoryCacheImplUsingChangeOperations.addOrUpdateCachedUsers(DirectoryCacheImplUsingChangeOperations.java:62)
at com.atlassian.crowd.directory.ldap.cache.UsnChangedCacheRefresher.synchroniseAllUsers(UsnChangedCacheRefresher.java:195)
at com.atlassian.crowd.directory.ldap.cache.AbstractCacheRefresher.synchroniseAll(AbstractCacheRefresher.java:89)
at com.atlassian.crowd.directory.ldap.cache.UsnChangedCacheRefresher.synchroniseAll(UsnChangedCacheRefresher.java:168)
at com.atlassian.crowd.directory.DbCachingRemoteDirectory.synchroniseCache(DbCachingRemoteDirectory.java:1122)
at com.atlassian.crowd.manager.directory.DirectorySynchroniserImpl.synchronise(DirectorySynchroniserImpl.java:76)
at com.atlassian.crowd.directory.DbCachingDirectoryPoller.pollChanges(DbCachingDirectoryPoller.java:50)
at com.atlassian.crowd.manager.directory.monitor.poller.DirectoryPollerJobRunner.runJob(DirectoryPollerJobRunner.java:93)
at com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:135)
...
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
Caused by: java.lang.NullPointerException
at com.atlassian.confluence.user.persistence.dao.hibernate.HibernateConfluenceUserDao.rename(HibernateConfluenceUserDao.java:121)
at com.atlassian.confluence.impl.user.persistence.dao.CachingConfluenceUserDao.rename(CachingConfluenceUserDao.java:60)
at sun.reflect.GeneratedMethodAccessor1493.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)Cause
Mismatched username and lower_username in the user_mapping table in the Confluence Database
Resolution
Warning: Backup your database before proceeding.
Before running any SQL in this article, create a full backup of your database. This is a database-level operation with no undo other than a backup restore. Only proceed if you're comfortable running SQL directly against the database, and test on a staging or cloned environment first, wherever possible.
Run this query to identify the mismatch:
SELECT * FROM user_mapping WHERE LOWER(username) != lower_username OR lower_username IS NULL;Fix the mismatch accordingly, and the issue should be resolved. For some cases, the user record itself will not be there in the user_mapping table for those users which have the rename event. In such cases above query will not provide those records. For fixing those records, first, enable the SQL logging so that we have the actual user records and that can be created manually in the user_mapping table.
Was this helpful?