Hi All, I'm experiencing some index corruption in an AEM 5.6.1 author production index. I can't replicate it locally or on staging instances that mirror the production environment. The problem occurs intermittently when moving an asset in a custom workflow process via Session.move(). The move operation doesn't generate any exceptions and the asset is properly moved to its new location. For example, workflowSession.getSession().move(oldPath, newPath). After the (silent) corruption JCR queries return strange results that include both the old location and the new location of the assets. The query results are extra strange because they return the old path even when the query specifically should only search under the new path. For example, suppose the old path is /content/dam/oldassets/asset1.jpg and the new path is /content/dam/newassets/asset1.jpg. And then in CRXDE I do this XPath query: /jcr:root/content/dam/newassets//*[jcr:contains(., 'asset1')] I'm specifically restricting the search to assets contained under newassets but the query results somehow contains both the old and the new paths - despite the fact that the XPath query shouldn't include anything under /content/dam/oldassets. We're going to run a consistency check to see what that turns up. And we'll probably open a ticket with Adobe. Has anyone seen anything like this? Is there maybe a hotfix that addresses similar index corruption issues? Thanks very much. David Frenkiel
Solved! Go to Solution.
Views
Replies
Total Likes
Hi David,
The fact, that you can find a moved asset on the old and the new location can happen at a small timeframe after the move, assuming that you moved larger entities (normally assets), as for these the indexing is executed asynchronously. Then it can take some seconds until the indexing is executed.
The fact, that you find assets on the old path when you looked explicitly only on the new location is quite strange. Can you reproduce the issue also on a different environment?
kind regards,
Jörg
Views
Replies
Total Likes
Try reindexing also. Can you also verify from your backup how far early it was working ok? May be suddenr restart or something happened that corrupted repo.
Views
Replies
Total Likes
Hi David,
The fact, that you can find a moved asset on the old and the new location can happen at a small timeframe after the move, assuming that you moved larger entities (normally assets), as for these the indexing is executed asynchronously. Then it can take some seconds until the indexing is executed.
The fact, that you find assets on the old path when you looked explicitly only on the new location is quite strange. Can you reproduce the issue also on a different environment?
kind regards,
Jörg
Views
Replies
Total Likes
We'll definitely reindex at some point. And maybe/hopefully after a reindex the problem will go away permanently.
The corruption happens during perfectly normal operation as far as I can tell. It doesn't appear to be related to crashes or sudden restarts.
Thanks!
Views
Replies
Total Likes
Hi Jörg,
I haven't been able to reproduce the issue in other environments. The production environment has more content than the other environments so I assume that's why. I'm going to see if I can create a replica of production and test with that.
Thanks,
David Frenkiel
Views
Replies
Total Likes
Views
Likes
Replies