Cache refresh - Identifiying which user/entry is failing or problematic

By: Neemesh Patel user 16 Sep 2016 at 4:04 a.m. CDT

2 Responses
Neemesh Patel gravatar
Hi, I've configured cache refresh and everything has been working great, but recently I am seeing "Problems at the last run: 1" in the cache refresh configuration page. I've had this before and looking at the /opt/tomcat/logs/oxtrust_cache_refresh.log normally states the error (i.e. non-unique ID), but this time it doesn't seem to be including which specific entry it's failing on or why (excerpt below). It is mentioning a "problem file" however so I'm wondering if that will either shed light on the matter or if there is something stuck there. Could anyone help me in identifying which entry is causing the problem? Could you also point me in the direction of how to inspect the "problem file" as that would be useful to know also? > 2016-09-16 08:52:16,688 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) Attempting to load entries from source server > 2016-09-16 08:52:16,690 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) Found '5' entries in source server > 2016-09-16 08:52:16,690 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) Found '5' unique entries in source server > 2016-09-16 08:52:16,693 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) Found '0' changed entries **> 2016-09-16 08:52:16,693 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) Loaded '1' problem entries from problem file** > 2016-09-16 08:52:16,716 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) Updated '0' entries > 2016-09-16 08:52:16,716 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) Failed to update '1' entries > 2016-09-16 08:52:16,733 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) Removed '0' persons from target server > 2016-09-16 08:52:16,733 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) There are '5' entries before updating inum list > 2016-09-16 08:52:16,733 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) There are '5' entries after removal '0' entries > 2016-09-16 08:52:16,733 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-1-thread-10) There are '5' entries after adding '0' entries Thanks
U1404
closed

Answers

By Aliaksandr Samuseu staff 16 Sep 2016 at 7:21 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Neemesh. Problem file is located at `/var/ox/oxtrust/vds-snapshots/problem-inum-list.txt` by default. In your case it should contain just one line. You'll see `inum` of the problem entry in this line. Then do a search like this to get a bit more info what entry it is: `# /opt/opendj/bin/ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D 'cn=directory manager' -w 'YOUR_LDAP_PASS' -b 'o=site' '(inum=@!INUM.FROM.THE.PROBLEM.FILE)'` You also can try to remove everything in the `/var/ox/oxtrust/vds-snapshots/` directory, then at then next pull attempt CR will try to update all user entries, and you'll probably see the reason why this one can't be persisted in the log.

By Neemesh Patel user 19 Sep 2016 at 3:29 a.m. CDT

Copy
Neemesh Patel gravatar
Much appreciated. I couldn't get any results from the LDAP search (be that checking openDJ or our external directory) but clearing the entry out of the problem file did seem to clear the issue. I also manually checked how many were in openDJ vs how many were in our external directory and everything seemed to be accounted for, so my guess is it was something I introduced during development. Thanks for the help, please feel free to close the ticket.

Post an answer