Index Corruption in AEM 5.6.1 after Session.move() | Community
Skip to main content
D
davidf46996755
Level 3
October 16, 2015
Solved

Index Corruption in AEM 5.6.1 after Session.move()

  • October 16, 2015
  • 4 replies
  • 1290 views
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
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

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

4 replies

G
Adobe Employee
gopalKaAdobe Employee
Adobe Employee
October 16, 2015

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.

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
October 16, 2015

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

D
davidf46996755Author
Level 3
October 16, 2015

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!

D
davidf46996755Author
Level 3
October 16, 2015

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

Terms & ConditionsAccessibility statement

Loading footer...